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: Putting 2fddfb7ce770f into emacs-26? Date: Wed, 08 Nov 2017 09:19:14 -0800 Message-ID: <87r2t8vgbx.fsf@ericabrahamsen.net> References: <87efp9y03x.fsf@ericabrahamsen.net> <83375osr4p.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510161726 14833 195.159.176.226 (8 Nov 2017 17:22:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 17:22:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 08 18:21:59 2017 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 1eCU33-0003ST-Oh for ged-emacs-devel@m.gmane.org; Wed, 08 Nov 2017 18:21:57 +0100 Original-Received: from localhost ([::1]:32856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCU3B-0003n6-1L for ged-emacs-devel@m.gmane.org; Wed, 08 Nov 2017 12:22:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCU2O-0003lm-Pc for emacs-devel@gnu.org; Wed, 08 Nov 2017 12:21:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCU2I-0003Oz-S1 for emacs-devel@gnu.org; Wed, 08 Nov 2017 12:21:16 -0500 Original-Received: from [195.159.176.226] (port=52706 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCU2I-0003NA-K9 for emacs-devel@gnu.org; Wed, 08 Nov 2017 12:21:10 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eCU25-0001HQ-MU for emacs-devel@gnu.org; Wed, 08 Nov 2017 18:20:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 48 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Rjj1ObqS/bZgRDzE+9TtgLqsJFs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:219982 Archived-At: Eli Zaretskii writes: >> From: Eric Abrahamsen >> Date: Tue, 07 Nov 2017 18:29:06 -0800 >> >> I know it's a bit late in the day, but would it be okay to cherry-pick >> 61313f058c7a899c2fbce055d21 from master to emacs-26? > > There's no such commit on master, I guess you took the SHA1 from some > local branch of yours. But I think I've succeeded to guess what you > meant. It is the commit below, right? Weird, I got the right hash in the subject heading, but somehow... > commit 2fddfb7ce770f61313f058c7a899c2fbce055d21 > Author: Eric Abrahamsen > AuthorDate: Sun Oct 22 07:59:29 2017 -0700 > Commit: Eric Abrahamsen > CommitDate: Sun Oct 22 07:59:29 2017 -0700 > > Handle object string name in eieio-persistent-convert-list-object > > * lisp/emacs-lisp/eieio-base.el (eieio-persistent-convert-list-to-object): > Starting to phase out the printing of object names in > `object-write', handle either case. > >> It's related to how EIEIO objects are written to file. Previously, the >> written representation included a string label, which was later >> obsoleted. Current emacs-26 code *assumes* the presence of a string >> label: it discards it, but will fail without it. >> >> The change in 61313f058c7a899c2fbce055d21 checks for the label and >> conditionally ignores it, making the code more resilient when reading >> objects written by a wider range of Emacs versions. A bit of >> future-proofing. >> >> Is that acceptable for emacs-26? > > If you meant the above commit, then are you absolutely sure the second > slot can never be a string unless it's the object name? If you are, > then this is okay for emacs-26. I'm pretty sure, yes. All slots are written as pairs of :slot-name "slot value", and there's currently no way for any odd-numbered element to be anything but a keyword, except for the first one in this "object name" case. Away we go...