From: Michael Albinus <michael.albinus@gmx.de>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Stefan Kangas <stefan@marxist.se>, 36940@debbugs.gnu.org
Subject: bug#36940: tests slowness and failure after recent Tramp changes
Date: Mon, 26 Aug 2019 10:44:06 +0200 [thread overview]
Message-ID: <87k1b0wc2x.fsf@gmx.de> (raw)
In-Reply-To: <dc21144b-ef1f-c3d6-92e9-1dc9212edacc@cs.ucla.edu> (Paul Eggert's message of "Sun, 25 Aug 2019 13:36:46 -0700")
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.
next prev parent reply other threads:[~2019-08-26 8:44 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-06 0:28 bug#36940: tests slowness and failure after recent Tramp changes Paul Eggert
2019-08-06 12:59 ` Michael Albinus
2019-08-06 16:13 ` Paul Eggert
2019-08-06 19:16 ` Michael Albinus
2019-08-06 19:54 ` Michael Albinus
2019-08-06 23:27 ` Paul Eggert
2019-08-07 15:20 ` Michael Albinus
2019-08-07 19:36 ` Paul Eggert
2019-08-08 14:14 ` Michael Albinus
2019-08-07 21:42 ` Glenn Morris
2019-08-08 13:52 ` Michael Albinus
2019-08-10 1:39 ` Paul Eggert
2019-08-10 9:43 ` Michael Albinus
2019-08-10 20:24 ` Paul Eggert
2019-08-11 10:12 ` Michael Albinus
2019-08-14 10:31 ` Michael Albinus
2019-08-15 4:26 ` Paul Eggert
2019-08-24 1:51 ` Stefan Kangas
2019-08-24 8:08 ` Michael Albinus
2019-08-24 12:51 ` Stefan Kangas
[not found] ` <CADwFkmnZ1D-t3BchTSuUrkbkOpKG=yCH9c1ZJbkyGr9mUZrAUg@mail.gmail.com>
2019-08-25 9:27 ` Michael Albinus
2019-08-25 9:51 ` Eli Zaretskii
2019-08-25 10:07 ` Eli Zaretskii
2019-08-25 11:26 ` Michael Albinus
2019-08-25 11:39 ` Eli Zaretskii
2019-08-25 11:46 ` Michael Albinus
2019-08-25 11:58 ` Eli Zaretskii
2019-08-26 9:22 ` Michael Albinus
2019-08-26 9:59 ` Eli Zaretskii
2019-08-26 11:47 ` Michael Albinus
2019-08-26 12:54 ` Stefan Kangas
2019-08-26 14:19 ` Michael Albinus
2019-08-26 14:36 ` Stefan Kangas
2019-08-26 15:09 ` Michael Albinus
2019-08-26 15:46 ` Stefan Kangas
2019-08-26 16:43 ` Michael Albinus
2019-08-26 17:46 ` Stefan Kangas
2019-08-26 19:47 ` Michael Albinus
2019-08-27 16:34 ` Stefan Kangas
2019-08-27 16:56 ` Michael Albinus
2019-08-28 0:23 ` Stefan Kangas
2019-08-25 11:28 ` Michael Albinus
2019-08-25 11:48 ` Michael Albinus
2019-08-25 15:39 ` Paul Eggert
2019-08-25 16:34 ` Michael Albinus
2019-08-25 20:36 ` Paul Eggert
2019-08-26 8:44 ` Michael Albinus [this message]
2019-08-27 2:17 ` Paul Eggert
2019-08-27 11:03 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1b0wc2x.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=36940@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=stefan@marxist.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).