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

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

bug#36940: tests slowness and failure after recent Tramp changes


From: Michael Albinus
Subject: bug#36940: tests slowness and failure after recent Tramp changes
Date: Mon, 26 Aug 2019 10:44:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> For example, suppose the inode number is 2**63 - 512 and the Perl code
> generates "9223372036854775296.0", which is exact. When the Emacs Lisp
> reader converts this to double it must round since there is no exact
> double representation, and rounding yields 2**63, i.e.,
> 9223372036854775808.0, which is off by 512.
>
> A simple fix is to change the Perl code to omit the trailing ".0",
> e.g., "9223372036854775296" rather than "9223372036854775296.0". This
> will cause the Emacs Lisp reader in master to return an exact integer
> instead of a float, thus avoiding the rounding error. This fix will
> still suffer from the same rounding errors in older Emacs releases
> where the reader returns a float for integers out of fixnum range, but
> it shouldn't hurt those older releases and it should fix the problem
> in master.

Indeed, up to Emacs 26 this rounding error still applies. With master
(improved big number support) it works fine.

> Please see attached patch. I haven't tested or installed the patch as
> I don't use Tramp, but you should be able to test it with something
> like this:

OK for me. You might install the patch, and also adapt the templates in
`tramp-do-file-attributes-with-stat and'
`tramp-do-directory-files-and-attributes-with-stat'.

>> I haven't seen any code in Emacs which needs this slot.
>
> It's used by ede--inode-for-dir, eshell-shuffle-files, ls-lisp-format,
> find-lisp-format, nnmaildir--group-maxnum,
> nnmaildir--new-number.

`ls-lisp-format' and `find-lisp-format' don't count, they *provide* the
inode number; they don't *use* it.

> Typical uses are to determine whether two
> directory entries identify the same file, e.g., (equal
> (file-attribute-inode-number file1) (file-attribute-inode-number
> file2)) or to use it in a hash table.

`ede--inode-for-dir' and `nnmaildir--*' are a little bit lazy, they
don't compare the device number. Might be acceptable; one could assume
that a project dir or a mail dir handle only files on the same file system.

Best regards, Michael.





reply via email to

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