From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Heads-up: Emacs 26.1 RC1 Date: Wed, 21 Mar 2018 17:48:36 +0800 Message-ID: <878tal4v4b.fsf@ericabrahamsen.net> References: <83605snjjt.fsf@gnu.org> <87605raoo9.fsf@killashandra.ballybran.fr> <83zi33n9ud.fsf@gnu.org> <87y3inalb5.fsf@killashandra.ballybran.fr> <83sh8vn7ss.fsf@gnu.org> <87r2of5las.fsf@ericabrahamsen.net> <83d0zzmd3b.fsf@gnu.org> <87muz35f33.fsf@ericabrahamsen.net> <83bmfjm7ew.fsf@gnu.org> <87efke5o3b.fsf@ericabrahamsen.net> <83h8pakkcg.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521625808 8423 195.159.176.226 (21 Mar 2018 09:50:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Mar 2018 09:50:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: johnw@gnu.org, pierre.techoueyres@free.fr, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 21 10:50:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyaNe-00020r-VZ for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2018 10:50:03 +0100 Original-Received: from localhost ([::1]:53683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyaPg-0005WE-JC for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2018 05:52:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyaOz-0005Vt-9r for emacs-devel@gnu.org; Wed, 21 Mar 2018 05:51:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyaOy-0003Jf-A7 for emacs-devel@gnu.org; Wed, 21 Mar 2018 05:51:25 -0400 Original-Received: from mail.ericabrahamsen.net ([50.56.99.223]:45849) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eyaOt-00035m-D8; Wed, 21 Mar 2018 05:51:19 -0400 Original-Received: from localhost (unknown [172.56.13.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 61BC5C0A5C; Wed, 21 Mar 2018 09:51:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.ericabrahamsen.net; s=mail; t=1521625871; bh=gKup2SG8OIoaxryZ4Mo3H2oEZ+KnR6/Ipc/WOwR0eBg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=snlB/oE/u6/v+73LjLQ2Is3BHE24xF2/oaj/sIYRoUhmlOdpzaM5+n36Sni5PwBmu 0Ps4Q1Eik1oFNwVa88DYM4e+NFzXAtwarhpcrbrhnYKxZ9NvFojPL2GA+XgHF87FIy HYaMCRMgXa7iUGTGElxtLDhjne9N45w7qx3d7HkI= In-Reply-To: <83h8pakkcg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 21 Mar 2018 08:34:39 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 50.56.99.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223880 Archived-At: Eli Zaretskii writes: >> From: Eric Abrahamsen >> 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