GNU bug report logs - #29220
26.0.90; eieio-persistent-read fail to restore saved object.

Previous Next

Full log

View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: pierre.techoueyres <at> free.fr (Pierre Téchoueyres)
Cc: 29220 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: bug#29220: 26.0.90; eieio-persistent-read fail to restore saved object.
Date: Tue, 28 Nov 2017 14:10:55 -0800

pierre.techoueyres <at> free.fr (Pierre Téchoueyres) writes:

> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
>>> I've tried to dive into print.c but I don't understand how you return
>>> from print_object, when you're on an hash-table to obtain the vector
>>> with an eieio-class-tag--<class> (as in 25.3) ?
>>>
>>> Can anyone tell me how this work in 25.3 ?
>>
>> Nothing has changed in print.c in this respect.  In 25.3, objects are
>> vectors, and class tags are symbols.  In 26, objects are records and
>> class tags are eieio--class records.  As a result, they print
>> differently.
>
> I trust you, but that's not the answer I expected, sorry.
> I tried to follow the trace from the call of `eieio-persistent-save'
> until I could find where it prints the content of the hash table.
>
> What bothers me is that, in emacs 25, you had have  an short vector with
> a symbol and now you've an big object dump instead.
>
> Emacs 25 :
> [eieio-class-tag--person "Bob"]
>
> Emacs 26 :
> #s(#2=#s(eieio--class person nil nil [#s(cl-slot-descriptor name
> #3=#:unbound string nil)] #s(hash-table size 65 test eq rehash-size
> 1.5 rehash-threshold 0.8125 data (name 0)) nil ((:name . name)) #1=[]
> #1# #s(#2# #3#) (:custom-groups nil)) "Bob")

That's exactly what Noam was saying! The implementation of objects
changed from 25 to 26, and thus their printed representation also
changed.

> As a side note: as class tags are now eieio--class objects you can't read
> an object saved with emacs 25 in emacs 26. Maybe this incompatibility
> should be documented into NEWS ?

The real problem isn't that objects written with 25 can't be read by 26
(I don't think that kind of compatibility is guaranteed), but that
objects written by 26 can't be read at all -- at least not when they're
written internally, as members of other objects.

Personally I'm not sure how to fix the problem, which is why we keep
cc'ing Stefan on these messages (ahem).

Eric

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.