* bug#34322: reproducibility: absolute file name in tramp.elc
@ 2019-02-04 22:58 Glenn Morris
2019-02-05 9:00 ` Michael Albinus
2019-02-05 16:14 ` bug#34322: reproducibility: absolute file name in tramp.elc Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Glenn Morris @ 2019-02-04 22:58 UTC (permalink / raw)
To: 34322
Package: emacs
Version: 26.1.91
Severity: minor
Perhaps the same issue as https://debbugs.gnu.org/34321 .
The definition of tramp-lookup-syntax in tramp.elc contains the absolute
file name of the build directory, making the file non-reproducible.
Eg in the 26.1.91 pretest tarfile, it contains
"/home/nico/work/emacs-26/lisp/net/tramp-compat.elc"
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34322: reproducibility: absolute file name in tramp.elc
2019-02-04 22:58 bug#34322: reproducibility: absolute file name in tramp.elc Glenn Morris
@ 2019-02-05 9:00 ` Michael Albinus
2019-02-05 16:18 ` Eli Zaretskii
2019-02-05 16:14 ` bug#34322: reproducibility: absolute file name in tramp.elc Eli Zaretskii
1 sibling, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2019-02-05 9:00 UTC (permalink / raw)
To: Glenn Morris; +Cc: 34322
Glenn Morris <rgm@gnu.org> writes:
> Perhaps the same issue as https://debbugs.gnu.org/34321 .
> The definition of tramp-lookup-syntax in tramp.elc contains the absolute
> file name of the build directory, making the file non-reproducible.
> Eg in the 26.1.91 pretest tarfile, it contains
> "/home/nico/work/emacs-26/lisp/net/tramp-compat.elc"
Don't know how to fix it. For the records, in the emacs-26 branch,
tramp.elc contains
--8<---------------cut here---------------start------------->8---
(defalias 'tramp-lookup-syntax #[257 "\301 \236A\206\f\302\303\b\"\207" [tramp-syntax #[0 "\b\301\267\202\n\302\207\303\207\b\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 8)) default separate] 2 ("/usr/local/src/emacs-26/lisp/net/tramp-compat.elc" . 7408)] error "Wrong `tramp-syntax' %s"] 4 (#$ . 25891)])
--8<---------------cut here---------------end--------------->8---
OTOH, in the Tramp git repository, branch tramp-2-3-stable, tramp.elc contains
--8<---------------cut here---------------start------------->8---
(defalias 'tramp-lookup-syntax #[257 "\b\301\267\202
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#34322: reproducibility: absolute file name in tramp.elc
2019-02-05 9:00 ` Michael Albinus
@ 2019-02-05 16:18 ` Eli Zaretskii
2019-02-05 16:36 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2019-02-05 16:18 UTC (permalink / raw)
To: Michael Albinus, Stefan Monnier; +Cc: 34322
> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Tue, 05 Feb 2019 10:00:15 +0100
> Cc: 34322@debbugs.gnu.org
>
> Don't know how to fix it. For the records, in the emacs-26 branch,
> tramp.elc contains
>
> --8<---------------cut here---------------start------------->8---
> (defalias 'tramp-lookup-syntax #[257 "\301 \236A\206\f\302\303\b\"\207" [tramp-syntax #[0 "\b\301\267\202\n\302\207\303\207\b\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 8)) default separate] 2 ("/usr/local/src/emacs-26/lisp/net/tramp-compat.elc" . 7408)] error "Wrong `tramp-syntax' %s"] 4 (#$ . 25891)])
> --8<---------------cut here---------------end--------------->8---
>
> OTOH, in the Tramp git repository, branch tramp-2-3-stable, tramp.elc contains
>
> --8<---------------cut here---------------start------------->8---
> (defalias 'tramp-lookup-syntax #[257 "\b\301\267\202 \302\202 \303\202 \b\236A\206 \304\305\b\"\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10)) default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
> --8<---------------cut here---------------end--------------->8---
>
> I have no idea where the absolute file name in the former comes
> from.
I tried to explain what it means in another message.
> Both repositories use the same Emacs 26.1.91 binary for the build.
I think whether there is or isn't such a reference depends on whether
tramp-compat.elc exists when you byte-compile tramp.c. Try removing
the former or renaming it, and you get the contents you have in the
second excerpt. So perhaps whether the reference exists or not
depends on the order of the compilation, and maybe also on how many
compilation jobs in parallel are run when boostrapping Emacs.
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#34322: reproducibility: absolute file name in tramp.elc
2019-02-05 16:18 ` Eli Zaretskii
@ 2019-02-05 16:36 ` Stefan Monnier
2019-02-05 17:45 ` Michael Albinus
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2019-02-05 16:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Michael Albinus, 34322
>> --8<---------------cut here---------------start------------->8---
>> (defalias 'tramp-lookup-syntax #[257 "\301 \236A\206\f\302\303\b\"\207"
>> [tramp-syntax #[0 "\b\301\267\202\n\302\207\303\207\b\207" [tramp-syntax
>> #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125
>> purecopy t data (ftp 6 sep 8)) default separate]
>> 2 ("/usr/local/src/emacs-26/lisp/net/tramp-compat.elc" . 7408)] error
>> "Wrong `tramp-syntax' %s"] 4 (#$ . 25891)])
>> --8<---------------cut here---------------end--------------->8---
Hmm... looks like a bug in the implementation of defsubst: it works by
replacing references to tramp-compat-tramp-syntax with a copy of the
function's byte-code (this is the #[0 ...] object above, which includes
the source file name info), and later on those copied bytecode objects
are normally spliced into the surrounding bytecode (at which point the
extra source info is dropped), but here it seems like it hasn't been
spliced as it should.
>> --8<---------------cut here---------------start------------->8---
>> (defalias 'tramp-lookup-syntax #[257 "\b\301\267\202 \302\202 \303\202
>> \b\236A\206 \304\305\b\"\207" [tramp-syntax #s(hash-table size 2 test eq
>> rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10))
>> default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
>> --8<---------------cut here---------------end--------------->8---
Here you can see that there is no nested bytecode object (i.e. no
#[...] with the main #[...]) so the call has been correctly inlined.
> I think whether there is or isn't such a reference depends on whether
> tramp-compat.elc exists when you byte-compile tramp.c. Try removing
I don't think we've changed anything significant in the implementation
of defsubst so indeed it's likely triggered by something like the order
of compilation.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#34322: reproducibility: absolute file name in tramp.elc
2019-02-05 16:36 ` Stefan Monnier
@ 2019-02-05 17:45 ` Michael Albinus
2019-02-05 20:41 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2019-02-05 17:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 34322
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> --8<---------------cut here---------------start------------->8---
>>> (defalias 'tramp-lookup-syntax #[257 "\b\301\267\202 \302\202 \303\202
>>> \b\236A\206 \304\305\b\"\207" [tramp-syntax #s(hash-table size 2 test eq
>>> rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10))
>>> default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
>>> --8<---------------cut here---------------end--------------->8---
>
> Here you can see that there is no nested bytecode object (i.e. no
> #[...] with the main #[...]) so the call has been correctly inlined.
Given, that the absolute file name is not needed in the bytecode, I'm
wondering why we insert it there. Couldn't we live without?
> Stefan
Best regards, Michael.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34322: reproducibility: absolute file name in tramp.elc
2019-02-05 17:45 ` Michael Albinus
@ 2019-02-05 20:41 ` Stefan Monnier
2021-08-11 19:14 ` bug#34322: bug#34321: reproducibility: absolute file name in newst-treeview.elc Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2019-02-05 20:41 UTC (permalink / raw)
To: Michael Albinus; +Cc: 34322
>> Here you can see that there is no nested bytecode object (i.e. no
>> #[...] with the main #[...]) so the call has been correctly inlined.
> Given, that the absolute file name is not needed in the bytecode,
It's present in the in-memory bytecode object so that `C-h f` can jump
to the source upon demand, so it is needed.
> I'm wondering why we insert it there.
It's because we just insert the bytecode object wholesale (not a copy of
the object), so it comes with all its fields.
> Couldn't we live without?
We'd have to make a copy of the bytecode object, skipping the
source-code reference.
But really, this is actually a side-problem: the inlined bytecode is not
spliced the way it should, so the inlining optimization is basically
missing. Such a half-assed inlining gives you all the downsides of
inlining without its upsides. Once we fix that, the reproducibility
problem will also be fixed.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#34322: bug#34321: reproducibility: absolute file name in newst-treeview.elc
2019-02-05 20:41 ` Stefan Monnier
@ 2021-08-11 19:14 ` Lars Ingebrigtsen
0 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-11 19:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Michael Albinus, 34321, rgm, 34322
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> But really, this is actually a side-problem: the inlined bytecode is not
> spliced the way it should, so the inlining optimization is basically
> missing. Such a half-assed inlining gives you all the downsides of
> inlining without its upsides. Once we fix that, the reproducibility
> problem will also be fixed.
It's two years later, so I checked whether this problem is still present
on the trunk, and indeed:
(defalias 'tramp-lookup-syntax #[257 "..." [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 8)) default separate] 2 ("/home/larsi/src/emacs/trunk/lisp/net/tramp-compat.elc" . 7627)] error "Wrong `tramp-syntax' %s"] 4 (#$ . 29248)])
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34322: reproducibility: absolute file name in tramp.elc
2019-02-04 22:58 bug#34322: reproducibility: absolute file name in tramp.elc Glenn Morris
2019-02-05 9:00 ` Michael Albinus
@ 2019-02-05 16:14 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2019-02-05 16:14 UTC (permalink / raw)
To: Glenn Morris, Stefan Monnier; +Cc: 34322
> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 04 Feb 2019 17:58:50 -0500
>
> Package: emacs
> Version: 26.1.91
> Severity: minor
>
> Perhaps the same issue as https://debbugs.gnu.org/34321 .
> The definition of tramp-lookup-syntax in tramp.elc contains the absolute
> file name of the build directory, making the file non-reproducible.
> Eg in the 26.1.91 pretest tarfile, it contains
> "/home/nico/work/emacs-26/lisp/net/tramp-compat.elc"
It seems to be a reference to the place in tramp-compat.elc where
tramp-compat-tramp-syntax is defined. Maybe some byte-compiler guru
could explain or guess when does the byte compiler use such
references. Stefan, any ideas?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-08-11 19:14 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-04 22:58 bug#34322: reproducibility: absolute file name in tramp.elc Glenn Morris
2019-02-05 9:00 ` Michael Albinus
2019-02-05 16:18 ` Eli Zaretskii
2019-02-05 16:36 ` Stefan Monnier
2019-02-05 17:45 ` Michael Albinus
2019-02-05 20:41 ` Stefan Monnier
2021-08-11 19:14 ` bug#34322: bug#34321: reproducibility: absolute file name in newst-treeview.elc Lars Ingebrigtsen
2019-02-05 16:14 ` bug#34322: reproducibility: absolute file name in tramp.elc Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).