bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#29220: 26.0.90; eieio-persistent-read fail to restore saved object.


From: Eric Abrahamsen
Subject: bug#29220: 26.0.90; eieio-persistent-read fail to restore saved object.
Date: Fri, 17 Nov 2017 20:39:44 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Noam Postavsky <address@hidden> writes:

> Noam Postavsky <address@hidden> writes:
>
>> When I set a breakpoint in eieio-persistent-read, the object being seems
>> correct.  If I evaluate (pcache-get ret 'foo) in edebug, I get 44, as
>> expected.  But somehow the object which gets returned from
>> (pcache-repository :object-name #1="pcache-test/tmp2") doesn't have
>> anything in its hash table.
>
> Okay, I found where the problem is, it's failing pcache-validate-repo
> (what's the idea behind throwing an error which is caught and ignored
> anyway?):
>
>     (cl-defmethod make-instance ((cache (subclass pcache-repository)) &rest 
> args)
>       ...
>                  (condition-case nil
>                      (let* ((obj (eieio-persistent-read path 
> 'pcache-repository)))
>                        (and (or (pcache-validate-repo obj)
>                                 (error "wrong version")) ...
>                    (error nil)))

(Are you guys looking at a different version of the pcache repo? The one
on Github uses `constructor', not `make-instance'.)

> Specifically, this part:
>
>     (defun pcache-validate-repo (cache)
>        ...
>        (cl-every
>         (lambda (entry)
>           (and (object-of-class-p entry (slot-value cache 'entry-cls))
>                ...
>         (pcache-hash-table-values (slot-value cache 'entries)))))
>
> I can't really tell what this function is supposed to be checking.

The call to `eieio-persistent-read' does basic slot value validation,
but this function is additionally checking that all of the entries in
the hash table are of the proper class, that specified in the
`entry-cls' slot.

But I still think the problem isn't in reading, it's in writing: the
entries in the hash table are being written incorrectly, and so this
validation step is exploding.

I sure don't know why setting `print-circle' to t would have solved it,
though...

Eric






reply via email to

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