all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.