GNU bug report logs - #36447
27.0.50; New "Unknown keyword" errors

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Sun, 30 Jun 2019 18:24:01 UTC

Severity: normal

Tags: fixed

Merged with 36321

Found in version 27.0.50

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, npostavs <at> gmail.com, pipcet <at> gmail.com, 36447 <at> debbugs.gnu.org
Subject: bug#36447: 27.0.50; New "Unknown keyword" errors
Date: Fri, 05 Jul 2019 21:07:03 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Pip Cet <pipcet <at> gmail.com>,  michael_heerdegen <at> web.de,  npostavs <at> gmail.com,  36447 <at> debbugs.gnu.org
> Date: Fri, 05 Jul 2019 14:00:22 -0400
> 
> The problem is not rehashing in general, but rehashing a purecopied
> hash-table.  This should normally never be needed, since a purecopied
> hash-table should never be modified (no puthash/remhash should be
> applied to it), but sadly pdumper may need to recompute the hashes
> because objects's addresses may have changed between the dump and
> the reload.

Then perhaps pdumper should make a new object when it does that?

> His patch can/should be made slightly more efficient by only doing the
> Fcopy_sequence on those hash-tables that are in purespace.

I cannot say I like tweaking the GP implementation for the benefit of
what only the pdumper must do, it doesn't feel right.  Problems caused
by the pdumper should IMO be fixed in pdumper code.




This bug report was last modified 5 years and 316 days ago.

Previous Next


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