GNU bug report logs - #55163
29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55163 in the body.
You can then email your comments to 55163 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke
 lsp-mode
Date: Thu, 28 Apr 2022 12:53:44 +0200

Hi,
the recent patch 4a1f69ebca broke the lsp-mode logging code. The logging code uses the expression
expression (/ (nth 2 (time-since before-send)) 1000) to
calculate the time of the event to be logged. lsp-mode starts the lsp-server, but is unable to work.

Thank you.
Ciao



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-04-28 built on 3-191.divsi.unimi.it
Repository revision: 9c70045f674b31db7a640d8a59939ce8df7ed37b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 35 (KDE Plasma)

Configured using:
 'configure --with-cairo --with-x-toolkit=gtk3 --with-xwidgets
 --without-pop --without-imagemagick --prefix=/opt/emacs_x11
 --with-file-notification=inotify --enable-link-time-optimization
 --with-native-compilation --with-xinput2 'CFLAGS=-DMAIL_USE_LOCKF -O3
 -fno-strict-aliasing -g -march=native -mtune=native -D_FORTIFY_SOURCE=2
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fstack-clash-protection
 -fcf-protection''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: it_IT.UTF-8
  locale-coding-system: utf-8-unix

Major mode: JavaScript[JSX]

Minor modes in effect:
  lsp-ui-mode: t
  lsp-ui-doc-mode: t
  dap-tooltip-mode: t
  dap-ui-mode: t
  dap-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: t
  treemacs-fringe-indicator-mode: t
  global-semanticdb-minor-mode: t
  global-git-gutter-mode: t
  git-gutter-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  auto-revert-mode: t
  shell-dirtrack-mode: t
  which-key-mode: t
  projectile-mode: t
  lsp-mode: t
  yas-minor-mode: t
  company-quickhelp-mode: t
  company-quickhelp-local-mode: t
  global-company-mode: t
  company-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  persp-mode: t
  vertico-mode: t
  override-global-mode: t
  electric-pair-mode: t
  which-function-mode: t
  save-place-mode: t
  winner-mode: t
  minibuffer-electric-default-mode: t
  savehist-mode: t
  delete-selection-mode: t
  recentf-mode: t
  xterm-mouse-mode: t
  semantic-idle-completions-mode: t
  global-semantic-idle-completions-mode: t
  global-semantic-idle-scheduler-mode: t
  global-semantic-idle-summary-mode: t
  semantic-idle-summary-mode: t
  semantic-idle-scheduler-mode: t
  semantic-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/opt/emacs_x11/share/emacs/29.0.50/lisp/transient hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/transient-20220425.1314/transient
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/build/src/irony
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/test/elisp/irony
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony-cdb-json hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-cdb-json
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony-iotask hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-iotask

Features:
(shadow sort mail-extr emacsbug cl-print debug backtrace
semantic/decorate/mode semantic/decorate semantic/imenu semantic/sb
semantic/db-typecache lsp-ui lsp-ui-flycheck lsp-ui-doc xwidget
goto-addr lsp-ui-imenu lsp-ui-peek lsp-ui-sideline lsp-ui-util lsp-zig
lsp-steep lsp-svelte lsp-sqls lsp-yaml lsp-xml lsp-vimscript lsp-vhdl
lsp-volar lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v lsp-typeprof
lsp-ttcn3 lsp-toml lsp-terraform lsp-tex lsp-sorbet lsp-solargraph
lsp-rust lsp-rf lsp-remark lsp-r lsp-purescript lsp-pylsp lsp-pyls
lsp-pwsh lsp-php lsp-perlnavigator lsp-perl lsp-openscad lsp-ocaml
lsp-magik lsp-nix lsp-nim lsp-nginx lsp-markdown lsp-lua lsp-kotlin
lsp-json lsp-javascript lsp-java request lsp-idris lsp-haxe lsp-groovy
lsp-hack lsp-graphql lsp-go lsp-completion lsp-gdscript lsp-fsharp
lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elixir lsp-elm
lsp-dockerfile lsp-dhall lsp-dart lsp-dart-commands
lsp-dart-flutter-widget-guide lsp-dart-flutter-fringe-colors
lsp-dart-flutter-colors lsp-dart-outline lsp-dart-code-lens
lsp-dart-test-tree lsp-dart-test-output lsp-dart-test-support
lsp-dart-dap lsp-dart-devtools lsp-dart-flutter-daemon dap-utils
dap-mouse dap-ui gdb-mi bindat gud bui bui-list bui-info bui-entry
bui-core bui-history bui-button bui-utils lsp-lens dap-mode dap-launch
posframe dap-overlays lsp-dart-closing-labels lsp-dart-utils
lsp-dart-protocol lsp-d lsp-css lsp-csharp lsp-crystal lsp-cmake
lsp-clojure lsp-treemacs lsp-treemacs-themes treemacs
treemacs-header-line treemacs-compatibility treemacs-mode
treemacs-bookmarks treemacs-interface treemacs-extensions
treemacs-mouse-interface treemacs-tags treemacs-persistence
treemacs-filewatch-mode treemacs-follow-mode treemacs-rendering
treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-scope pulse treemacs-faces
treemacs-icons treemacs-themes treemacs-core-utils pfuture
treemacs-logging treemacs-customization treemacs-macros
lsp-semantic-tokens lsp-clangd lsp-beancount lsp-bash lsp-ansible
lsp-angular lsp-ada lsp-actionscript semantic/db-find semantic/db-ref
semantic/db-file data-debug cedet-files semantic/wisent/javascript-jv
semantic/wisent/js-wy semantic/wisent semantic/wisent/wisent
semantic/java semantic/doc js-mode-expansions js vc-git vc-dispatcher
company-web-html company-web company-css web-completion-data
web-mode-expansions semantic/db-mode web-mode shortdoc help-fns
radix-tree mule-util cal-move misearch multi-isearch ol-eww eww xdg
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file url-dired svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader range
ol-docview doc-view jka-compr image-mode exif ol-bibtex ol-bbdb ol-w3m
ol-doi org-link-doi the-org-mode-expansions org-element avl-tree org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-java ob-sql ob-js ob-C cc-mode-expansions cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs ob-python ob-shell ob-awk ob ob-tangle org-src ob-ref ob-lob
ob-table ob-exp ob-comint ob-core ob-eval org-table oc-basic bibtex ol
org-keys oc org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs git-gutter google-translate-smooth-ui
google-translate-core-ui facemenu popup google-translate-core
google-translate-tk google-translate-backend magit-bookmark
magit-submodule magit-obsolete magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
diff git-commit log-edit message sendmail yank-media dired
dired-loaddefs rfc822 mml mml-sec epa derived gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util magit-core magit-autorevert autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
magit-git magit-base magit-section crm compat-27 compat-26 compat vterm
tramp tramp-loaddefs trampver tramp-integration tramp-compat parse-time
iso8601 time-date ls-lisp format-spec face-remap term disp-table shell
pcomplete ehelp vterm-module term/xterm xterm expand-region
text-mode-expansions python-el-fgallina-expansions er-basic-expansions
expand-region-core expand-region-custom dired-launch which-key
projectile-speedbar sr-speedbar speedbar dframe projectile lisp-mnt
ibuf-ext ibuffer ibuffer-loaddefs add-log init custom-rust custom-dart
custom-java mvn custom-go custom-sql sql view custom-clojure custom-web
custom-ruby custom-python elpy elpy-rpc pyvenv eshell esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
elpy-shell elpy-profile elpy-django elpy-refactor diff-mode python
hideshow grep files-x cus-edit cus-start cus-load custom-php
custom-markdown custom-c irony irony-iotask lsp-modeline lsp-mode
lsp-protocol yasnippet spinner network-stream puny nsm rmc markdown-mode
color noutline outline lv inline ht filenotify f s ewoc epg rfc6068
epg-config compile comint company-quickhelp pos-tip company-yasnippet
company-keywords company-etags etags fileloop generator
company-dabbrev-code company-dabbrev company-files company-semantic
company-template company-capf company pcase consult-flycheck flycheck
ansi-color dash consult-imenu consult-xref xref project consult-vertico
consult bookmark text-property-search perspective comp comp-cstr
warnings advice thingatpt ido vertico rx edmacro kmacro cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source password-cache json map url-vars
elec-pair which-func imenu saveplace winner ring minibuf-eldef hl-line
savehist delsel recentf tree-widget wid-edit xt-mouse custom-function
custom-variable semantic/idle semantic/analyze semantic/sort
semantic/scope semantic/analyze/fcn semantic/db eieio-base cl-seq
semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt
semantic/util-modes semantic/util semantic pp semantic/tag semantic/lex
semantic/fw eieio seq subr-x byte-opt bytecomp byte-compile cconv
eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib mode-local
find-func cedet iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice simple cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 825540 79395)
 (symbols 48 59651 1)
 (strings 32 278778 26200)
 (string-bytes 1 11022323)
 (vectors 16 122356)
 (vector-slots 8 2826624 108417)
 (floats 8 1092 841)
 (intervals 56 3189 489)
 (buffers 992 28))

Message #8 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Thu, 28 Apr 2022 14:10:57 +0200

Vincenzo Pupillo <v.pupillo <at> gmail.com> writes:

> the recent patch 4a1f69ebca broke the lsp-mode logging code. The logging code uses the expression
> expression (/ (nth 2 (time-since before-send)) 1000) to
> calculate the time of the event to be logged. lsp-mode starts the lsp-server, but is unable to work.

Paul, it seems like this change is just breaking too much code out
there, so I think it'll have to be reverted.

Eli, what do you think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Thu, 28 Apr 2022 16:38:47 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 55163 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii
>  <eliz <at> gnu.org>
> Date: Thu, 28 Apr 2022 14:10:57 +0200
> 
> Vincenzo Pupillo <v.pupillo <at> gmail.com> writes:
> 
> > the recent patch 4a1f69ebca broke the lsp-mode logging code. The logging code uses the expression
> > expression (/ (nth 2 (time-since before-send)) 1000) to
> > calculate the time of the event to be logged. lsp-mode starts the lsp-server, but is unable to work.
> 
> Paul, it seems like this change is just breaking too much code out
> there, so I think it'll have to be reverted.
> 
> Eli, what do you think?

I tend to agree.

I actually didn't expect Paul to make such changes, given the recent
discussion on emacs-devel, where he seemed to agree with my argument
against this kind of changes.  But he did make this change regardless.

Message #14 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Thu, 28 Apr 2022 13:15:54 -0700

[Message part 1 (text/plain, inline)]

On 4/28/22 05:10, Lars Ingebrigtsen wrote:
> Paul, it seems like this change is just breaking too much code out
> there, so I think it'll have to be reverted.

Yes, I came to pretty much the same conclusion. I installed the attached 
patch to revert the effect of the change. Instead, this patch adds a new 
variable current-time-list that lets you try out the new timestamp 
behavior, with the default being the longstanding behavior.

This was separate from the long thread we had about exposing 
clock_getres results to the user, as it doesn't involve calling 
clock_getres; it's merely about timestamp format.

Also, I notice that current-cpu-time was recently added; I'll try to 
spring some time free to look into it and will follow up on Bug#44674.

[0001-Change-current-time-back-to-list-form.patch (text/x-patch, attachment)]

Message #17 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50;
 master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Thu, 28 Apr 2022 22:42:25 +0200

In data giovedì 28 aprile 2022 22:15:54 CEST, Paul Eggert ha scritto:
> On 4/28/22 05:10, Lars Ingebrigtsen wrote:
> > Paul, it seems like this change is just breaking too much code out
> > there, so I think it'll have to be reverted.
> 
> Yes, I came to pretty much the same conclusion. I installed the attached
> patch to revert the effect of the change. Instead, this patch adds a new
> variable current-time-list that lets you try out the new timestamp
> behavior, with the default being the longstanding behavior.
> 
> This was separate from the long thread we had about exposing
> clock_getres results to the user, as it doesn't involve calling
> clock_getres; it's merely about timestamp format.
> 
> Also, I notice that current-cpu-time was recently added; I'll try to
> spring some time free to look into it and will follow up on Bug#44674.

Thanks guys, now it works correctly with this patch.

Ciao

Message #20 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Thu, 28 Apr 2022 23:51:50 +0200

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

> Yes, I came to pretty much the same conclusion. I installed the
> attached patch to revert the effect of the change. Instead, this patch
> adds a new variable current-time-list that lets you try out the new
> timestamp behavior, with the default being the longstanding behavior.

Thanks; makes sense to me.  And it was worth a try to modernise these
functions, but it doesn't seem like the world is ready yet (and it's
hard to see a practical way forward without deprecating all the current
time-related functions and creating new ones, which we probably don't
want to do).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #23 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Thu, 28 Apr 2022 23:55:20 +0200

Vincenzo Pupillo <v.pupillo <at> gmail.com> writes:

> Thanks guys, now it works correctly with this patch.

Thanks for checking; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #28 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 11:54:07 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Thanks; makes sense to me.  And it was worth a try to modernise these
> functions, but it doesn't seem like the world is ready yet (and it's
> hard to see a practical way forward without deprecating all the current
> time-related functions and creating new ones, which we probably don't
> want to do).

Thinking about this slightly more, perhaps it's worth doing?  Because we
currently have some interfaces in this area that could be more efficient
or elegant.

The time functions commonly used are don't have particularly
discoverable names -- current-time and float-time are probably the ones
used most.  Another common source of times are
(file-attribute-modification-time (file-attributes ...)), which is
commonly called in loops, and generates a lot of unnecessary garbage.

So perhaps we could come up with a set of new functions in this area
that are more efficient and avoid using the old time formats.

Off the top of my head, we could have
(file-attribute file 'modification-time) (i.e., have a &rest to specify
the attributes, and don't return a list if there's one attribute, which
is common).  And we could have `time' instead of `current-time', with
(time 'float) instead of `float-time' and even (time 'decoded) instead
of `decode-time'.  Or `time-float', `time-decoded' with no parameters...

And so on.  That is, I think this might be an opportunity to overhaul
Emacs in this area -- introduce efficient functions with consistent
naming, and then obsolete the old ones after a while.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #31 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: v.pupillo <at> gmail.com, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 13:54:03 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 55163 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  Vincenzo Pupillo
>  <v.pupillo <at> gmail.com>
> Date: Fri, 29 Apr 2022 11:54:07 +0200
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Thanks; makes sense to me.  And it was worth a try to modernise these
> > functions, but it doesn't seem like the world is ready yet (and it's
> > hard to see a practical way forward without deprecating all the current
> > time-related functions and creating new ones, which we probably don't
> > want to do).
> 
> Thinking about this slightly more, perhaps it's worth doing?  Because we
> currently have some interfaces in this area that could be more efficient
> or elegant.
> 
> The time functions commonly used are don't have particularly
> discoverable names -- current-time and float-time are probably the ones
> used most.  Another common source of times are
> (file-attribute-modification-time (file-attributes ...)), which is
> commonly called in loops, and generates a lot of unnecessary garbage.
> 
> So perhaps we could come up with a set of new functions in this area
> that are more efficient and avoid using the old time formats.
> 
> Off the top of my head, we could have
> (file-attribute file 'modification-time) (i.e., have a &rest to specify
> the attributes, and don't return a list if there's one attribute, which
> is common).  And we could have `time' instead of `current-time', with
> (time 'float) instead of `float-time' and even (time 'decoded) instead
> of `decode-time'.  Or `time-float', `time-decoded' with no parameters...
> 
> And so on.  That is, I think this might be an opportunity to overhaul
> Emacs in this area -- introduce efficient functions with consistent
> naming, and then obsolete the old ones after a while.

I don't understand how this is related to making the time rfesolution
explicit in time objects.  The main problem in that area wa how we can
know the resolution of each timestamp, not how to expose that to Lisp.

In the particular example you mention, how can Emacs know what is the
resolution of a file's last modification time?

What did I miss?

Message #34 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: v.pupillo <at> gmail.com, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 12:59:39 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I don't understand how this is related to making the time rfesolution
> explicit in time objects.  The main problem in that area wa how we can
> know the resolution of each timestamp, not how to expose that to Lisp.
>
> In the particular example you mention, how can Emacs know what is the
> resolution of a file's last modification time?
>
> What did I miss?

This isn't related to that at all (except tangentially).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #37 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: v.pupillo <at> gmail.com, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 14:10:20 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu,  55163 <at> debbugs.gnu.org,  v.pupillo <at> gmail.com
> Date: Fri, 29 Apr 2022 12:59:39 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I don't understand how this is related to making the time rfesolution
> > explicit in time objects.  The main problem in that area wa how we can
> > know the resolution of each timestamp, not how to expose that to Lisp.
> >
> > In the particular example you mention, how can Emacs know what is the
> > resolution of a file's last modification time?
> >
> > What did I miss?
> 
> This isn't related to that at all (except tangentially).

Then why again would we want to come up with new functions for
handling timestamps? just because the existing ones have names that
make discovery difficult, or are there other reasons?

Message #40 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 12:38:19 -0700

On 4/29/22 04:10, Eli Zaretskii wrote:
> Then why again would we want to come up with new functions for
> handling timestamps? just because the existing ones have names that
> make discovery difficult, or are there other reasons?

I think Lars is saying both, though the other reasons are more important.

Lars makes a good point that common idioms like 
(file-attribute-modification-time (file-attributes F)) generate 
unnecessary garbage. And it's more than just GC overhead: at a lower 
level, 'statx' on GNU/Linux can be significantly more efficient than 
plain 'stat' when retrieving just a subset of stat info (such as, just 
the file timestamp).

Getting various flavors of the current time is another issue. This 
related to the polishing that Stefan referred to with the new CPU time 
primitive.

I'll try to shake some time free to think about this more.

Message #43 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 22:53:31 +0300

> Date: Fri, 29 Apr 2022 12:38:19 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 4/29/22 04:10, Eli Zaretskii wrote:
> > Then why again would we want to come up with new functions for
> > handling timestamps? just because the existing ones have names that
> > make discovery difficult, or are there other reasons?
> 
> I think Lars is saying both, though the other reasons are more important.
> 
> Lars makes a good point that common idioms like 
> (file-attribute-modification-time (file-attributes F)) generate 
> unnecessary garbage. And it's more than just GC overhead: at a lower 
> level, 'statx' on GNU/Linux can be significantly more efficient than 
> plain 'stat' when retrieving just a subset of stat info (such as, just 
> the file timestamp).

This is (almost) unrelated to timestamps.  The same case can be made
about almost every individual file attribute, at least theoretically.

But before we implement a separate primitive for each attribute, we
should ask ourselves: what are the use cases where a Lisp program
would want to use such a primitive.  Taking the file's modification
time as an example, are there any important use cases except
determining if a file is older or newer than another?  Because we
already have a primitive for that.

Message #46 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 15:45:44 -0700

On 4/29/22 12:53, Eli Zaretskii wrote:

>> Lars makes a good point that common idioms like 
>> (file-attribute-modification-time (file-attributes F)) generate 
>> unnecessary garbage. And it's more than just GC overhead: at a lower 
>> level, 'statx' on GNU/Linux can be significantly more efficient than 
>> plain 'stat' when retrieving just a subset of stat info (such as, just 
>> the file timestamp).
> 
> This is (almost) unrelated to timestamps.  The same case can be made
> about almost every individual file attribute, at least theoretically.

Yes, we could separate the idea. File timestamps are the worst offenders 
for GC, so they provide much of the motivation for this other idea.


>   Taking the file's modification
> time as an example, are there any important use cases except
> determining if a file is older or newer than another?

Yes, for example lots of Lisp code takes a file timestamp, keeps it 
somewhere, then examines it later to print or to compare to another 
timestamp. See, for example, how ido-file-name-all-completions compares 
ctime (the cached timestamp) to mtime (the file timestamp).

> we already have a primitive for that

Sure, but file-newer-than-file-p is not adequate for many routine 
calculations involving file timestamps. It can't do the sort of caching 
described above, for example. My impression is that 
file-newer-than-file-p suffices for less than half of the sort of 
routine things people need to do with file timestamps.

Message #49 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>,
 55163 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 18:44:54 -0700

On 4/29/22 02:54, Lars Ingebrigtsen wrote:

> Off the top of my head, we could have
> (file-attribute file 'modification-time) (i.e., have a &rest to specify
> the attributes, and don't return a list if there's one attribute, which
> is common).

Yes, one possibility is to generalize file-attributes's existing 
ID-FORMAT argument. For example, if (file-attributes "/") currently 
returns (t 20 0 0 (25196 16750 33564 745000) (25175 34183 905318 398000) 
(25175 34183 905318 398000) 4096 "dr-xr-xr-x" t 2 2053), then 
(file-attributes "/" '(mtime size dev)) would return just 
((1649902983905318398000 . 1000000000000) 4096 2053) - that is, just the 
requested components. And (file-attributes "/" 'size) would return just 
4096 as you suggest.

file-attributes's existing ID-FORMAT args 'integer' and 'string' would 
continue to have their current meaning for backward compatibility.


>  And we could have `time' instead of `current-time', with
> (time 'float) instead of `float-time' and even (time 'decoded) instead
> of `decode-time'.  Or `time-float', `time-decoded' with no parameters...

It sounds like the idea here is to use the prefix 'time' for 
time-related functions. Although I prefixed 'time-' to names of the time 
functions I added a few years ago (e.g., time-convert) I'm a bit leery 
about using the very-generic name 'time' for a new function. It's 
probably better to use a hyphenated name.


> introduce efficient functions with consistent
> naming, and then obsolete the old ones after a while.
For consistent naming, we could borrow names from GNU/Linux and POSIX, 
which have CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID. 
For example, we could have:

* (clock-realtime) returns the system-wide clock. It acts like 
(time-convert nil t), i.e., like (current-time) but returning (TICKS . 
HZ) form.

* (clock-process-cputime) returns the Emacs process's CPU-time clock; it 
would replace the recently-added current-cpu-time (except the obvious 
implementation would be less likely to wrap around).

* (clock-monotonic) is like (clock-realtime) except it cannot have 
negative clock jumps and its origin is unspecified. Emacs has nothing 
like this now; it would be useful for apps that keep event timestamps 
and want to know whether event A occurred before event B (current-time 
doesn't do that).

GNU/Linux has seven other kinds of clocks that could be useful, plus 
dynamic clocks, but we don't need to support them all, at least not 
until there's a demonstrated need.

Alternatively, if we'd rather not add one Lisp primitive per clock, we 
could add just one primitive (clock-time CLOCK) where CLOCK specifies 
the type of clock desired.

Message #52 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 08:29:24 +0300

> Date: Fri, 29 Apr 2022 15:45:44 -0700
> Cc: larsi <at> gnus.org, 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> >   Taking the file's modification
> > time as an example, are there any important use cases except
> > determining if a file is older or newer than another?
> 
> Yes, for example lots of Lisp code takes a file timestamp, keeps it 
> somewhere, then examines it later to print or to compare to another 
> timestamp. See, for example, how ido-file-name-all-completions compares 
> ctime (the cached timestamp) to mtime (the file timestamp).

Such code cannot take advantage of this particular proposal, it will
have to be rewritten to be able to do that.  When it _is_ rewritten,
it can easily use the existing primitive, perhaps after we extend it
(see below).

> > we already have a primitive for that
> 
> Sure, but file-newer-than-file-p is not adequate for many routine 
> calculations involving file timestamps. It can't do the sort of caching 
> described above, for example.

We can easily extend it to be able to receive a time object instead of
one of the file names.  (Or maybe I don't understand what kind of
"caching" you have in mind.)

But since we were talking about something more general, what are the
use cases for the other file attributes that would be much better
served by having separate primitives for those attributes?

Message #55 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 08:40:32 +0300

> Date: Fri, 29 Apr 2022 18:44:54 -0700
> Cc: 55163 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>  Vincenzo Pupillo <v.pupillo <at> gmail.com>,
>  Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> For consistent naming, we could borrow names from GNU/Linux and POSIX, 
> which have CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID. 
> For example, we could have:
> 
> * (clock-realtime) returns the system-wide clock. It acts like 
> (time-convert nil t), i.e., like (current-time) but returning (TICKS . 
> HZ) form.
> 
> * (clock-process-cputime) returns the Emacs process's CPU-time clock; it 
> would replace the recently-added current-cpu-time (except the obvious 
> implementation would be less likely to wrap around).
> 
> * (clock-monotonic) is like (clock-realtime) except it cannot have 
> negative clock jumps and its origin is unspecified. Emacs has nothing 
> like this now; it would be useful for apps that keep event timestamps 
> and want to know whether event A occurred before event B (current-time 
> doesn't do that).
> 
> GNU/Linux has seven other kinds of clocks that could be useful, plus 
> dynamic clocks, but we don't need to support them all, at least not 
> until there's a demonstrated need.
> 
> Alternatively, if we'd rather not add one Lisp primitive per clock, we 
> could add just one primitive (clock-time CLOCK) where CLOCK specifies 
> the type of clock desired.

Creeping featurism alert!

As I already said up-thread: let's not introduce APIs for which we
don't have clear and frequently-needed use cases in Emacs.  Emacs is
not a general-purpose programming platform, it's mainly a platform for
writing text-processing applications.  We don't need to provide
interfaces to every OS-level facility under the sun, only to those
which matter to Emacs's important uses.  Thinking about this from the
OS-level POV, as opposed to the POV of Lisp programs which could use
those facilities, will facilitate introduction of APIs that are hard
to discover, understand, and use, unless one is familiar with these
OS-level concepts and the related system calls -- which is not who
most Emacs Lisp programmers are.

IMO, this is the wrong way of introducing features into Emacs.

Message #58 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: v.pupillo <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 11:10:18 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> But before we implement a separate primitive for each attribute, we
> should ask ourselves: what are the use cases where a Lisp program
> would want to use such a primitive.  Taking the file's modification
> time as an example, are there any important use cases except
> determining if a file is older or newer than another?  Because we
> already have a primitive for that.

It's common to get a list of files (including modtime) and then offer to
sort the files in various ways.

My overall point here was simply: If we're going to institute some
interface changes in how we deal with time (in general, and I think we
probably should because of resolution and efficiency issues), it's an
opportunity to look at the wider ecosystem of functionality in this
area, and see whether we can improve other things at the same time.
`file-attributes' seems like an obvious low-hanging fruit.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #61 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>,
 55163 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 11:15:16 +0200

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

> It sounds like the idea here is to use the prefix 'time' for
> time-related functions. Although I prefixed 'time-' to names of the
> time functions I added a few years ago (e.g., time-convert) I'm a bit
> leery about using the very-generic name 'time' for a new
> function. It's probably better to use a hyphenated name.

Yes, `time' as a function name does sound a bit...  dramatic.  On the
other hand, it looks kinda nice in things like (time-less-p thing (time)),
etc.

> For consistent naming, we could borrow names from GNU/Linux and POSIX,
> which have CLOCK_REALTIME, CLOCK_MONOTONIC,
> CLOCK_PROCESS_CPUTIME_ID. For example, we could have:
>
> * (clock-realtime) returns the system-wide clock. It acts like
>   (time-convert nil t), i.e., like (current-time) but returning (TICKS
>   . HZ) form.

clock- as a prefix does make a lot of sense, but I think I'd interpret
that as "realtime" as something having to do with scheduling, and
"clock" perhaps as a localised time (i.e., "the wall clock in time zone
foo").

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #64 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: v.pupillo <at> gmail.com, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 13:00:21 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  55163 <at> debbugs.gnu.org,
>   v.pupillo <at> gmail.com
> Date: Sat, 30 Apr 2022 11:10:18 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > But before we implement a separate primitive for each attribute, we
> > should ask ourselves: what are the use cases where a Lisp program
> > would want to use such a primitive.  Taking the file's modification
> > time as an example, are there any important use cases except
> > determining if a file is older or newer than another?  Because we
> > already have a primitive for that.
> 
> It's common to get a list of files (including modtime) and then offer to
> sort the files in various ways.

That might mean we want a primitive that returns a list of files
sorted by modtime, not necessarily that we want a primitive that
returns just a modtime of a file.

> My overall point here was simply: If we're going to institute some
> interface changes in how we deal with time (in general, and I think we
> probably should because of resolution and efficiency issues), it's an
> opportunity to look at the wider ecosystem of functionality in this
> area, and see whether we can improve other things at the same time.
> `file-attributes' seems like an obvious low-hanging fruit.

I agree with the general idea, but we should consider each related
functionality on a case-by-case basis, and refrain from introducing
new APIs just because we can, or because they could be useful in some
theoretical situations.  Because if we don't make these judgments, we
will risk adding gobs of new APIs that rarely if ever used in
practice, and the net result will be a fatter Emacs that is not more
useful.

Message #67 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 55163 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#55163: 29.0.50;
 master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 13:21:04 +0200

In data sabato 30 aprile 2022 07:40:32 CEST, Eli Zaretskii ha scritto:
> As I already said up-thread: let's not introduce APIs for which we
> don't have clear and frequently-needed use cases in Emacs.  Emacs is
> not a general-purpose programming platform, it's mainly a platform for
> writing text-processing applications.

Many packages on melpa/elpa have a custom log function. I'm not familiar with 
the Emacs API, is there a standard way to log events? 
I think a simple log function would be useful for many packages.

Message #70 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: larsi <at> gnus.org, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#55163: 29.0.50;
 master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 14:25:31 +0300

> From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
> Cc: larsi <at> gnus.org, 55163 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Sat, 30 Apr 2022 13:21:04 +0200
> 
> In data sabato 30 aprile 2022 07:40:32 CEST, Eli Zaretskii ha scritto:
> > As I already said up-thread: let's not introduce APIs for which we
> > don't have clear and frequently-needed use cases in Emacs.  Emacs is
> > not a general-purpose programming platform, it's mainly a platform for
> > writing text-processing applications.
> 
> Many packages on melpa/elpa have a custom log function. I'm not familiar with 
> the Emacs API, is there a standard way to log events? 
> I think a simple log function would be useful for many packages.

Do you mean logging to the system log?

If not, then generating a log doesn't require any new primitives, I
think, you could just use write-region or something?

Or am I misunderstanding the feature you have in mind?

Message #73 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#55163: 29.0.50;
 master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 14:32:17 +0200

In data sabato 30 aprile 2022 13:25:31 CEST, Eli Zaretskii ha scritto:
> > From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
> > Cc: larsi <at> gnus.org, 55163 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> > Date: Sat, 30 Apr 2022 13:21:04 +0200
> > 
> > In data sabato 30 aprile 2022 07:40:32 CEST, Eli Zaretskii ha scritto:
> > > As I already said up-thread: let's not introduce APIs for which we
> > > don't have clear and frequently-needed use cases in Emacs.  Emacs is
> > > not a general-purpose programming platform, it's mainly a platform for
> > > writing text-processing applications.
> > 
> > Many packages on melpa/elpa have a custom log function. I'm not familiar
> > with the Emacs API, is there a standard way to log events?
> > I think a simple log function would be useful for many packages.
> 
> Do you mean logging to the system log?
> 
> If not, then generating a log doesn't require any new primitives, I
> think, you could just use write-region or something?
> 
> Or am I misunderstanding the feature you have in mind?

I mean something that can generate a properly formatted log message, in a 
"standard" way (with log levels, ERROR, WARNING, INFO etc, if possible), for 
both use cases if possible. Something like log4j, but not as monstrous as 
log4j.

Just three examples of different way to generate logging message:  
1. jsonrpc has a function, jsonrpc--log-event, that generates a message 
                          (msg (format "[%s]%s%s %s:\n%s"
                                   type
                                   (if id (format " (id:%s)" id) "")
                                   (if error " ERROR" "")
                                   (current-time-string)
                                   (pp-to-string message))))
2. treemacs (see treemacs-logging.el: one function and six macro)
3. the package log4e (on melpa)

The message format of these three packets is different.
Something more "standardized" may be useful, I think.

Message #76 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: larsi <at> gnus.org, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#55163: 29.0.50;
 master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 15:50:04 +0300

> From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, larsi <at> gnus.org, 55163 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Sat, 30 Apr 2022 14:32:17 +0200
> 
> > > Many packages on melpa/elpa have a custom log function. I'm not familiar
> > > with the Emacs API, is there a standard way to log events?
> > > I think a simple log function would be useful for many packages.
> > 
> > Do you mean logging to the system log?
> > 
> > If not, then generating a log doesn't require any new primitives, I
> > think, you could just use write-region or something?
> > 
> > Or am I misunderstanding the feature you have in mind?
> 
> I mean something that can generate a properly formatted log message, in a 
> "standard" way (with log levels, ERROR, WARNING, INFO etc, if possible), for 
> both use cases if possible. Something like log4j, but not as monstrous as 
> log4j.

Sure, why not?

Message #79 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#55163: 29.0.50;
 master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 15:22:12 +0200

In data sabato 30 aprile 2022 14:50:04 CEST, Eli Zaretskii ha scritto:
> > From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
> > Cc: eggert <at> cs.ucla.edu, larsi <at> gnus.org, 55163 <at> debbugs.gnu.org,
> > monnier <at> iro.umontreal.ca Date: Sat, 30 Apr 2022 14:32:17 +0200
> > 
> > > > Many packages on melpa/elpa have a custom log function. I'm not
> > > > familiar
> > > > with the Emacs API, is there a standard way to log events?
> > > > I think a simple log function would be useful for many packages.
> > > 
> > > Do you mean logging to the system log?
> > > 
> > > If not, then generating a log doesn't require any new primitives, I
> > > think, you could just use write-region or something?
> > > 
> > > Or am I misunderstanding the feature you have in mind?
> > 
> > I mean something that can generate a properly formatted log message, in a
> > "standard" way (with log levels, ERROR, WARNING, INFO etc, if possible),
> > for both use cases if possible. Something like log4j, but not as
> > monstrous as log4j.
> 
> Sure, why not?
Because log4j does too many things, and I think it's too much for emacs. I 
think something simpler is enough.

Message #82 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, v.pupillo <at> gmail.com,
 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 13:51:24 -0700

On 4/30/22 03:00, Eli Zaretskii wrote:

> That might mean we want a primitive that returns a list of files
> sorted by modtime

Such a primitive would not be as useful. First, it's common for Emacs to 
look at files opportunistically: that is, Emacs doesn't know in advance 
all the files it will eventually look at, and so it can't give a 
primitive a list of files in advance. Second, it's common for Emacs to 
compare the timestamp of a file at time T1 with the timestamp of another 
(or the same) file at a later time T2. A primitive that accepts a list 
of files can't do that.

In contrast, a primitive that simply gives you a file's timestamp 
handles these use cases, and is considerably easier to describe and support.

> we
> will risk adding gobs of new APIs that rarely if ever used in
> practice

Yes, we don't want to do that. However the case for making improvements 
here is strong enough here that it's worth doing.

There are dozens of potential uses for the proposed (file-attributes 
FILE 'mtime) etc. improvement in Emacs right now, so it's an easy call 
that this API will get used.

There are also cases where the code now uses current-time and assumes 
that the resulting timestamps are issued in numeric order, an assumption 
that is not always true in practice. It'd be better for this code to use 
a monotonic clock instead. Admittedly the resulting misbehavior is rare 
(because it's rare that people adjust their machines' clocks), but Emacs 
shouldn't glitch out on me merely because I've corrected my laptop's 
time-of-day.

Message #85 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>,
 55163 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sat, 30 Apr 2022 14:03:55 -0700

On 4/30/22 02:15, Lars Ingebrigtsen wrote:
>> * (clock-realtime) returns the system-wide clock. It acts like
>>    (time-convert nil t), i.e., like (current-time) but returning (TICKS
>>    . HZ) form.
> clock- as a prefix does make a lot of sense, but I think I'd interpret
> that as "realtime" as something having to do with scheduling

Yes, "realtime" is an unfortunate phrase here, even if it's POSIX. 
Perhaps we should use "universal" instead, since it's Universal Time.

Another thought is that instead of a new Lisp function, we could extend 
current-time. E.g., (current-time 'universal) would return the current 
time in seconds since the EPOCH, (current-time 'process-cpu) the 
process's CPU time, (current-time 'monotonic) a monotonic clock, etc. 
Although this wouldn't let us reorganize the time API in a major way, it 
would let us add the needed functionality in a way that follows existing 
practice pretty closely, and there's benefit to that.

Message #88 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 01 May 2022 08:38:39 +0300

> Date: Sat, 30 Apr 2022 13:51:24 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com,
>  Lars Ingebrigtsen <larsi <at> gnus.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 4/30/22 03:00, Eli Zaretskii wrote:
> 
> > That might mean we want a primitive that returns a list of files
> > sorted by modtime
> 
> Such a primitive would not be as useful. First, it's common for Emacs to 
> look at files opportunistically: that is, Emacs doesn't know in advance 
> all the files it will eventually look at, and so it can't give a 
> primitive a list of files in advance.

In those cases, a Lisp program usually doesn't know whether it will
sort files by time or by some other attribute, so we generally need
the list of files with all their attributes anyway.

> Second, it's common for Emacs to compare the timestamp of a file at
> time T1 with the timestamp of another (or the same) file at a later
> time T2. A primitive that accepts a list of files can't do that.

Please show at least 3 examples of such "common" situations.  I think
it is rather UN-common.

> In contrast, a primitive that simply gives you a file's timestamp 
> handles these use cases, and is considerably easier to describe and support.

Really? what's the problem to describe and support a primitive that
returns a sorted list of files?

> > we
> > will risk adding gobs of new APIs that rarely if ever used in
> > practice
> 
> Yes, we don't want to do that. However the case for making improvements 
> here is strong enough here that it's worth doing.

That's your opinion, not mine.  I will object to introducing such
"simple" primitives as long as the use cases for them aren't common
enough, or are better served by dedicated primitives that address
the specific use cases we care about.

People who want a general-purpose Lisp environment for writing
system-level applications should use Guile, not Emacs Lisp.

> There are dozens of potential uses for the proposed (file-attributes 
> FILE 'mtime) etc. improvement in Emacs right now, so it's an easy call 
> that this API will get used.

I challenge you to present even half a dozen of such uses.

> There are also cases where the code now uses current-time and assumes 
> that the resulting timestamps are issued in numeric order, an assumption 
> that is not always true in practice. It'd be better for this code to use 
> a monotonic clock instead. Admittedly the resulting misbehavior is rare 
> (because it's rare that people adjust their machines' clocks), but Emacs 
> shouldn't glitch out on me merely because I've corrected my laptop's 
> time-of-day.

That's a separate issue, and again: please present the use cases for
that which are relevant to Emacs applications.

Message #91 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 01 May 2022 08:40:51 +0300

> Date: Sat, 30 Apr 2022 14:03:55 -0700
> Cc: 55163 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>  Vincenzo Pupillo <v.pupillo <at> gmail.com>,
>  Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 4/30/22 02:15, Lars Ingebrigtsen wrote:
> >> * (clock-realtime) returns the system-wide clock. It acts like
> >>    (time-convert nil t), i.e., like (current-time) but returning (TICKS
> >>    . HZ) form.
> > clock- as a prefix does make a lot of sense, but I think I'd interpret
> > that as "realtime" as something having to do with scheduling
> 
> Yes, "realtime" is an unfortunate phrase here, even if it's POSIX. 
> Perhaps we should use "universal" instead, since it's Universal Time.

Using "universal" will IMO make the discovery even more difficult,
because no one will think of looking up time functions under
"universal".

> Another thought is that instead of a new Lisp function, we could extend 
> current-time. E.g., (current-time 'universal) would return the current 
> time in seconds since the EPOCH, (current-time 'process-cpu) the 
> process's CPU time, (current-time 'monotonic) a monotonic clock, etc. 
> Although this wouldn't let us reorganize the time API in a major way, it 
> would let us add the needed functionality in a way that follows existing 
> practice pretty closely, and there's benefit to that.

That could be a good idea, but thinking about names, I still don't
understand why we don't want to use "time-" as the prefix of these
APIs.  What did I miss?

Message #94 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 1 May 2022 08:00:05 -0700

On 4/30/22 22:38, Eli Zaretskii wrote:
>> it's common for Emacs to compare the timestamp of a file at
>> time T1 with the timestamp of another (or the same) file at a later
>> time T2.

> Please show at least 3 examples of such "common" situations.  I think
> it is rather UN-common.

auth-source-netrc-parse, semanticdb-synchronize, and dir-locals-find-file.


> what's the problem to describe and support a primitive that
> returns a sorted list of files?

What happens with ties in the timestamps - do we sort stably? What 
happens with files named but not present? What if we want to sort by 
ctime instead of by mtime? What if the user is involved in selecting 
files as we go? How do we specify the files: a list of strings, a 
pattern, or something else? What if we want to look at a tree of files? Etc.

Of course one could come up with answers to those questions, but this 
sort of thing is much better handled in Lisp code than as a C-language 
primitive.


> I challenge you to present even half a dozen of such uses.

I listed three examples above. Here are three more, which makes six: 
multisession-backend-value, eshell-read-passwd, 
nneething-create-mapping. More examples can easily be supplied.


>> There are also cases where the code now uses current-time and assumes
>> that the resulting timestamps are issued in numeric order, an assumption
>> that is not always true in practice.
> 
> That's a separate issue, and again: please present the use cases for
> that which are relevant to Emacs applications.

erc-server-send-ping, progress-reporter-do-update, timer-event-handler. 
I'm sure there are others.


Your point is well taken that if we made changes along the lines being 
discussed, we shouldn't merely add the new primitives: we should *use* 
them. And if we can't find significant use for them then we shouldn't 
add them.

Message #97 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 1 May 2022 08:08:00 -0700

On 4/30/22 22:40, Eli Zaretskii wrote:

> Using "universal" will IMO make the discovery even more difficult,
> because no one will think of looking up time functions under
> "universal".

Yes, it shouldn't be "universal" by itself. It should be (time-now 
'universal) or something like that, where the context is clear.

I did consider "UTC"; unfortunately something like (time-now 'UTC) would 
imply that the timestamps include leap seconds, which they typically 
don't. "Universal" is a more-general term that includes both UTC and 
POSIX time (the latter omits leap seconds).

..
> I still don't
> understand why we don't want to use "time-" as the prefix of these
> APIs.

Sure, we can stick with "time-" for new functions.

Message #100 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 01 May 2022 18:42:04 +0300

> Date: Sun, 1 May 2022 08:00:05 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com, larsi <at> gnus.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 4/30/22 22:38, Eli Zaretskii wrote:
> >> it's common for Emacs to compare the timestamp of a file at
> >> time T1 with the timestamp of another (or the same) file at a later
> >> time T2.
> 
> > Please show at least 3 examples of such "common" situations.  I think
> > it is rather UN-common.
> 
> auth-source-netrc-parse, semanticdb-synchronize, and dir-locals-find-file.

Out of these, only the 3rd one could qualify, because it's the only
one where performance counts.

> > what's the problem to describe and support a primitive that
> > returns a sorted list of files?
> 
> What happens with ties in the timestamps - do we sort stably? What 
> happens with files named but not present? What if we want to sort by 
> ctime instead of by mtime? What if the user is involved in selecting 
> files as we go? How do we specify the files: a list of strings, a 
> pattern, or something else? What if we want to look at a tree of files? Etc.

I see no problems there that are worth talking about.

> Of course one could come up with answers to those questions, but this 
> sort of thing is much better handled in Lisp code than as a C-language 
> primitive.

And then those issues will have to be handled by Lisp application
programmers? who in many cases will not even know these issues exist?
Is that really a good trade-off?

> > I challenge you to present even half a dozen of such uses.
> 
> I listed three examples above. Here are three more, which makes six: 
> multisession-backend-value, eshell-read-passwd, 
> nneething-create-mapping. More examples can easily be supplied.

Only performance-critical examples count.  Any function that involves
user interaction by definition isn't.

> >> There are also cases where the code now uses current-time and assumes
> >> that the resulting timestamps are issued in numeric order, an assumption
> >> that is not always true in practice.
> > 
> > That's a separate issue, and again: please present the use cases for
> > that which are relevant to Emacs applications.
> 
> erc-server-send-ping, progress-reporter-do-update, timer-event-handler. 
> I'm sure there are others.

We don't need wallclock time for those, only elapsed time since some
instant, right?  When elapsed time is used, the monotonicity issue
never arises.

> Your point is well taken that if we made changes along the lines being 
> discussed, we shouldn't merely add the new primitives: we should *use* 
> them. And if we can't find significant use for them then we shouldn't 
> add them.

Yes, that's my point.  So we should look at this from the POV of what
will be used, not what can be provided.

Message #103 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 1 May 2022 09:17:09 -0700

On 5/1/22 08:42, Eli Zaretskii wrote:

> Out of these, only the 3rd one could qualify, because it's the only
> one where performance counts.

I'm sure other places can be found like that. And even one such 
occurrence can be enough motivation.


> And then those issues will have to be handled by Lisp application
> programmers?

No, not at all. We could write the code in Elisp and put it into 
files.el or wherever. The point is that this sort of thing need not and 
should not be written in C.


>> erc-server-send-ping, progress-reporter-do-update, timer-event-handler.
>> I'm sure there are others.
> 
> We don't need wallclock time for those, only elapsed time since some
> instant, right?  When elapsed time is used, the monotonicity issue
> never arises.

I'm not sure what is meant by the distinction between a monotonic clock 
and an elapsed-time clock. Either way, current-time does not suffice.

GNU/Linux has many types of monotonic clocks. We don't need to expose 
them all to the user. But Emacs apps do need at least one such clock, 
and POSIX's CLOCK_MONOTONIC is a portable way to get one.

Message #106 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Sun, 01 May 2022 19:43:08 +0300

> Date: Sun, 1 May 2022 09:17:09 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com, larsi <at> gnus.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 5/1/22 08:42, Eli Zaretskii wrote:
> 
> > Out of these, only the 3rd one could qualify, because it's the only
> > one where performance counts.
> 
> I'm sure other places can be found like that. And even one such 
> occurrence can be enough motivation.

No, one such occurrence won't be enough, not in my book.

> > And then those issues will have to be handled by Lisp application
> > programmers?
> 
> No, not at all. We could write the code in Elisp and put it into 
> files.el or wherever. The point is that this sort of thing need not and 
> should not be written in C.

What's the difference, for the purpose of this discussion, between
having the code in C and having it in internal Lisp functions?  The
important conclusion is the same: no need for public APIs that expose
individual attributes.

> >> erc-server-send-ping, progress-reporter-do-update, timer-event-handler.
> >> I'm sure there are others.
> > 
> > We don't need wallclock time for those, only elapsed time since some
> > instant, right?  When elapsed time is used, the monotonicity issue
> > never arises.
> 
> I'm not sure what is meant by the distinction between a monotonic clock 
> and an elapsed-time clock. Either way, current-time does not suffice.

The distinction is that the resolution of the wallclock time doesn't
matter.

> GNU/Linux has many types of monotonic clocks. We don't need to expose 
> them all to the user. But Emacs apps do need at least one such clock, 
> and POSIX's CLOCK_MONOTONIC is a portable way to get one.

What we have established is that Emacs apps need to be able to measure
time intervals, not that they need a monotonic clock.  Functions for
measuring time intervals can be built on functions that return
monotonic clock time, but they can also be built on other bases that
have very little with actual time stamps.

Message #109 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Mon, 2 May 2022 10:27:14 -0700

On 5/1/22 09:43, Eli Zaretskii wrote:

> one such occurrence won't be enough, not in my book.

If one such occurrence makes Emacs significantly slower for a 
common-enough use, it can be important enough to improve Emacs. And as I 
wrote, I'm sure there are more occurrences.


> What's the difference, for the purpose of this discussion, between
> having the code in C and having it in internal Lisp functions?

The internal Lisp function would need an efficient way to get a file's 
timestamp. It can't do that if there's no C primitive to do it.


> What we have established is that Emacs apps need to be able to measure
> time intervals, not that they need a monotonic clock.  Functions for
> measuring time intervals can be built on functions that return
> monotonic clock time, but they can also be built on other bases that
> have very little with actual time stamps.

What other bases would these be? Monotonic clocks are relatively 
portable; other methods that come to mind are not.

Message #112 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Mon, 02 May 2022 20:58:10 +0300

> Date: Mon, 2 May 2022 10:27:14 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com, larsi <at> gnus.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> > What's the difference, for the purpose of this discussion, between
> > having the code in C and having it in internal Lisp functions?
> 
> The internal Lisp function would need an efficient way to get a file's 
> timestamp. It can't do that if there's no C primitive to do it.

And this is relevant to this discussion because...?

The discussion, to remind you, was whether we should provide _public_
APIs to obtain individual attributes, as opposed to providing more
high-level public APIs that serve specific important use cases of
using those attributes, without exposing those attributes.

> > What we have established is that Emacs apps need to be able to measure
> > time intervals, not that they need a monotonic clock.  Functions for
> > measuring time intervals can be built on functions that return
> > monotonic clock time, but they can also be built on other bases that
> > have very little with actual time stamps.
> 
> What other bases would these be? Monotonic clocks are relatively 
> portable; other methods that come to mind are not.

As long as such a method exists on a platform, that platform can make
do without high-resolution wallclock time.

Message #115 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Mon, 2 May 2022 16:17:38 -0700

On 5/2/22 10:58, Eli Zaretskii wrote:
>> The internal Lisp function would need an efficient way to get a file's
>> timestamp. It can't do that if there's no C primitive to do it.
> And this is relevant to this discussion because...?
> 
> The discussion, to remind you, was whether we should provide_public_
> APIs to obtain individual attributes

If the concern is the public nature of the API then yes, we could 
provide a private function file--attributes that would act like 
file-attributes but be able to obtain individual attributes.


>>> What we have established is that Emacs apps need to be able to measure
>>> time intervals, not that they need a monotonic clock.  Functions for
>>> measuring time intervals can be built on functions that return
>>> monotonic clock time, but they can also be built on other bases that
>>> have very little with actual time stamps.
>> What other bases would these be? Monotonic clocks are relatively
>> portable; other methods that come to mind are not.
> As long as such a method exists on a platform, that platform can make
> do without high-resolution wallclock time.

Sorry, I'm still lost. What methods would these be? Are they methods 
that one can already use in portable Elisp code?

Message #118 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Tue, 03 May 2022 05:32:39 +0300

> Date: Mon, 2 May 2022 16:17:38 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com, larsi <at> gnus.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> >>> What we have established is that Emacs apps need to be able to measure
> >>> time intervals, not that they need a monotonic clock.  Functions for
> >>> measuring time intervals can be built on functions that return
> >>> monotonic clock time, but they can also be built on other bases that
> >>> have very little with actual time stamps.
> >> What other bases would these be? Monotonic clocks are relatively
> >> portable; other methods that come to mind are not.
> > As long as such a method exists on a platform, that platform can make
> > do without high-resolution wallclock time.
> 
> Sorry, I'm still lost. What methods would these be?

For example, measuring time intervals by looking at CPU counters.

> Are they methods that one can already use in portable Elisp code?

No, because we were talking about APIs that are not yet available in
Emacs.

Message #121 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Mon, 2 May 2022 19:52:23 -0700

On 5/2/22 19:32, Eli Zaretskii wrote:
> For example, measuring time intervals by looking at CPU counters.

That might be a way to do its, though it sounds a bit complicated since 
these days CPUs often don't run at a constant rate. And not every system 
lets you look at its CPU counters.

I suppose Emacs could use CLOCK_MONOTONIC on systems that have it, and 
fall back on CPU counters on systems that don't.

Previous Next

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