emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heads-up: Emacs 26.1 RC1


From: Eric Abrahamsen
Subject: Re: Heads-up: Emacs 26.1 RC1
Date: Wed, 21 Mar 2018 17:48:36 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Eric Abrahamsen <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]