From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: johnw@gnu.org, pierre.techoueyres@free.fr, emacs-devel@gnu.org
Subject: Re: Heads-up: Emacs 26.1 RC1
Date: Wed, 21 Mar 2018 17:48:36 +0800 [thread overview]
Message-ID: <878tal4v4b.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <83h8pakkcg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 21 Mar 2018 08:34:39 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: pierre.techoueyres@free.fr, johnw@gnu.org, emacs-devel@gnu.org
>> Date: Wed, 21 Mar 2018 07:22:48 +0800
>>
>> > Which code/packages outside of CEDET use the affected functions?
>>
>> Pcache is a big one, as several other packages depend on it -- though I
>> haven't been able to figure out exactly how many from the Melpa repo. It
>> currently errors loudly. The Gnus repository is another, and it is
>> silently corrupted. Those are the main two, and the code changes (though
>> they look large) are specifically targeted at those two packages. A more
>> general solution is in the works for 27, but this was the smallest diff
>> I could manage that fixes the problem.
>
> Then please explain in more detail why the 2nd branch of the 'cond'
> you introduced is needed (the 1st just repeats the original code, so
> it doesn't need any explanation).
>
> Thanks.
Backing up just a bit, I've made two changes to eieio-persistent over
the past few months, both of them already on 26. Both changes introduced
errors that need to be fixed. They are:
c59ddb2120 * Fix slot typecheck in eieio-persistent
e1cc2037a9 * Handle hash tables and vectors when reading/writing EIEIO objects
The first contained a dumb error in that valid types could be returned
as a list, but the code that consumed the return value didn't handle a
list. That mistake is fixed in this (very small) commit on the
fix/eieio-persistent branch:
1ea9947ca3 * Handle possible classtype values in eieio-persistent-read
This fix is necessary to get pcache working again.
The second commit was also necessary for pcache, as it stores eieio
objects inside hash tables. This wasn't an issue in Emacs 25, because
the hash tables were serialized with `prin1', including their values,
and objects written with `prin1' could be read with `read'. It *is* an
issue in Emacs 26, however, because those objects can no longer be read
with `read'. Commit e1cc2037a9 allows the serialization process to
descend into hash tables and handle their values correctly.
That introduced a bug for the Gnus registry, however, as *non-object*
hash table values are written with `eieio-override-prin1', which passes
lists to `eieio-list-prin1', which wraps the list in a call to `quote'.
The registry just happens to use list values in its hash tables, so they
get quoted.
The normal de-serialization process looks for quoted lists and strips
the quote (nine lines from the top of
`eieio-persistent-validate/fix-slot-value'). But the handling of hash
tables and vectors only checks for object values, not for quoted lists.
That means that each time the object is serialized to disk, another call
to `quote' is added, but never stripped, which soon makes the values
useless.
So, to finally answer your question, the new `cond' statements in
bf4f34ac7d on the fix/eieio-persistent branch simply check for a quote
and strip it, the same thing that happens to list values up at the top
of the function.
The whole process is very arbitrary and fragile, and should be reworked.
But at least, with these patches, the process is arbitrary in a way that
can be round-tripped correctly.
1ea9947ca3 on the fix/eieio-persistent branch is all that's needed to
get pcache working again. bf4f34ac7d is needed to get Gnus working, and
to make the process fully balanced between serialization and
de-serialization.
Apologies again for the last-minute mess.
Eric
next prev parent reply other threads:[~2018-03-21 9:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-19 15:59 Heads-up: Emacs 26.1 RC1 Eli Zaretskii
2018-03-19 18:46 ` Pierre Téchoueyres
2018-03-19 19:28 ` Eli Zaretskii
2018-03-19 19:59 ` Pierre Téchoueyres
2018-03-19 20:12 ` Eli Zaretskii
2018-03-20 6:10 ` Eric Abrahamsen
2018-03-20 7:16 ` Eli Zaretskii
2018-03-20 8:25 ` Eric Abrahamsen
2018-03-20 9:18 ` Eli Zaretskii
2018-03-20 23:22 ` Eric Abrahamsen
2018-03-20 23:33 ` Dmitry Gutov
2018-03-21 0:11 ` Eric Abrahamsen
2018-03-21 6:34 ` Eli Zaretskii
2018-03-21 9:48 ` Eric Abrahamsen [this message]
2018-03-21 9:57 ` Eric Abrahamsen
2018-03-21 12:54 ` Eli Zaretskii
2018-03-21 13:50 ` Eric Abrahamsen
2018-03-22 19:38 ` Pierre Téchoueyres
2018-03-19 21:00 ` Michael Heerdegen
2018-03-20 7:03 ` Eli Zaretskii
2018-03-26 18:53 ` Eli Zaretskii
2018-03-26 20:05 ` Michael Heerdegen
2018-03-27 0:01 ` Michael Heerdegen
2018-03-27 2:40 ` Eli Zaretskii
2018-03-27 2:58 ` Michael Heerdegen
2018-03-27 3:12 ` Eli Zaretskii
2018-03-19 21:04 ` Phillip Lord
2018-03-19 21:11 ` Noam Postavsky
2018-03-20 7:05 ` Eli Zaretskii
2018-03-20 10:31 ` Phillip Lord
2018-03-19 21:33 ` Richard Copley
2018-03-20 7:08 ` Eli Zaretskii
2018-03-20 9:52 ` Robert Pluim
2018-03-20 12:32 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878tal4v4b.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=johnw@gnu.org \
--cc=pierre.techoueyres@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.