From unknown Fri Aug 15 16:17:48 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55163 <55163@debbugs.gnu.org> To: bug#55163 <55163@debbugs.gnu.org> Subject: Status: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Reply-To: bug#55163 <55163@debbugs.gnu.org> Date: Fri, 15 Aug 2025 23:17:48 +0000 retitle 55163 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time brok= e lsp-mode reassign 55163 emacs submitter 55163 Vincenzo Pupillo severity 55163 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 06:54:50 2022 Received: (at submit) by debbugs.gnu.org; 28 Apr 2022 10:54:50 +0000 Received: from localhost ([127.0.0.1]:45551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk1nN-0002Qb-RN for submit@debbugs.gnu.org; Thu, 28 Apr 2022 06:54:50 -0400 Received: from lists.gnu.org ([209.51.188.17]:46800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk1nM-0002QT-0b for submit@debbugs.gnu.org; Thu, 28 Apr 2022 06:54:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk1nL-00051g-LA for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2022 06:54:47 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:39699) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nk1nH-0002x4-RW for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2022 06:54:47 -0400 Received: by mail-ed1-x52e.google.com with SMTP id g20so5045281edw.6 for ; Thu, 28 Apr 2022 03:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:mime-version; bh=wQJvc+Xe2ps3IYtwPL7eM6vENUopexseUdhpDFL08zQ=; b=Somd8uqzlKMK/ZPW10cyoag/ZlycFN9RA1zap3LqYAzrp2Q57DSxBvfsHk0cj6X5D6 oszT/u1PcBm9WtpcQ5nc4wfW3rT2+UeYzfBw+YeSM45dKbgRa0YHLltjnw40pIwLCB4z abxHUDAXQWvGnsOZy0BxSaE+fJ7eZ6o3hKYm1OwjtQanLI7TwHa2PQHGiNXvt0XtUlmA LPr9nDL5ffAdbhJkHbAS/imN1hQ2UobXnsWZ/lJgSYjc7TSDOFf71jClA3pbwFVANZXQ Ju/odPDE4mEkESICUxmaJGO5/j0NGpxgpsZBw9gknMCgrxZ2LbIlYM8iJGewv6P2yy2G MWLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=wQJvc+Xe2ps3IYtwPL7eM6vENUopexseUdhpDFL08zQ=; b=8CJd4jFs2nwz26V0fXZSGSg1+KY0vvCUaaRuoBruG/rif/7E/AJ+oMBNTFO2mpLWZ/ 7wkEXAVkYO43oCeHJ368HadeS7zUg/hrFJZQj+14hhQqzjl4OrJrp5GW62av+T3HFYvw pkwOg6QN/PUI9MQg9pBAMBBOQrykxp83oPwYY5oc9GtNlndzqyzR2sxs8Unk3VXjDcnu l/rvho6RSvyUDYkrOso38Nl+cZURYc0GuWJAaK26M1o3iBGxKHUkdjdQ3mD4M8Und5tH ju4GFHPUbuxKc7NCPwJYIuuK3q6KMvWhZ5HGuSK0M/Cf9z5GTEj9qzx0nyDeyABMo1YM cW2A== X-Gm-Message-State: AOAM533yHB0QUo47/OiflO5yxOi8Tb7/3Wk9w7mWavtp4roFzP1fc7C1 69YXKKTEanbizn9QtbUwHN/7U5/vagk= X-Google-Smtp-Source: ABdhPJw8t7P3VuDpYwmyBgQTHyv5AzU7ID3zRz6kE7Yb1ECA0t5l07whnWrc7+PHv6mVD3M2Fa4LAw== X-Received: by 2002:a05:6402:2394:b0:425:ee16:77f4 with SMTP id j20-20020a056402239400b00425ee1677f4mr19850108eda.197.1651143281837; Thu, 28 Apr 2022 03:54:41 -0700 (PDT) Received: from 3-191.divsi.unimi.it (3-191.divsi.unimi.it. [159.149.3.191]) by smtp.gmail.com with ESMTPSA id hf3-20020a1709072c4300b006f392c2bf71sm5646248ejc.175.2022.04.28.03.54.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 03:54:41 -0700 (PDT) From: Vincenzo Pupillo To: bug-gnu-emacs@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 Message-ID: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::52e; envelope-from=v.pupillo@gmail.com; helo=mail-ed1-x52e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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)) From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 08:11:16 2022 Received: (at 55163) by debbugs.gnu.org; 28 Apr 2022 12:11:16 +0000 Received: from localhost ([127.0.0.1]:45695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2zM-0006vJ-29 for submit@debbugs.gnu.org; Thu, 28 Apr 2022 08:11:16 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2zK-0006v6-GH for 55163@debbugs.gnu.org; Thu, 28 Apr 2022 08:11:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OQ5c4H/fwEMDucOebnbAWAKYQRMk3Xdcq88YVItC3ng=; b=Lp8C80uWvUQbB0J0WCaQOtjzLm 8yPC322F88mnlRMdY841fIkLduzrIzvhiEYzL1gF2l/VuwWf9A1INXd8DkgbAac4DXsMScCSC9+Hd VfpE/NGa3ETkmNClL1P/FSCdO5uzKW+PPyG4NCe9YJpVHhqi69iOQOXowGkcEIQ8hWLc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2z4-0000W5-8B; Thu, 28 Apr 2022 14:11:00 +0200 From: Lars Ingebrigtsen To: Vincenzo Pupillo Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> X-Now-Playing: Ms. John Soda's _Loom_: "The Light" Date: Thu, 28 Apr 2022 14:10:57 +0200 In-Reply-To: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> (Vincenzo Pupillo's message of "Thu, 28 Apr 2022 12:53:44 +0200") Message-ID: <87zgk5jtm6.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Vincenzo Pupillo 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 lo [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Paul Eggert , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Vincenzo Pupillo 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 09:38:57 2022 Received: (at 55163) by debbugs.gnu.org; 28 Apr 2022 13:38:57 +0000 Received: from localhost ([127.0.0.1]:45815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4MD-00054g-5m for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:38:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4MB-00054T-0L for 55163@debbugs.gnu.org; Thu, 28 Apr 2022 09:38:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4M4-0002Cv-Vd; Thu, 28 Apr 2022 09:38:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=H+ssUpTNFCddooNI9EUscCsW2nLJzQabfjGC9Kio4QQ=; b=nZpD9mI8WOs4 bOBfHlypB3m53rbAQrrSM0T6mR1zBX8vQOJml7wKVdcO4EByjogPNFhRCND5ltJZXs8+cWBEXl0Wm OLvGjxH+RWmKAQtdOsXgeN1nS0WVOvCRte6oJRs23OovByYD8bOpN7mqkBHGWMwsrEt2kYZC1NxhT 4Ft/apF5IxpyStgnf7aeHlAixrXFjKmDVDRcTIxN35kK+dV2cmvUMcLWunbExYr9mWSKBjM954sDf gJc54+QJJH1HHnL3jfafYDVuMJKXItP0M273lcJISuuF2vGjlOBBOwqESirgwOOUROxi1pPrK6wo9 fGv2aRThOPn3jf8FD/GNpA==; Received: from [87.69.77.57] (port=2686 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4M4-00016P-Ef; Thu, 28 Apr 2022 09:38:48 -0400 Date: Thu, 28 Apr 2022 16:38:47 +0300 Message-Id: <83fslxba54.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87zgk5jtm6.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 28 Apr 2022 14:10:57 +0200) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, 55163@debbugs.gnu.org, eggert@cs.ucla.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 55163@debbugs.gnu.org, Paul Eggert , Eli Zaretskii > > Date: Thu, 28 Apr 2022 14:10:57 +0200 > > Vincenzo Pupillo 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 16:16:07 2022 Received: (at 55163) by debbugs.gnu.org; 28 Apr 2022 20:16:07 +0000 Received: from localhost ([127.0.0.1]:50067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkAYY-00064e-N2 for submit@debbugs.gnu.org; Thu, 28 Apr 2022 16:16:07 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkAYU-00063t-U2 for 55163@debbugs.gnu.org; Thu, 28 Apr 2022 16:16:05 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 84B8B1600C0; Thu, 28 Apr 2022 13:15:57 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0AApXfHaRrCm; Thu, 28 Apr 2022 13:15:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D57031600F4; Thu, 28 Apr 2022 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0L3OIqpkEfDK; Thu, 28 Apr 2022 13:15:55 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AFBEB1600C0; Thu, 28 Apr 2022 13:15:55 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------EJDWBR5HCECe50pcMHAv0nPT" Message-ID: Date: Thu, 28 Apr 2022 13:15:54 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Content-Language: en-US To: Lars Ingebrigtsen References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <87zgk5jtm6.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Vincenzo Pupillo , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------EJDWBR5HCECe50pcMHAv0nPT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------EJDWBR5HCECe50pcMHAv0nPT Content-Type: text/x-patch; charset=UTF-8; name="0001-Change-current-time-back-to-list-form.patch" Content-Disposition: attachment; filename="0001-Change-current-time-back-to-list-form.patch" Content-Transfer-Encoding: base64 RnJvbSAwODNkMjcwOGY5ZWM3ZjA5NzEyNDg4YTk5ZmM5ZWVkZDNkNTk0ZmY2IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBUaHUsIDI4IEFwciAyMDIyIDEyOjUwOjM5IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gQ2hhbmdlIGN1cnJlbnQtdGltZSBiYWNrIHRvIGxpc3QgZm9ybQoKQ2hhbmdlIGN1cnJl bnQtdGltZSBhbmQgcmVsYXRlZCBmdW5jdGlvbnMgYmFjayB0byB1c2luZyB0aGUKdHJhZGl0 aW9uYWwgbGlzdCBmb3JtLiAgQWxzbywgYWRkIGEgbmV3IGJvb2xlYW4gdmFyaWFibGUKY3Vy cmVudC10aW1lLWxpc3QgdGhhdCBsZXRzIHBlb3BsZSB0cnkgb3V0IChUSUNLUyAuIEhaKSBm b3JtLAp3aXRoIHRoZSBnb2FsIG9mIHNtb290aGluZyB0aGUgdHJhbnNpdGlvbi4KKiBzcmMv dGltZWZucy5jIChDVVJSRU5UX1RJTUVfTElTVCk6IENoYW5nZSBkZWZhdWx0IGJhY2sgdG8g dHJ1ZS4KKGN1cnJlbnQtdGltZS1saXN0KTogTmV3IGJvb2xlYW4gTGlzcCB2YXJpYWJsZSwg d2hpY2ggZGVmYXVsdHMgdG8KQ1VSUkVOVF9USU1FX0xJU1QuICBBbGwgdXNlcyBvZiBDVVJS RU5UX1RJTUVfTElTVCBjaGFuZ2VkIHRvCnVzZSBjdXJyZW50X3RpbWVfbGlzdCwgYW5kIGFs bCBkb2N1bWVudGF0aW9uIGNoYW5nZWQuCi0tLQogZG9jL2xpc3BpbnRyby9lbWFjcy1saXNw LWludHJvLnRleGkgfCAgOSArKysrLS0KIGRvYy9saXNwcmVmL2ZpbGVzLnRleGkgICAgICAg ICAgICAgIHwgMjQgKysrKysrKysrLS0tLS0tCiBkb2MvbGlzcHJlZi9pbnRyby50ZXhpICAg ICAgICAgICAgICB8ICA0ICsrLQogZG9jL2xpc3ByZWYvb3MudGV4aSAgICAgICAgICAgICAg ICAgfCAyOSArKysrKysrKysrKysrLS0tLQogZXRjL05FV1MgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAxNSArKysrKy0tLS0KIHNyYy90aW1lZm5zLmMgICAgICAgICAgICAgICAg ICAgICAgIHwgNDggKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0KIDYgZmlsZXMgY2hh bmdlZCwgODcgaW5zZXJ0aW9ucygrKSwgNDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv ZG9jL2xpc3BpbnRyby9lbWFjcy1saXNwLWludHJvLnRleGkgYi9kb2MvbGlzcGludHJvL2Vt YWNzLWxpc3AtaW50cm8udGV4aQppbmRleCBhZmFlZDEwY2RmLi4wNDljOGE2NWE4IDEwMDY0 NAotLS0gYS9kb2MvbGlzcGludHJvL2VtYWNzLWxpc3AtaW50cm8udGV4aQorKysgYi9kb2Mv bGlzcGludHJvL2VtYWNzLWxpc3AtaW50cm8udGV4aQpAQCAtMTUzNDMsOSArMTUzNDMsMTIg QEAgRmlsZXMgTGlzdAogMTAwCiBAZW5kIGdyb3VwCiBAZ3JvdXAKLSgxMzUxMDUxNjc0NTc5 OTg5Njk3IC4gMTAwMDAwMDAwMCkKLSgxMTczNDc3NzYxMDAwMDAwMDAwIC4gMTAwMDAwMDAw MCkKLSgxMzUxMDUwOTY3NzM0NzkxODA1IC4gMTAwMDAwMDAwMCkKKygyMDYxNSAyNzAzNCA1 Nzk5ODkgNjk3MDAwKQorKDE3OTA1IDU1NjgxIDAgMCkKKygyMDYxNSAyNjMyNyA3MzQ3OTEg ODA1MDAwKUBmb290bm90ZXtJZiBAY29kZXtjdXJyZW50LXRpbWUtbGlzdH0gaXMKK0Bjb2Rl e25pbH0gdGhlIHRocmVlIHRpbWVzdGFtcHMgYXJlIEBjb2RleygxMzUxMDUxNjc0NTc5OTg5 Njk3CisuIDEwMDAwMDAwMDApfSwgQGNvZGV7KDExNzM0Nzc3NjEwMDAwMDAwMDAgLiAxMDAw MDAwMDAwKX0sIGFuZAorQGNvZGV7KDEzNTEwNTA5Njc3MzQ3OTE4MDUgLiAxMDAwMDAwMDAw KX0sIHJlc3BlY3RpdmVseS59CiAxMzE4OAogIi1ydy1yLS1yLS0iCiBAZW5kIGdyb3VwCmRp ZmYgLS1naXQgYS9kb2MvbGlzcHJlZi9maWxlcy50ZXhpIGIvZG9jL2xpc3ByZWYvZmlsZXMu dGV4aQppbmRleCA0Mzk0ZjY0YTMyLi43NTkwNTY1OGU2IDEwMDY0NAotLS0gYS9kb2MvbGlz cHJlZi9maWxlcy50ZXhpCisrKyBiL2RvYy9saXNwcmVmL2ZpbGVzLnRleGkKQEAgLTE0MjMs OSArMTQyMyw5IEBAIEZpbGUgQXR0cmlidXRlcwogQGdyb3VwCiAoZmlsZS1hdHRyaWJ1dGVz ICJmaWxlcy50ZXhpIiAnc3RyaW5nKQogICAgICBAcmVzdWx0e30gIChuaWwgMSAibGgiICJ1 c2VycyIKLSAgICAgICAgICAoMTM1MTAyMzEyMzA1MDA0MDE1MiAuIDEwMDAwMDAwMDApCi0g ICAgICAgICAgKDEzMTA3MjAwMjMwMDAwMDAwMDAgLiAxMDAwMDAwMDAwKQotICAgICAgICAg ICgxMzUxMDIzNjU5OTAyMjg5ODcyIC4gMTAwMDAwMDAwMCkKKyAgICAgICAgICAoMjA2MTQg NjQwMTkgNTAwNDAgMTUyMDAwKQorICAgICAgICAgICgyMDAwMCAyMyAwIDApCisgICAgICAg ICAgKDIwNjE0IDY0NTU1IDkwMjI4OSA4NzIwMDApCiAgICAgICAgICAgMTIyMjk1ICItcnct cnctcnctIgogICAgICAgICAgIHQgNjQ3MzkyNDQ2NDUyMDEzOAogICAgICAgICAgIDEwMTQ0 Nzg0NjgpCkBAIC0xNDQ5LDE0ICsxNDQ5LDIwIEBAIEZpbGUgQXR0cmlidXRlcwogQGl0ZW0g InVzZXJzIgogaXMgaW4gdGhlIGdyb3VwIHdpdGggbmFtZSBAc2FtcHt1c2Vyc30uCiAKLUBp dGVtICgxMzUxMDIzMTIzMDUwMDQwMTUyIC4gMTAwMDAwMDAwMCkKLXdhcyBsYXN0IGFjY2Vz c2VkIG9uIE9jdG9iZXIgMjMsIDIwMTIsIGF0IDIwOjEyOjAzLjA1MDA0MDE1MiBVVEMuCitA aXRlbSAoMjA2MTQgNjQwMTkgNTAwNDAgMTUyMDAwKQord2FzIGxhc3QgYWNjZXNzZWQgb24g T2N0b2JlciAyMywgMjAxMiwgYXQgMjA6MTI6MDMuMDUwMDQwMTUyIFVUQ0AuCisoVGhpcyB0 aW1lc3RhbXAgaXMgQGNvZGV7KDEzNTEwMjMxMjMwNTAwNDAxNTIgLiAxMDAwMDAwMDAwKX0K K2lmIEBjb2Rle2N1cnJlbnQtdGltZS1saXN0fSBpcyBAY29kZXtuaWx9LikKIAotQGl0ZW0g KDEzMTA3MjAwMjMwMDAwMDAwMDAgLiAxMDAwMDAwMDAwKQotd2FzIGxhc3QgbW9kaWZpZWQg b24gSnVseSAxNSwgMjAwMSwgYXQgMDg6NTM6NDMuMDAwMDAwMDAwIFVUQy4KK0BpdGVtICgy MDAwMCAyMyAwIDApCit3YXMgbGFzdCBtb2RpZmllZCBvbiBKdWx5IDE1LCAyMDAxLCBhdCAw ODo1Mzo0My4wMDAwMDAwMDAgVVRDQC4KKyhUaGlzIHRpbWVzdGFtcCBpcyBAY29kZXsoMTMx MDcyMDAyMzAwMDAwMDAwMCAuIDEwMDAwMDAwMDApfQoraWYgQGNvZGV7Y3VycmVudC10aW1l LWxpc3R9IGlzIEBjb2Rle25pbH0uKQogCi1AaXRlbSAoMTM1MTAyMzY1OTkwMjI4OTg3MiAu IDEwMDAwMDAwMDApCi1sYXN0IGhhZCBpdHMgc3RhdHVzIGNoYW5nZWQgb24gT2N0b2JlciAy MywgMjAxMiwgYXQgMjA6MjA6NTkuOTAyMjg5ODcyIFVUQy4KK0BpdGVtICgyMDYxNCA2NDU1 NSA5MDIyODkgODcyMDAwKQorbGFzdCBoYWQgaXRzIHN0YXR1cyBjaGFuZ2VkIG9uIE9jdG9i ZXIgMjMsIDIwMTIsIGF0IDIwOjIwOjU5LjkwMjI4OTg3MiBVVENALgorKFRoaXMgdGltZXN0 YW1wIGlzIEBjb2RleygxMzUxMDIzNjU5OTAyMjg5ODcyIC4gMTAwMDAwMDAwMCl9CitpZiBA Y29kZXtjdXJyZW50LXRpbWUtbGlzdH0gaXMgQGNvZGV7bmlsfS4pCiAKIEBpdGVtIDEyMjI5 NQogaXMgMTIyMjk1IGJ5dGVzIGxvbmcuICAoSXQgbWF5IG5vdCBjb250YWluIDEyMjI5NSBj aGFyYWN0ZXJzLCB0aG91Z2gsCmRpZmYgLS1naXQgYS9kb2MvbGlzcHJlZi9pbnRyby50ZXhp IGIvZG9jL2xpc3ByZWYvaW50cm8udGV4aQppbmRleCBkMWEzZmVmN2E0Li45NzUyMTVkNjk3 IDEwMDY0NAotLS0gYS9kb2MvbGlzcHJlZi9pbnRyby50ZXhpCisrKyBiL2RvYy9saXNwcmVm L2ludHJvLnRleGkKQEAgLTUwMyw5ICs1MDMsMTEgQEAgVmVyc2lvbiBJbmZvCiBAZXhhbXBs ZQogQGdyb3VwCiBlbWFjcy1idWlsZC10aW1lCi0gICAgIEByZXN1bHR7fSAoMTY1MDIyODkw MjYzNzAzODgzMSAuIDEwMDAwMDAwMDApCisgICAgIEByZXN1bHR7fSAoMjUxOTQgNTU4OTQg ODU0NyA2MTcwMDApCiBAZW5kIGdyb3VwCiBAZW5kIGV4YW1wbGUKKyhUaGlzIHRpbWVzdGFt cCBpcyBAY29kZXsoMTY1MTE2OTg3ODAwODU0NzYxNyAuIDEwMDAwMDAwMDApfQoraWYgQGNv ZGV7Y3VycmVudC10aW1lLWxpc3R9IHdhcyBAY29kZXtuaWx9IHdoZW4gRW1hY3Mgd2FzIGJ1 aWx0LikKIEBlbmQgZGVmdmFyCiAKIEBkZWZ2YXIgZW1hY3MtdmVyc2lvbgpkaWZmIC0tZ2l0 IGEvZG9jL2xpc3ByZWYvb3MudGV4aSBiL2RvYy9saXNwcmVmL29zLnRleGkKaW5kZXggODlk ZGYxNjRhMS4uMjBiNmMxY2VjNiAxMDA2NDQKLS0tIGEvZG9jL2xpc3ByZWYvb3MudGV4aQor KysgYi9kb2MvbGlzcHJlZi9vcy50ZXhpCkBAIC0xMzU5LDYgKzEzNTksMTAgQEAgVGltZSBv ZiBEYXkKIEB0ZXgKICRoaWdoIFx0aW1lcyAyXnsxNn0gKyBsb3cgKyBtaWNybyBcdGltZXMg MTBeey02fSArIHBpY28gXHRpbWVzIDEwXnstMTJ9JC4KIEBlbmQgdGV4CitJZiBAY29kZXtj dXJyZW50LXRpbWUtbGlzdH0gaXMgQGNvZGV7dH0sCitzb21lIGZ1bmN0aW9ucyBtYXkgZGVm YXVsdCB0byByZXR1cm5pbmcgdHdvLSBvcgordGhyZWUtZWxlbWVudCBsaXN0cywgd2l0aCBv bWl0dGVkIEB2YXJ7bWljcm99IGFuZCBAdmFye3BpY299Citjb21wb25lbnRzIGRlZmF1bHRp bmcgdG8gemVyby4KIE9uIGFsbCBjdXJyZW50IG1hY2hpbmVzIEB2YXJ7cGljb30gaXMgYSBt dWx0aXBsZSBvZiAxMDAwLCBidXQgdGhpcwogbWF5IGNoYW5nZSBhcyBoaWdoZXItcmVzb2x1 dGlvbiBjbG9ja3MgYmVjb21lIGF2YWlsYWJsZS4KIEBlbmQgaXRlbWl6ZQpAQCAtMTQxMCwx NSArMTQxNCwyOCBAQCBUaW1lIG9mIERheQogQGVuZCBleGFtcGxlCiBAZW5kIGRlZnVuCiAK K0BkZWZ2YXIgY3VycmVudC10aW1lLWxpc3QKK1RoaXMgYm9vbGVhbiB2YXJpYWJsZSBpcyBh IHRyYW5zaXRpb24gYWlkLiAgSWYgQGNvZGV7dH0sCitAY29kZXtjdXJyZW50LXRpbWV9IGFu ZCByZWxhdGVkIGZ1bmN0aW9ucyByZXR1cm4gdGltZXN0YW1wcyBpbiBsaXN0Citmb3JtLCB0 eXBpY2FsbHkgQGNvZGV7KEB2YXJ7aGlnaH0gQHZhcntsb3d9IEB2YXJ7bWljcm99IEB2YXJ7 cGljb30pfTsKK290aGVyd2lzZSwgdGhleSB1c2UgQGNvZGV7KEB2YXJ7dGlja3N9IC4gQHZh cntoen0pfSBmb3JtLiAgQ3VycmVudGx5Cit0aGlzIHZhcmlhYmxlIGRlZmF1bHRzIHRvIEBj b2Rle3R9LCBmb3IgYmVoYXZpb3IgY29tcGF0aWJsZSB3aXRoCitwcmV2aW91cyBFbWFjcyB2 ZXJzaW9ucy4gIERldmVsb3BlcnMgYXJlIGVuY291cmFnZSB0byB0ZXN0Cit0aW1lc3RhbXAt cmVsYXRlZCBjb2RlIHdpdGggdGhpcyB2YXJpYWJsZSBzZXQgdG8gQGNvZGV7bmlsfSwgYXMg aXQKK3dpbGwgZGVmYXVsdCB0byBAY29kZXtuaWx9IGluIGEgZnV0dXJlIEVtYWNzIHZlcnNp b24sIGFuZCB3aWxsIGJlCityZW1vdmVkIGluIHNvbWUgdmVyc2lvbiBhZnRlciB0aGF0Lgor QGVuZCBkZWZ2YXIKKwogQGRlZnVuIGN1cnJlbnQtdGltZQogVGhpcyBmdW5jdGlvbiByZXR1 cm5zIHRoZSBjdXJyZW50IHRpbWUgYXMgYSBMaXNwIHRpbWVzdGFtcC4KLVRoZSB0aW1lc3Rh bXAgaGFzIHRoZSBmb3JtIEBjb2RleyhAdmFye3RpY2tzfSAuIEB2YXJ7aHp9KX0gd2hlcmUK K0lmIEBjb2Rle2N1cnJlbnQtdGltZS1saXN0fSBpcyBAY29kZXtuaWx9LAordGhlIHRpbWVz dGFtcCBoYXMgdGhlIGZvcm0gQGNvZGV7KEB2YXJ7dGlja3N9IC4gQHZhcntoen0pfSB3aGVy ZQogQHZhcnt0aWNrc30gY291bnRzIGNsb2NrIHRpY2tzIGFuZCBAdmFye2h6fSBpcyB0aGUg Y2xvY2sgdGlja3MgcGVyIHNlY29uZC4KLQotSW4gRW1hY3MgMjggYW5kIGVhcmxpZXIsIHRo ZSByZXR1cm5lZCB0aW1lc3RhbXAgaGFkIHRoZSBsaXN0IGZvcm0KLUBjb2RleyhAdmFye2hp Z2h9IEB2YXJ7bG93fSBAdmFye3VzZWN9IEB2YXJ7cHNlY30pfS4gIFlvdSBjYW4gdXNlCi1A Y29kZXsodGltZS1jb252ZXJ0IG5pbCAnbGlzdCl9IHRvIHJldHVybiB0aGUgY3VycmVudCB0 aW1lIGluIHRoaXMKLW9sZGVyIGZvcm0uICBAeHJlZntUaW1lIENvbnZlcnNpb259LgorT3Ro ZXJ3aXNlLCB0aGUgdGltZXN0YW1wIGhhcyB0aGUgbGlzdCBmb3JtCitAY29kZXsoQHZhcnto aWdofSBAdmFye2xvd30gQHZhcnt1c2VjfSBAdmFye3BzZWN9KX0uCitZb3UgY2FuIHVzZSBA Y29kZXsodGltZS1jb252ZXJ0IG5pbCB0KX0gb3IgQGNvZGV7KHRpbWUtY29udmVydCBuaWwg J2xpc3QpfQordG8gb2J0YWluIGEgcGFydGljdWxhciBmb3JtIHJlZ2FyZGxlc3Mgb2YgdGhl IHZhbHVlIG9mCitAY29kZXtjdXJyZW50LXRpbWUtbGlzdH0uICBAeHJlZntUaW1lIENvbnZl cnNpb259LgogQGVuZCBkZWZ1bgogCiBAZGVmdW4gZmxvYXQtdGltZSAmb3B0aW9uYWwgdGlt ZQpkaWZmIC0tZ2l0IGEvZXRjL05FV1MgYi9ldGMvTkVXUwppbmRleCA3MDA4N2YyNjI5Li45 ZjkzYzQwNjdmIDEwMDY0NAotLS0gYS9ldGMvTkVXUworKysgYi9ldGMvTkVXUwpAQCAtMjAz LDEyICsyMDMsMTUgQEAgdXNlIHRoZSBuZXcgJ3RhbWlsLWl0cmFucy1kaWdpdHMnIGFuZCAn dGFtaWwtaW5zY3JpcHQtZGlnaXRzJyBpbnB1dAogbWV0aG9kcyBpbnN0ZWFkLgogCiArKysK LSoqIGN1cnJlbnQtdGltZSBhbmQgcmVsYXRlZCBmdW5jdGlvbnMgbm93IHlpZWxkIChUSUNL UyAuIEhaKSB0aW1lc3RhbXBzLgotUHJldmlvdXNseSB0aGV5IHlpZWxkZWQgdGltZXN0YW1w cyBvZiB0aGUgZm9ybXMgKEhJIExPIFVTIFBTKSwgKEhJIExPCi1VUykgb3IgKEhJIExPKSwg d2hpY2ggd2VyZSBsZXNzIHJlZ3VsYXIgYW5kIGxlc3MgZWZmaWNpZW50IGFuZCB3aGljaAot bGFja2VkIGluZm9ybWF0aW9uIGFib3V0IGNsb2NrIHJlc29sdXRpb24uICBUaGlzIGxvbmct cGxhbm5lZCBjaGFuZ2UKLXdhcyBkb2N1bWVudGVkIGluIEVtYWNzIDI3LiAgVG8gY29udmVy dCBhIHRpbWVzdGFtcCBYIHRvIHRoZSBvbGQKLTQtZWxlbWVudCBsaXN0IGZvcm0sIHlvdSBj YW4gdXNlICh0aW1lLWNvbnZlcnQgWCAnbGlzdCkuCisqKiBOZXcgdmFyaWFibGUgY3VycmVu dC10aW1lLWxpc3QgZ292ZXJuaW5nIGRlZmF1bHQgdGltZXN0YW1wIGZvcm0uCitGdW5jdGlv bnMgbGlrZSBjdXJyZW50LXRpbWUgbm93IHlpZWxkIChUSUNLUyAuIEhaKSB0aW1lc3RhbXBz IGlmIHRoaXMKK25ldyB2YXJpYWJsZSBpcyBuaWwuICBUaGUgdmFyaWFibGUgZGVmYXVsdHMg dG8gdCwgd2hpY2ggbWVhbnMgdGhlc2UKK2Z1bmN0aW9ucyBkZWZhdWx0IHRvIHRpbWVzdGFt cHMgb2YgdGhlIGZvcm1zIChISSBMTyBVUyBQUyksIChISSBMTyBVUykKK29yIChISSBMTyks IHdoaWNoIGFyZSBsZXNzIHJlZ3VsYXIgYW5kIGxlc3MgZWZmaWNpZW50LiAgVGhpcyBpcyBw YXJ0CitvZiBhIGxvbmctcGxhbm5lZCBjaGFuZ2UgZmlyc3QgZG9jdW1lbnRlZCBpbiBFbWFj cyAyNy4gIERldmVsb3BlcnMgYXJlCitlbmNvdXJhZ2UgdG8gdGVzdCB0aW1lc3RhbXAtcmVs YXRlZCBjb2RlIHdpdGggdGhpcyB2YXJpYWJsZSBzZXQgdG8KK25pbCwgYXMgaXQgd2lsbCBk ZWZhdWx0IHRvIG5pbCBpbiBhIGZ1dHVyZSBFbWFjcyB2ZXJzaW9uIGFuZCB3aWxsIGJlCity ZW1vdmVkIHNvbWUgdGltZSBhZnRlciB0aGF0LgogCiAMCiAqIENoYW5nZXMgaW4gRW1hY3Mg MjkuMQpkaWZmIC0tZ2l0IGEvc3JjL3RpbWVmbnMuYyBiL3NyYy90aW1lZm5zLmMKaW5kZXgg NjUxZTA3NjBlOC4uYmNhOWE1NjZlMCAxMDA2NDQKLS0tIGEvc3JjL3RpbWVmbnMuYworKysg Yi9zcmMvdGltZWZucy5jCkBAIC02OSwxMSArNjksMTEgQEAgQ29weXJpZ2h0IChDKSAxOTg1 LTE5ODcsIDE5ODksIDE5OTMtMjAyMiBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4K ICMgZGVmaW5lIEZBU1RFUl9USU1FRk5TIDEKICNlbmRpZgogCi0vKiBjdXJyZW50LXRpbWUg ZXRjLiBnZW5lcmF0ZSAoVElDS1MgLiBIWikgdGltZXN0YW1wcy4KLSAgIFRvIGNoYW5nZSB0 aGF0IHRvIHRoZSBvbGQgNC1lbGVtZW50IGxpc3QgZm9ybWF0IChISSBMTyBVUyBQUyksCi0g ICBjb21waWxlIHdpdGggLURDVVJSRU5UX1RJTUVfTElTVD0xLiAgKi8KKy8qIGN1cnJlbnQt dGltZS1saXN0IGRlZmF1bHRzIHRvIHQsIHR5cGljYWxseSBnZW5lcmF0aW5nIChISSBMTyBV UyBQUykKKyAgIHRpbWVzdGFtcHMuICBUbyBjaGFuZ2UgdGhlIGRlZmF1bHQgdG8gbmlsLCBn ZW5lcmF0aW5nIChUSUNLUyAuIEhaKQorICAgdGltZXN0YW1wcywgY29tcGlsZSB3aXRoIC1E Q1VSUkVOVF9USU1FX0xJU1Q9MC4gICovCiAjaWZuZGVmIENVUlJFTlRfVElNRV9MSVNUCi1l bnVtIHsgQ1VSUkVOVF9USU1FX0xJU1QgPSBmYWxzZSB9OworZW51bSB7IENVUlJFTlRfVElN RV9MSVNUID0gdHJ1ZSB9OwogI2VuZGlmCiAKICNpZiBGSVhOVU1fT1ZFUkZMT1dfUCAoMTAw MDAwMDAwMCkKQEAgLTU2OCw3ICs1NjgsNyBAQCBsaXNwX3RpbWVfc2Vjb25kcyAoc3RydWN0 IGxpc3BfdGltZSB0KQogTGlzcF9PYmplY3QKIG1ha2VfbGlzcF90aW1lIChzdHJ1Y3QgdGlt ZXNwZWMgdCkKIHsKLSAgaWYgKENVUlJFTlRfVElNRV9MSVNUKQorICBpZiAoY3VycmVudF90 aW1lX2xpc3QpCiAgICAgewogICAgICAgdGltZV90IHMgPSB0LnR2X3NlYzsKICAgICAgIGlu dCBucyA9IHQudHZfbnNlYzsKQEAgLTExNzEsMTMgKzExNzEsMTMgQEAgdGltZV9hcml0aCAo TGlzcF9PYmplY3QgYSwgTGlzcF9PYmplY3QgYiwgYm9vbCBzdWJ0cmFjdCkKICAgICB9CiAK ICAgLyogUmV0dXJuIGFuIGludGVnZXIgaWYgdGhlIHRpbWVzdGFtcCByZXNvbHV0aW9uIGlz IDEsCi0gICAgIG90aGVyd2lzZSB0aGUgKFRJQ0tTIC4gSFopIGZvcm0gaWYgIUNVUlJFTlRf VElNRV9MSVNUIG9yIGlmCisgICAgIG90aGVyd2lzZSB0aGUgKFRJQ0tTIC4gSFopIGZvcm0g aWYgIWN1cnJlbnRfdGltZV9saXN0IG9yIGlmCiAgICAgIGVpdGhlciBpbnB1dCB1c2VkIChU SUNLUyAuIEhaKSBmb3JtIG9yIHRoZSByZXN1bHQgY2FuJ3QgYmUgZXhwcmVzc2VkCiAgICAg IGV4YWN0bHkgaW4gKEhJIExPIFVTIFBTKSBmb3JtLCBvdGhlcndpc2UgdGhlIChISSBMTyBV UyBQUykgZm9ybQogICAgICBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4gICovCiAgIHJl dHVybiAoRVEgKGh6LCBtYWtlX2ZpeG51bSAoMSkpCiAJICA/IHRpY2tzCi0JICA6ICghQ1VS UkVOVF9USU1FX0xJU1QKKwkgIDogKCFjdXJyZW50X3RpbWVfbGlzdAogCSAgICAgfHwgYWZv cm0gPT0gVElNRUZPUk1fVElDS1NfSFoKIAkgICAgIHx8IGJmb3JtID09IFRJTUVGT1JNX1RJ Q0tTX0haCiAJICAgICB8fCAhdHJpbGxpb25fZmFjdG9yIChoeikpCkBAIC0xNzE2LDcgKzE3 MTYsNyBAQCBERUZVTiAoImVuY29kZS10aW1lIiwgRmVuY29kZV90aW1lLCBTZW5jb2RlX3Rp bWUsIDEsIE1BTlksIDAsCiAgICAgdGltZV9lcnJvciAobWt0aW1lX2Vycm5vKTsKIAogICBp ZiAoRVEgKGh6LCBtYWtlX2ZpeG51bSAoMSkpKQotICAgIHJldHVybiAoQ1VSUkVOVF9USU1F X0xJU1QKKyAgICByZXR1cm4gKGN1cnJlbnRfdGltZV9saXN0CiAJICAgID8gbGlzdDIgKGhp X3RpbWUgKHZhbHVlKSwgbG9fdGltZSAodmFsdWUpKQogCSAgICA6IElOVF9UT19JTlRFR0VS ICh2YWx1ZSkpOwogICBlbHNlCkBAIC0xNzQ3LDcgKzE3NDcsNyBAQCBERUZVTiAoInRpbWUt Y29udmVydCIsIEZ0aW1lX2NvbnZlcnQsIFN0aW1lX2NvbnZlcnQsIDEsIDIsIDAsCiAgIHN0 cnVjdCBsaXNwX3RpbWUgdDsKICAgZW51bSB0aW1lZm9ybSBpbnB1dF9mb3JtID0gZGVjb2Rl X2xpc3BfdGltZSAodGltZSwgZmFsc2UsICZ0LCAwKTsKICAgaWYgKE5JTFAgKGZvcm0pKQot ICAgIGZvcm0gPSBDVVJSRU5UX1RJTUVfTElTVCA/IFFsaXN0IDogUXQ7CisgICAgZm9ybSA9 IGN1cnJlbnRfdGltZV9saXN0ID8gUWxpc3QgOiBRdDsKICAgaWYgKEVRIChmb3JtLCBRbGlz dCkpCiAgICAgcmV0dXJuIHRpY2tzX2h6X2xpc3Q0ICh0LnRpY2tzLCB0Lmh6KTsKICAgaWYg KEVRIChmb3JtLCBRaW50ZWdlcikpCkBAIC0xNzYyLDE0ICsxNzYyLDE1IEBAIERFRlVOICgi dGltZS1jb252ZXJ0IiwgRnRpbWVfY29udmVydCwgU3RpbWVfY29udmVydCwgMSwgMiwgMCwK IAogREVGVU4gKCJjdXJyZW50LXRpbWUiLCBGY3VycmVudF90aW1lLCBTY3VycmVudF90aW1l LCAwLCAwLCAwLAogICAgICAgIGRvYzogLyogUmV0dXJuIHRoZSBjdXJyZW50IHRpbWUsIGFz IHRoZSBudW1iZXIgb2Ygc2Vjb25kcyBzaW5jZSAxOTcwLTAxLTAxIDAwOjAwOjAwLgotVGhl IHRpbWUgaXMgcmV0dXJuZWQgYXMgYSBwYWlyIG9mIGludGVnZXJzIChUSUNLUyAuIEhaKSwg d2hlcmUgVElDS1MKLWNvdW50cyBjbG9jayB0aWNrcyBhbmQgSFogaXMgdGhlIGNsb2NrIHRp Y2tzIHBlciBzZWNvbmQuCi0KLUluIEVtYWNzIDI4IGFuZCBlYXJsaWVyLCB0aGUgcmV0dXJu ZWQgdGltZXN0YW1wIGhhZCB0aGUgZm9ybSAoSElHSCBMT1cKLVVTRUMgUFNFQyksIHdoZXJl IEhJR0ggaXMgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0cyBvZiB0aGUgc2Vjb25kcywKLUxP VyB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQgMTYgYml0cywgYW5kIFVTRUMgYW5kIFBTRUMgYXJl IHRoZQotbWljcm9zZWNvbmQgYW5kIHBpY29zZWNvbmQgY291bnRzLiAgVXNlIFwodGltZS1j b252ZXJ0IG5pbCBcXD0nbGlzdCkKLWlmIHlvdSBuZWVkIHRoaXMgb2xkZXIgdGltZXN0YW1w IGZvcm0uICAqLykKK0lmIHRoZSB2YXJpYWJsZSBgY3VycmVudC10aW1lLWxpc3QnIGlzIG5p bCwgdGhlIHRpbWUgaXMgcmV0dXJuZWQgYXMgYQorcGFpciBvZiBpbnRlZ2VycyAoVElDS1Mg LiBIWiksIHdoZXJlIFRJQ0tTIGNvdW50cyBjbG9jayB0aWNrcyBhbmQgSFoKK2lzIHRoZSBj bG9jayB0aWNrcyBwZXIgc2Vjb25kLiAgT3RoZXJ3aXNlLCB0aGUgdGltZSBpcyByZXR1cm5l ZCBhcyBhCitsaXN0IG9mIGludGVnZXJzIChISUdIIExPVyBVU0VDIFBTRUMpIHdoZXJlIEhJ R0ggaGFzIHRoZSBtb3N0CitzaWduaWZpY2FudCBiaXRzIG9mIHRoZSBzZWNvbmRzLCBMT1cg aGFzIHRoZSBsZWFzdCBzaWduaWZpY2FudCAxNgorYml0cywgYW5kIFVTRUMgYW5kIFBTRUMg YXJlIHRoZSBtaWNyb3NlY29uZCBhbmQgcGljb3NlY29uZCBjb3VudHMuCisKK1lvdSBjYW4g dXNlIGB0aW1lLWNvbnZlcnQnIHRvIGdldCBhIHBhcnRpY3VsYXIgdGltZXN0YW1wIGZvcm0K K3JlZ2FyZGxlc3Mgb2YgdGhlIHZhbHVlIG9mIGBjdXJyZW50LXRpbWUtbGlzdCcuICAqLykK ICAgKHZvaWQpCiB7CiAgIHJldHVybiBtYWtlX2xpc3BfdGltZSAoY3VycmVudF90aW1lc3Bl YyAoKSk7CkBAIC0yMDI1LDYgKzIwMjYsMTkgQEAgc3ltc19vZl90aW1lZm5zICh2b2lkKQog CiAgIERFRlNZTSAoUWVuY29kZV90aW1lLCAiZW5jb2RlLXRpbWUiKTsKIAorICBERUZWQVJf Qk9PTCAoImN1cnJlbnQtdGltZS1saXN0IiwgY3VycmVudF90aW1lX2xpc3QsCisJICAgICAg IGRvYzogLyogV2hldGhlciBgY3VycmVudC10aW1lJyBzaG91bGQgcmV0dXJuIGxpc3Qgb3Ig KFRJQ0tTIC4gSFopIGZvcm0uCisKK1RoaXMgYm9vbGVhbiB2YXJpYWJsZSBpcyBhIHRyYW5z aXRpb24gYWlkLiAgSWYgdCwgYGN1cnJlbnQtdGltZScgYW5kCityZWxhdGVkIGZ1bmN0aW9u cyByZXR1cm4gdGltZXN0YW1wcyBpbiBsaXN0IGZvcm0sIHR5cGljYWxseQorXChISUdIIExP VyBVU0VDIFBTRUMpOyBvdGhlcndpc2UsIHRoZXkgdXNlIChUSUNLUyAuIEhaKSBmb3JtLgor Q3VycmVudGx5IHRoaXMgdmFyaWFibGUgZGVmYXVsdHMgdG8gdCwgZm9yIGJlaGF2aW9yIGNv bXBhdGlibGUgd2l0aAorcHJldmlvdXMgRW1hY3MgdmVyc2lvbnMuICBEZXZlbG9wZXJzIGFy ZSBlbmNvdXJhZ2UgdG8gdGVzdAordGltZXN0YW1wLXJlbGF0ZWQgY29kZSB3aXRoIHRoaXMg dmFyaWFibGUgc2V0IHRvIG5pbCwgYXMgaXQgd2lsbAorZGVmYXVsdCB0byBuaWwgaW4gYSBm dXR1cmUgRW1hY3MgdmVyc2lvbiwgYW5kIHdpbGwgYmUgcmVtb3ZlZCBpbiBzb21lCit2ZXJz aW9uIGFmdGVyIHRoYXQuICAqLyk7CisgIGN1cnJlbnRfdGltZV9saXN0ID0gQ1VSUkVOVF9U SU1FX0xJU1Q7CisKICAgZGVmc3ViciAoJlNjdXJyZW50X3RpbWUpOwogI2lmZGVmIENMT0NL U19QRVJfU0VDCiAgIGRlZnN1YnIgKCZTY3VycmVudF9jcHVfdGltZSk7Ci0tIAoyLjM1LjEK Cg== --------------EJDWBR5HCECe50pcMHAv0nPT-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 16:42:34 2022 Received: (at 55163) by debbugs.gnu.org; 28 Apr 2022 20:42:34 +0000 Received: from localhost ([127.0.0.1]:50111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkAyA-0006jf-6u for submit@debbugs.gnu.org; Thu, 28 Apr 2022 16:42:34 -0400 Received: from mail-ej1-f48.google.com ([209.85.218.48]:40767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkAy9-0006jS-EF for 55163@debbugs.gnu.org; Thu, 28 Apr 2022 16:42:33 -0400 Received: by mail-ej1-f48.google.com with SMTP id l18so11809904ejc.7 for <55163@debbugs.gnu.org>; Thu, 28 Apr 2022 13:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=oaMojmUl8S2hM36U/LiusFVE8MDok5McanAP0gyAZ4I=; b=LLOVc+pKt8nynWR5Q4/4lqEvXt5xYkmxX6sB+yVfvhbQWL/ysq8u8+5AkvGk2Qh4VR Ak0uYsJAjk1gnxbL2Vpa27Ah4PV4iH0wbL3GUZgKosTe/5EaXJNn7p6iJNf3Z5B5wAfA jyPIVGo2cFeuUox8hbEaNGe0k6yDZ+eTENgRfjcjQh1yrEP3Mb4j9coXKCHvVaLCQ4uJ D1EpVYG0J/fErRvCib2DueS4UM7VLkJ8823dUgerZYvBQ1BVhMPCLHZ2XuAi/Y+wbBNn vR9/14UuJACpSs2rpvvYt/VftnTlpznMGAm6oV+zTRcJrUWynZL/31gDZKHfyCR/xP4W 1gcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oaMojmUl8S2hM36U/LiusFVE8MDok5McanAP0gyAZ4I=; b=5WWZ/E1sQKqlNVuu5tPPjudRrMIzBIjtwsrkzcwO3A/AagAHRrwLvgm9qm5cbJU7qc 6DTwAmyUji7R4ZxJDX+x00YQBdVIE5HNGYcsx3C6iVN5PzRXiNZrX7mEgD+JNr0en0fm ANo7woSIPuKDURTi9bsMUZN7jw+SXiLPjBwNl9/HYH1w/irsXTAXxMTmBV5m3yXlAHIc 8VUWyxEHFodkQSw4j2msBOK1E9uaZk8PqHRZQOk4tnIyHuQO0djxlyU1UWSHXSdfdfYf moDa2E5zVMPcP3lk4WQ6MICmADljjpCfbEJFAIw79eDJ1KjtKPmBNbluvNehxcuK4SZy vJYw== X-Gm-Message-State: AOAM5311XQ8qp3zcMkeTrifP3fbpguWfuKTFnYbJ0QKkEIvgZlv8pqoh 0vrZCzbYj8ArvtM5dzbpcoU= X-Google-Smtp-Source: ABdhPJy9jTL1FRoL88PhMux6tTwtvCbqAGJ0C4mk3eqbC0luyxhuonUVsG0q1p7jrFkbsAKRuzzynQ== X-Received: by 2002:a17:907:2bde:b0:6f3:8e91:3a60 with SMTP id gv30-20020a1709072bde00b006f38e913a60mr22498470ejc.434.1651178547497; Thu, 28 Apr 2022 13:42:27 -0700 (PDT) Received: from zarathustrawsp500.localnet (93-37-156-1.ip66.fastwebnet.it. [93.37.156.1]) by smtp.gmail.com with ESMTPSA id jl22-20020a17090775d600b006f3ef214d9esm8667ejc.4.2022.04.28.13.42.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 13:42:27 -0700 (PDT) From: Vincenzo Pupillo To: Lars Ingebrigtsen , Paul Eggert 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 Message-ID: <12000250.O9o76ZdvQC@zarathustrawsp500> In-Reply-To: References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In data gioved=EC 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. >=20 > 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. >=20 > 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. >=20 > 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 17:52:05 2022 Received: (at 55163) by debbugs.gnu.org; 28 Apr 2022 21:52:05 +0000 Received: from localhost ([127.0.0.1]:50196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkC3R-0008Tj-EO for submit@debbugs.gnu.org; Thu, 28 Apr 2022 17:52:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkC3N-0008TE-In for 55163@debbugs.gnu.org; Thu, 28 Apr 2022 17:52:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SNbdWM+H91ldy1QgC+L9Sx4IfBPSMHSwWj9UrZ2mKYY=; b=Co2kLCc4+na6Ge9dDo1BxFuDLY WKK1MdHeP8Rwcd/OgffVJfQHG7RfuTknKeOelrO0WBfayLsvjpie0ggKRyZdW8rRIPLiysI/T3LJH S1mbKZh4QIVVI5FHcNjjalIEXXGCQILdJi3ua9qVOkLEZV1QPGx0KQujhy3PxauAbmcQ=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkC3C-0005xs-JW; Thu, 28 Apr 2022 23:51:53 +0200 From: Lars Ingebrigtsen To: Paul Eggert Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEUSDgtcSC62rZn/ //8KEp6MAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YEHBUyF5fIrPUAAAGMSURBVCjPNZLBihsxDIZ/ hfFA9uQs40B6bmDbp9CETSE9KcEqNKc9ZJemT7F9g/ZSaE45dIeOn7KSkxgP+BvJ8u9fBoBm8vsF gsugyVCuSwHthhOaW+RLuUWaTLsy2ILtyxEeiZYBJGBXCs9qWmLMDRJXkApdY/UoRWxVpdamWPdE 6g1CLUqgzR3Xar5X5sXhDKIMaR3CiJCP0SKCngom/Vsnafhp4ROgxyzt8IqY9tyO4zS25YepLjxV EYQ/ftILL/Zv2eS7hCnSfrSyCztQ7NTvJVYt/GrRjxU6K2uZ78aLBX81gD7/sz+bDr+S5a7OUXBa oLd7YXWIEXoH0gMjHLotgkNBag7tms0petbwKUjoOWWHtFpLUjab4nOe7da8zBzYQAIR02ONLKVl 90waQbeUgEcDUwf9kNFVMNp+zZRNBHXeno3Ozn4B74mqxrOAG7Luasrvxf0lM0GDPLjZjTuSgnwj rg400Gk+whX7uN/kFeEKi5Dv+fokEEhvL8U7bPY8XZ6NTZlfYfIfpfRZcm/SY8EAAAAldEVYdGRh dGU6Y3JlYXRlADIwMjItMDQtMjhUMjE6NTA6MjMrMDA6MDBS6QGSAAAAJXRFWHRkYXRlOm1vZGlm eQAyMDIyLTA0LTI4VDIxOjUwOjIzKzAwOjAwI7S5LgAAAABJRU5ErkJggg== X-Now-Playing: Black Uhuru's _The Dub Factor_: "Puffed Out" Date: Thu, 28 Apr 2022 23:51:50 +0200 In-Reply-To: (Paul Eggert's message of "Thu, 28 Apr 2022 13:15:54 -0700") Message-ID: <87o80kj2q1.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Eggert 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Vincenzo Pupillo , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Paul Eggert 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 17:55:34 2022 Received: (at 55163) by debbugs.gnu.org; 28 Apr 2022 21:55:34 +0000 Received: from localhost ([127.0.0.1]:50200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkC6n-00007R-UE for submit@debbugs.gnu.org; Thu, 28 Apr 2022 17:55:34 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkC6l-00007D-Ko for 55163@debbugs.gnu.org; Thu, 28 Apr 2022 17:55:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2f6OXma+P4eOKah9bbC1ao4A7AFvo+ISM+kNQugv98Q=; b=H1v08caNAQG+6dZdUjCSx1rFPu dvnOJ+Kl6ePPIkBoM4/iYyz9ny6qYwdd7RNjNupwRkctmNGIVDFXnWtcio2jSi+zB8at00/+Gl46C bzayYf+FKBwx7ELwvcUlZfcMNBi7UY2Mu4ZIsKCzvmTztsoeQi+R0ZLUr4tuolffOpYU=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkC6a-0005z5-Kc; Thu, 28 Apr 2022 23:55:22 +0200 From: Lars Ingebrigtsen To: Vincenzo Pupillo Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <12000250.O9o76ZdvQC@zarathustrawsp500> X-Now-Playing: Prince's _Sign 'O' the Times (5): Vault Tracks II_: "Train" Date: Thu, 28 Apr 2022 23:55:20 +0200 In-Reply-To: <12000250.O9o76ZdvQC@zarathustrawsp500> (Vincenzo Pupillo's message of "Thu, 28 Apr 2022 22:42:25 +0200") Message-ID: <87k0b8j2k7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Vincenzo Pupillo writes: > Thanks guys, now it works correctly with this patch. Thanks for checking; I'm closing this bug report, then. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Paul Eggert , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Vincenzo Pupillo 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 17:55:39 2022 Received: (at control) by debbugs.gnu.org; 28 Apr 2022 21:55:39 +0000 Received: from localhost ([127.0.0.1]:50203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkC6t-00007m-4u for submit@debbugs.gnu.org; Thu, 28 Apr 2022 17:55:39 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkC6o-00007H-Tx for control@debbugs.gnu.org; Thu, 28 Apr 2022 17:55:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=D5hBkk80sfdy8qf8/TmAhV7sgJ4ni7GCyuq+yuiMFV8=; b=KKp6ScIbngRldk/zWZfHue7lt3 Fjr2Bc5/tV2FFSU73INSd34khvUOjBy3eFvxZWmeLRm+Xb8uxaSR/Qu0dKSAYWv274/DAMBIWb5/k vODSsxaHDky7SzdP6oYdiRQOm7YHFMX5FSe0/AVUMJAIg6y6tnzqz4M+FhdhRrTYAHhM=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkC6h-0005zD-CA for control@debbugs.gnu.org; Thu, 28 Apr 2022 23:55:29 +0200 Date: Thu, 28 Apr 2022 23:55:26 +0200 Message-Id: <87ilqsj2k1.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #55163 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 55163 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 55163 29.1 quit From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 05:54:21 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 09:54:21 +0000 Received: from localhost ([127.0.0.1]:50875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkNKO-0005eG-O0 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 05:54:20 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkNKN-0005e3-Ka for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 05:54:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IX37SktNIo5GSqCLNRYOw0HzlmnfI9RP77KBMH9O35M=; b=ADuE8jaJo++KXYBD8uIYiuzlr0 R8/lI/nigF50M6bqmG6EmruLyXlmG6vpcI7xkEfvxoQcvgjX0rKevO8gLdxPyYexclMigyoajrahs UvqRdMxCHWis1hR4FoCkDsUhNY6PuhngoOzx6sH0Vw735zbSkr1BLAkGInXExA4+/FRE=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkNKC-0004xk-2W; Fri, 29 Apr 2022 11:54:10 +0200 From: Lars Ingebrigtsen To: Paul Eggert Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEVMPz6tSELAp5r/ ///wg2LlAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YEHQktLqgXFxIAAAGdSURBVCjPRZHNatwwFIWP xNh0tHKHcRhm5ZYQEj+FYlIoWanFGmhW3TQkfgrHq5KVY0JoZ+UGzxDfp+yRXajA+H7cc390BAAL u61xASRwib6yhsAvnE/eO7sJUQJEnudmQRiq+BDgG0inPsi8L7Ew6PNZVm6YyXIzyZgyyP41KIHl f1nu2DqduqXldsinOc6XKWU5eqgAWalcFfaMXFpmu/1bAe4UIdr9vsK7FdYTOM7PcsrU2qKQMVzh Lqy+KDZNpn8w4jD1eiESLhfzdy0iQeGMSPN49hNxnUA+5yzVinkLqc9NvYaeamQ4N00rzZx5oywL 8ED4paVOpKvuFeFRy8Pd8WmJyOLlpchZ2i1hmDkyVOUr4TmAsg6dIPaES91adD1Swlj09KGDP/Go Dl9bwkcjR2YO07OsYhkiVAOWyXvoWEbgZqB1Cf50Mn6BPNvwYomWkQ1axdDhKb7cEYLDgNXKw3+f QWldQvX4EBJFbBLEY3rLIquDPycyZLBwzQzjVLOaQfoAeYDtXgZOpW9iUe0nZ+krjZNKpJ3h8Bfz d5OVvNxeIQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wNC0yOVQwOTo0NTo0NiswMDowMPQctWcA AAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDQtMjlUMDk6NDU6NDYrMDA6MDCFQQ3bAAAAAElFTkSu QmCC X-Now-Playing: Themselves's _CrownsDown_: "oversleeping" Date: Fri, 29 Apr 2022 11:54:07 +0200 In-Reply-To: <87o80kj2q1.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 28 Apr 2022 23:51:50 +0200") Message-ID: <878rroi5a8.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Vincenzo Pupillo , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 06:54:10 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 10:54:11 +0000 Received: from localhost ([127.0.0.1]:50946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOGI-0005PD-K3 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 06:54:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOGH-0005P1-0z for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 06:54:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45486) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkOGA-0001HY-QP; Fri, 29 Apr 2022 06:54:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=n9GiYncBBg4K1fNzGP7ERyj5QQc1ALWpAY8hL92XKZQ=; b=WI2ZK4JqzAMw tVoFlO7EYZiVasLg3VLY6pVBl+EZOrx+kmFB4nNT6xstv5BPQzFvd+iLmjcki/MjKW0EJl3U5ozWy 6n/V4me8Ngc8VDZJGJx4GjPJ46SbqIyJLTY7XSsse/QZCxLosjy6FhEUhAfF3IN+JnJrTpM/t9B6M B+gn8f/IDCUlCigZc28Lhh8Ic346IptOmqtYjXUi2j3GGohZynnWkzb3n28IZk1RBQ3J9L76nATGE nkGZ53pybaJF4oLO+rbJlE42Shg+vOU7Okqi2hm/R0Bw1nf55u3hbcoyE/LPcErn6gSIAL0A+vwnw zfZSJdkopwCK+EIE7m0aZg==; Received: from [87.69.77.57] (port=1845 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkOG9-0003r8-Os; Fri, 29 Apr 2022 06:54:02 -0400 Date: Fri, 29 Apr 2022 13:54:03 +0300 Message-Id: <83y1zo9n3o.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <878rroi5a8.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 29 Apr 2022 11:54:07 +0200) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, eggert@cs.ucla.edu, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 55163@debbugs.gnu.org, Eli Zaretskii , Vincenzo Pupillo > > Date: Fri, 29 Apr 2022 11:54:07 +0200 > > Lars Ingebrigtsen 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 06:59:52 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 10:59:52 +0000 Received: from localhost ([127.0.0.1]:50954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOLo-0005Zf-B5 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 06:59:52 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOLm-0005ZR-Uv for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 06:59:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=k36DgnCl5oOi8KV9BWZfqFYlaIINju2eKeT8BRN7/Uo=; b=ahh76Pqtib77xjri8eCzERUHLS KQKu4qBkkukr8rRiFfIR62iVk4hYNpvMDH1XSv4oDdaGErmEAPR9vAzIBHKJWSTVbQHHYjeg5ypNS wlmDCx+10+YFUUCKAbRkWMMjyPThISuao2PoR+bNZaX9tCdwLCSOq9bOtmB5i4ceKUx4=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkOLc-0006A8-D6; Fri, 29 Apr 2022 12:59:42 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEVMPz6tSELAp5r/ ///wg2LlAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YEHQktLqgXFxIAAAGdSURBVCjPRZHNatwwFIWP xNh0tHKHcRhm5ZYQEj+FYlIoWanFGmhW3TQkfgrHq5KVY0JoZ+UGzxDfp+yRXajA+H7cc390BAAL u61xASRwib6yhsAvnE/eO7sJUQJEnudmQRiq+BDgG0inPsi8L7Ew6PNZVm6YyXIzyZgyyP41KIHl f1nu2DqduqXldsinOc6XKWU5eqgAWalcFfaMXFpmu/1bAe4UIdr9vsK7FdYTOM7PcsrU2qKQMVzh Lqy+KDZNpn8w4jD1eiESLhfzdy0iQeGMSPN49hNxnUA+5yzVinkLqc9NvYaeamQ4N00rzZx5oywL 8ED4paVOpKvuFeFRy8Pd8WmJyOLlpchZ2i1hmDkyVOUr4TmAsg6dIPaES91adD1Swlj09KGDP/Go Dl9bwkcjR2YO07OsYhkiVAOWyXvoWEbgZqB1Cf50Mn6BPNvwYomWkQ1axdDhKb7cEYLDgNXKw3+f QWldQvX4EBJFbBLEY3rLIquDPycyZLBwzQzjVLOaQfoAeYDtXgZOpW9iUe0nZ+krjZNKpJ3h8Bfz d5OVvNxeIQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wNC0yOVQwOTo0NTo0NiswMDowMPQctWcA AAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDQtMjlUMDk6NDU6NDYrMDA6MDCFQQ3bAAAAAElFTkSu QmCC X-Now-Playing: Themselves's _CrownsDown_: "deadcatclear ii" Date: Fri, 29 Apr 2022 12:59:39 +0200 In-Reply-To: <83y1zo9n3o.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Apr 2022 13:54:03 +0300") Message-ID: <87y1zof944.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii 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 expo [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, eggert@cs.ucla.edu, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 07:10:36 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 11:10:36 +0000 Received: from localhost ([127.0.0.1]:50967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOWB-0005qn-OO for submit@debbugs.gnu.org; Fri, 29 Apr 2022 07:10:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOW8-0005qY-V0 for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 07:10:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45636) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkOVz-0004Z2-Ms; Fri, 29 Apr 2022 07:10:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RisKmtwUTEaXsHNx8Ua7dZyXMZ6g1FTWrBCRYGXYlgE=; b=ZBwFri/wuX8q v3+AmDJ2Wru5eCwAbLbJYFbE/uDmT7cfD4ZfYL/EdKAEvmQ8gS/jfmDQdKEnB9JbjpH44PjaUYUUd +2LyJ13iHgQsHUoL6Rm+kE0Fkhyv7vRv5Punfa91r+EynTIiM4zlDfm6KdYHFlrkBfPimS+yMV+mF VnbEVTspR8xhqqTp8ppXiyYgULZ1X7gl1dakowxF+Y285Zez8OEts14MaauNs2hV6UCuqiYRtORDN OuEp73p5M7t2n6VHm1c0wgrmyvIzyOC3jxfhzAWUk7AEVDPk4GnXcJC/hTk5RRdgwWc/QYOaiBGTP jOjIv123woz8uQ1Mb5RkNw==; Received: from [87.69.77.57] (port=2842 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkOVu-0007bd-Io; Fri, 29 Apr 2022 07:10:22 -0400 Date: Fri, 29 Apr 2022 14:10:20 +0300 Message-Id: <83wnf89mcj.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87y1zof944.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 29 Apr 2022 12:59:39 +0200) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, eggert@cs.ucla.edu, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: eggert@cs.ucla.edu, 55163@debbugs.gnu.org, v.pupillo@gmail.com > Date: Fri, 29 Apr 2022 12:59:39 +0200 > > Eli Zaretskii 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 15:38:29 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 19:38:29 +0000 Received: from localhost ([127.0.0.1]:55376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkWRg-0004wu-TF for submit@debbugs.gnu.org; Fri, 29 Apr 2022 15:38:29 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkWRf-0004vX-7q for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 15:38:27 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 370DF16005C; Fri, 29 Apr 2022 12:38:21 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0MbG1j-eMLOs; Fri, 29 Apr 2022 12:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7C17A16006C; Fri, 29 Apr 2022 12:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Y4kXjZSP_HWm; Fri, 29 Apr 2022 12:38:20 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 4F1C516005C; Fri, 29 Apr 2022 12:38:20 -0700 (PDT) Message-ID: <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> Date: Fri, 29 Apr 2022 12:38:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Eli Zaretskii , Lars Ingebrigtsen References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <83wnf89mcj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 15:53:38 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 19:53:38 +0000 Received: from localhost ([127.0.0.1]:55391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkWgL-0005VM-Q3 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 15:53:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkWgJ-0005V8-MI for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 15:53:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55976) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkWgD-0004TI-Jm; Fri, 29 Apr 2022 15:53:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=StMdUB9hltS/4abgG6IHD+h91wHpYr0X4+GuufEZAVA=; b=jZiumCGKJ4Aq +GkScm54C7f7BRpaUnAM7zIM7GpjPMrwatTfLyKnHjs4EmPoGyk5sLEUAT81UbSe6FGqUEmywXFnV hMXThMGMt85xor2nsTWkpGp3OZnkgg8mPYWGo6LmGpPc8njAYJ8OdhKmnMY0lXNnd9BRzcxfWb/lJ SAvCfh8/HtI6tTxu41ZAaMkxedChfouTvj2Yg6VPbahS28NH/lFNQvWp/i1G1MB30knGs/E0h123Z 6ScbTGqDoZ2ajKDQ4U4JBZWs7m1sMxNpKPAuBk31HKxv91BOg/c3bV2Lri8UNuEnRt8/wHxKwQRPY BaQdU6KYwu3LbPP4I+AkDw==; Received: from [87.69.77.57] (port=3339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkWgD-00005V-88; Fri, 29 Apr 2022 15:53:29 -0400 Date: Fri, 29 Apr 2022 22:53:31 +0300 Message-Id: <83ee1facp0.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> (message from Paul Eggert on Fri, 29 Apr 2022 12:38:19 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 29 Apr 2022 12:38:19 -0700 > Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com > From: Paul Eggert > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 18:45:53 2022 Received: (at 55163) by debbugs.gnu.org; 29 Apr 2022 22:45:54 +0000 Received: from localhost ([127.0.0.1]:55527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkZN3-0001PB-Jj for submit@debbugs.gnu.org; Fri, 29 Apr 2022 18:45:53 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkZN1-0001Ox-ON for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 18:45:52 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C1C2016005E; Fri, 29 Apr 2022 15:45:45 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JWFKVxXq59Bi; Fri, 29 Apr 2022 15:45:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 03AD816006C; Fri, 29 Apr 2022 15:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fnviMrKoaePV; Fri, 29 Apr 2022 15:45:44 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B5F4E16005E; Fri, 29 Apr 2022 15:45:44 -0700 (PDT) Message-ID: <7b51f5af-cd60-79ff-5cef-36fcdd64b766@cs.ucla.edu> Date: Fri, 29 Apr 2022 15:45:44 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <83ee1facp0.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 21:45:03 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 01:45:03 +0000 Received: from localhost ([127.0.0.1]:55670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkcAR-000610-50 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 21:45:03 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkcAP-00060C-4k for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 21:45:01 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 98D1B16006C; Fri, 29 Apr 2022 18:44:55 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vSPVE836Etza; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A7AD916007E; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WJII4EgrIrH7; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 66C3316006C; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) Message-ID: <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> Date: Fri, 29 Apr 2022 18:44:54 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Content-Language: en-US To: Lars Ingebrigtsen References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <878rroi5a8.fsf@gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Vincenzo Pupillo , 55163@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 01:29:30 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 05:29:30 +0000 Received: from localhost ([127.0.0.1]:55747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkffd-0003PO-Ls for submit@debbugs.gnu.org; Sat, 30 Apr 2022 01:29:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkffb-0003P9-Mu for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 01:29:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39490) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkffV-0006PM-7N; Sat, 30 Apr 2022 01:29:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BZcUwyy9BDXXedOhgudYUBSeDfg6hwiS+gw7z/DeDqs=; b=gtPtLBhz0Ygt yhs3tzz0H4syDKtXf9316XVDcNZaIWUsxPMOMO/MVEzA4ihwZ+BcETMCvVgCpTWmtN91M8sKqAZfR HCjCNsU6o+v8TPX1VJIltRJgZQhwYDZhzWvTK1rA85PKgndc8LvNajK62Kd6lM2pdRbFLPFQ7XcFW 5yv2ko1fI1pcqsCfps6wkUoH72mLSjnlq0Ovt09vgRoDv9ft4lthMyPjdPqjrQLF5XIlgFFfJ0axV Pf0eudCDcfc8PXiwzbRun9biZCjsGNnyQJGbKJwmipaMPXVZTX2eK3PdbFuvnfi5QUWR7kFZANjzK 0bppLp3P9eMf6YH2OHIYVw==; Received: from [87.69.77.57] (port=2850 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkffU-0001ZV-Mw; Sat, 30 Apr 2022 01:29:21 -0400 Date: Sat, 30 Apr 2022 08:29:24 +0300 Message-Id: <83a6c39m17.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <7b51f5af-cd60-79ff-5cef-36fcdd64b766@cs.ucla.edu> (message from Paul Eggert on Fri, 29 Apr 2022 15:45:44 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <7b51f5af-cd60-79ff-5cef-36fcdd64b766@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 29 Apr 2022 15:45:44 -0700 > Cc: larsi@gnus.org, 55163@debbugs.gnu.org, v.pupillo@gmail.com > From: Paul Eggert > > > 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 01:40:42 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 05:40:42 +0000 Received: from localhost ([127.0.0.1]:55759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkfqT-0003mb-UU for submit@debbugs.gnu.org; Sat, 30 Apr 2022 01:40:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkfqR-0003mM-Tw for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 01:40:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfqL-0007uR-75; Sat, 30 Apr 2022 01:40:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=i34iHCTEnPcAQPl1fZrw2XId6ZoC2lrVNyyI+zs07/Q=; b=LFchBFFwL8eX 4S0Nk6odDeVuoVWtDPzd3giTf84RvQD4M2wlxKL+vbkb4GnDUHoASaghSexLihDRlhmDL1lnZYrno HiiK+7Qtdnbi51qUOaoES1wprqRKGSMqpogLfffM9ERhGw5WvrdyBksU/WYDJonMpGASA9iKz7aON jYhu7m3zAUZLX1H3np/jynjugQBThoTOg5krjXhR6isDCgFeP9dfLbd9Ixuk5c0i0QzKQryBtV58c MLrIaDngsXHnugxOUkV8AyqxRGhZ7bYuQrhFhYM7BlDw3bGbHxf/70bUKEPT1va0Od/Sd+lyfTARQ IjeCn2a4ovs44ppaLAEhlA==; Received: from [87.69.77.57] (port=3530 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfqI-0003IQ-D6; Sat, 30 Apr 2022 01:40:33 -0400 Date: Sat, 30 Apr 2022 08:40:32 +0300 Message-Id: <838rrn9lin.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> (message from Paul Eggert on Fri, 29 Apr 2022 18:44:54 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org, monnier@IRO.UMontreal.CA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 29 Apr 2022 18:44:54 -0700 > Cc: 55163@debbugs.gnu.org, Eli Zaretskii , > Vincenzo Pupillo , > Stefan Monnier > From: Paul Eggert > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 05:10:30 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 09:10:30 +0000 Received: from localhost ([127.0.0.1]:55855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkj7W-0002hP-9j for submit@debbugs.gnu.org; Sat, 30 Apr 2022 05:10:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkj7U-0002hB-Nb for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 05:10:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=G0ULmOYq2K1SAP54jcbcK5cvsai/CCBtsBXOFJV8muU=; b=OV75KpSv7sgOh5MiNIjkOaWwoG AnrPw5ecL1f4+tS/Otx99ef1sT5yHSociJ8ksMbxevSUQB6V6wZpRlrqAuEZb0mPdseVaLvOco66N kunQbKi3K43Fi+a5A9UNNicfB6TNhqWZuXdM2p2leHSVIsLTlKNJ8mwVwP0PcEpTDXkY=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkj7K-0005ss-NW; Sat, 30 Apr 2022 11:10:21 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAKlBMVEWCrLqi3PCr6/yW zuWNvM53pMwWIXQjM4Q1S5FUcZhxlaY3Q1lRZWr///+A617ZAAAAAWJLR0QN9rRh9QAAAAd0SU1F B+YEHgkEMXPsKuIAAAGiSURBVDjLnZQ/T8JAGMYrm8jSDg7E5U6MhDiJEhUGgzpAmDB+AJcWvwDF 3cChi5CYADoILFJucHDhz4CEheM+lL2WlLu2JsqT5u3w63PP+14vJ23IXimyvCuloa/AbwCuAQLW 64aVvTxb/JoHQGN1/9YsUTXNgxKrUQYSap0HBQe4HJoDoE+GDeDfgP5vB4qbOnlgNa7woKgy2VWY o4fum82PAWq0EBLmmNGeVMv1KCWE8gCORtnRdHYwIMkVYFlgQi9IOoQpNh2HPHh8rZoZd9Wn6qjR 8e9KE7qCzavT4Tzewse495LnwWcod0naXzQzpmTKLzVckMhzrd8KYjoRBuxSPKFBgsPB1EwIRwgV SqhQQaiCBEe5qOvmo2m6VhRA4AgbWSztZt7DmF8KDun327yf7GNjnFtObnUN6HjaGoZSCxxc7Aig buBpd2szho3zMwGU1aK9K6stsYHZp6MOD0rQrSXQFC9Q1gO6FwRcjkhV8Qfbzq91gYQIWAawGo8V hONjnmRFti2yEA6tKwQyH1iFA/GKgdanJgDe24eBtuyvH1Kw/DAZoN4eAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIyLTA0LTMwVDA5OjA0OjQ5KzAwOjAwB5IYrwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy Mi0wNC0zMFQwOTowNDo0OSswMDowMHbPoBMAAAAASUVORK5CYII= X-Now-Playing: New Order's _Movement: Remaster (1)_: "Senses" Date: Sat, 30 Apr 2022 11:10:18 +0200 In-Reply-To: <83ee1facp0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Apr 2022 22:53:31 +0300") Message-ID: <87tuab543p.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii 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 modifi [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, Paul Eggert , 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 05:15:34 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 09:15:34 +0000 Received: from localhost ([127.0.0.1]:55860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjCP-0002ot-UI for submit@debbugs.gnu.org; Sat, 30 Apr 2022 05:15:34 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjCN-0002of-4s for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 05:15:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=awjTPPtTYJt3RBcrA2YldqT+oU1vxfssxpOQrqkAGBM=; b=W67WULjwIi7203Tth7vSnVxYOc HzXtp2eR+e7WPEkiyQw4G3idiEBoF/O9KVtzM4XD6Q83fEyLggd63Mgzcr90OMO2MG4OrOuaJ2TqF 1HzOy3NXVnNz3lxlaQI0vVzi902YbRvjGLfWhWPsz1s9xC4TnFb/MVKjeoMRAq58NQb4=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkjCA-0005wh-6t; Sat, 30 Apr 2022 11:15:20 +0200 From: Lars Ingebrigtsen To: Paul Eggert Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAKlBMVEWCrLqi3PCr6/yW zuWNvM53pMwWIXQjM4Q1S5FUcZhxlaY3Q1lRZWr///+A617ZAAAAAWJLR0QN9rRh9QAAAAd0SU1F B+YEHgkEMXPsKuIAAAGiSURBVDjLnZQ/T8JAGMYrm8jSDg7E5U6MhDiJEhUGgzpAmDB+AJcWvwDF 3cChi5CYADoILFJucHDhz4CEheM+lL2WlLu2JsqT5u3w63PP+14vJ23IXimyvCuloa/AbwCuAQLW 64aVvTxb/JoHQGN1/9YsUTXNgxKrUQYSap0HBQe4HJoDoE+GDeDfgP5vB4qbOnlgNa7woKgy2VWY o4fum82PAWq0EBLmmNGeVMv1KCWE8gCORtnRdHYwIMkVYFlgQi9IOoQpNh2HPHh8rZoZd9Wn6qjR 8e9KE7qCzavT4Tzewse495LnwWcod0naXzQzpmTKLzVckMhzrd8KYjoRBuxSPKFBgsPB1EwIRwgV SqhQQaiCBEe5qOvmo2m6VhRA4AgbWSztZt7DmF8KDun327yf7GNjnFtObnUN6HjaGoZSCxxc7Aig buBpd2szho3zMwGU1aK9K6stsYHZp6MOD0rQrSXQFC9Q1gO6FwRcjkhV8Qfbzq91gYQIWAawGo8V hONjnmRFti2yEA6tKwQyH1iFA/GKgdanJgDe24eBtuyvH1Kw/DAZoN4eAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIyLTA0LTMwVDA5OjA0OjQ5KzAwOjAwB5IYrwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy Mi0wNC0zMFQwOTowNDo0OSswMDowMHbPoBMAAAAASUVORK5CYII= X-Now-Playing: New Order's _Movement: Remaster (1)_: "Chosen Time" Date: Sat, 30 Apr 2022 11:15:16 +0200 In-Reply-To: <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> (Paul Eggert's message of "Fri, 29 Apr 2022 18:44:54 -0700") Message-ID: <87pmkz53vf.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Eggert 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Vincenzo Pupillo , 55163@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Paul Eggert 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 06:00:38 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 10:00:38 +0000 Received: from localhost ([127.0.0.1]:55898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkju2-00040z-Cx for submit@debbugs.gnu.org; Sat, 30 Apr 2022 06:00:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkju0-00040k-4M for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 06:00:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42104) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkjtt-0007Ee-Qh; Sat, 30 Apr 2022 06:00:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7I3CiPmg5OoLDK/9/QYvbGd7hhIUhzobNO/IjTHPsPo=; b=AdROfzRAOFz0 cnVcwFYfYlhloQNVjZ5VSP1nbn1ODZR+1OGAZT/ip8cwdsdCkouxz9oAgVnoP2ToI+SjIO7bug9my LHnjEl3g8hWxX/1bLKpmtJNPkbC+H70YaHGnuUVlDJjdySw1ggQ/ii01rQ9mmwsqbJ/hP4wCVBrr5 sViOU8tJWHNAfnPOoGH3XOOJ1lzb3UBnkJdkQaIueZ0wjlWt6z6qOfCSPr9mNHPi5bhL9pEQlM7BO BZzJNNz3U+j9jWHfAR8iYpd6towRliitjUlUgXZ5IOMWOG9ix+r0vRju8zgzHzJjvnTsgsr4D2f5k /kPyInTQNHkp0370+dzWtg==; Received: from [87.69.77.57] (port=3607 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkjti-00018d-8i; Sat, 30 Apr 2022 06:00:19 -0400 Date: Sat, 30 Apr 2022 13:00:21 +0300 Message-Id: <83pmky99hm.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87tuab543p.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Apr 2022 11:10:18 +0200) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: v.pupillo@gmail.com, eggert@cs.ucla.edu, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Paul Eggert , 55163@debbugs.gnu.org, > v.pupillo@gmail.com > Date: Sat, 30 Apr 2022 11:10:18 +0200 > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:21:13 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 11:21:13 +0000 Received: from localhost ([127.0.0.1]:55990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nklA0-0008MC-UX for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:21:13 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:43604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nklA0-0008M1-0b for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 07:21:12 -0400 Received: by mail-wr1-f49.google.com with SMTP id v12so13796760wrv.10 for <55163@debbugs.gnu.org>; Sat, 30 Apr 2022 04:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SJoGcreSjypQMdY/OxzPvDkz4AXPmlv43PnZpZB+UJM=; b=qbQhsglCIeE1wfnshRjqSmdxKibpPo+yD29FkH/4p3VgSeGTJKQkgFl3UeyF288Xjd gH84YUcXP3ZsXTLlZp7pCwFr0H2txs81Jv77H/9dsXa1XvSxClY0wirB1cmROtKF5ZmC PziJIJVgjH2JCjPyMEaVuvDelCGRkhWL3jXSVlKf5SEaTvfHNsissf3BTFBaiqY2PGqm vI9sRKRcCAjkebFyyZ2xMTNa45CyHqIvEu51P7yFEAuWiePyfo0Q5nqpON7FjB8lQ8Il IKGhgqMSc5B2eEkTR7/m5UnS/9VMDaI6ZxOgDpmHS3KsOpn/6uJcgn2uSIAWAFNWXxAA 6neQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SJoGcreSjypQMdY/OxzPvDkz4AXPmlv43PnZpZB+UJM=; b=0SCPzFL1P0MeEr02mtsydNRCk0l9GQqgRmS+vF+/Ivt+E+eSShx/SvfuGPEnEZrcjA qfYGWTT1HVNVBsafwxqCyqKOI6gjIMCf/n1jmOlU7NesOgDUFMVPuP2nDzBLIIMAyfQ8 IT4qb4hBhDxFft/7lKcT+rBKiGa5zSGXvocj+1fpUav6iCcf+QLfKshFlxjlS5uMnuEz vmT5WzqqjQzME/eEUeBD96D23DYIZ+FdCurhgmCVJ+rhwIcsJdqsT8yfopdwhXCP1B8K ihWE0eFHBdDqgANfNIqGMpM+6NJTEwmGsv7uEw+1Du8M1dr3JfmOkwSnO5WQPkoxWYcj ggHw== X-Gm-Message-State: AOAM533kvHOk/Eph+QmDC/lNLz6HQMCxDdEBubNMnATqam3frovVr3PT QeJyjKDcj9P+ksbn/zB/3iI= X-Google-Smtp-Source: ABdhPJypei0BkiXf4KkbVqbD2JPXKWPVqTjHByaRrM/vciGvrwDC5j/yon9LCKgf1fOmNzQEjaTFdQ== X-Received: by 2002:a5d:44cf:0:b0:20a:c5d2:b6c3 with SMTP id z15-20020a5d44cf000000b0020ac5d2b6c3mr2691505wrr.177.1651317666035; Sat, 30 Apr 2022 04:21:06 -0700 (PDT) Received: from zarathustrawsp500.localnet (93-43-201-114.ip93.fastwebnet.it. [93.43.201.114]) by smtp.gmail.com with ESMTPSA id v13-20020adfa1cd000000b0020c5253d8b9sm1736554wrv.5.2022.04.30.04.21.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Apr 2022 04:21:05 -0700 (PDT) From: Vincenzo Pupillo To: Paul Eggert , Eli Zaretskii 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 Message-ID: <4464915.LvFx2qVVIh@zarathustrawsp500> In-Reply-To: <838rrn9lin.fsf@gnu.org> References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> <838rrn9lin.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:25:54 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 11:25:54 +0000 Received: from localhost ([127.0.0.1]:56004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nklEK-0008Tc-VV for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:25:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nklEG-0008TN-6T for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 07:25:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42964) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nklE9-0003Nq-QJ; Sat, 30 Apr 2022 07:25:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=m70XubLzYcrod9/HKiwtK8SCXj+QMFjWMSDoGDDI6KE=; b=AjDSD1bSfdA+ wg68G2pA+il/ZVx5MAFT4Y85mNDZ9tm4UlqotCh8NWPY1UzyTVu0iAZW9ibjhRRQMIAGkuQ36yx9M Rz6rBpxLeyk2t2/L/5KDZwon0zcbTlIAPDqvP5lNciQrD9gK2lR1taG4dxjBjTmGjtmbH5E/BQSI1 5EE6NRibuwuUJ2kg7QQElfayrYiGUlxug/fIpvK+LkfWbHYoertHfjI1ZA7JKk1wYd4zn724AXdkC MsR0aZm9M4Ssn8g+ZpXEpFsqXRYCn7ifbKCsEIq4ntMa1g59foeOgBh5Q7A3/hwyH83AI+Y0EFBRh zX8O/isaHFAy+0ykJNJGNw==; Received: from [87.69.77.57] (port=1068 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nklE8-0005xd-G5; Sat, 30 Apr 2022 07:25:29 -0400 Date: Sat, 30 Apr 2022 14:25:31 +0300 Message-Id: <83ee1e95jo.fsf@gnu.org> From: Eli Zaretskii To: Vincenzo Pupillo In-Reply-To: <4464915.LvFx2qVVIh@zarathustrawsp500> (message from Vincenzo Pupillo on Sat, 30 Apr 2022 13:21:04 +0200) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> <838rrn9lin.fsf@gnu.org> <4464915.LvFx2qVVIh@zarathustrawsp500> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, eggert@cs.ucla.edu, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Vincenzo Pupillo > Cc: larsi@gnus.org, 55163@debbugs.gnu.org, monnier@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? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 08:32:27 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 12:32:27 +0000 Received: from localhost ([127.0.0.1]:56077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkmGw-0001un-RW for submit@debbugs.gnu.org; Sat, 30 Apr 2022 08:32:27 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:39914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkmGv-0001qH-Eg for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 08:32:26 -0400 Received: by mail-wr1-f48.google.com with SMTP id d5so13963761wrb.6 for <55163@debbugs.gnu.org>; Sat, 30 Apr 2022 05:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7AhNPs2mGQaoxbkyMAH2EeIQIE6FLJwJwRkyW9Ljrcg=; b=OlPC8nvlUL1LayJ9yhvtFL5J9/+8oTnx3uOq47cCqV/Z0mGSkw6FGM1HqHPDLA//Ms a4lxX/iy1eqedQlWJF8TR8pvfMVMSD1JI0tWcDsV47yceI+lH5waASiJPvEcmUWx/E45 8EEhflUenWfd+qaWQ1bTbjPu2HEEqR4Bs7VMwecWOCOCAj7RaQyylevGUGeUIQ9rhunn nN2ZXUUX4WEmOooO6GYNr+tCblsuN0OUWptos92ZX5UmvkN8Mr6dZRrH99Nql1h5fgh6 9MiXEdsy0rYEb98FG3j5P0LYicwyZbmt1yIwaKQgajdhjA9W+wmZcbTRZqfvE57sFJvt RouQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7AhNPs2mGQaoxbkyMAH2EeIQIE6FLJwJwRkyW9Ljrcg=; b=3pzjfJpbcOwYz/iZn89SuGkWkg57CdwefrcpLPQHNR3AOL70HRYfHwoS0tXSBWe1no mvSQSGfOXWw5ljZd+U0PAy/I85KPIOfNrc2K4siuR3a8mGMt4Mc0IrN40Wvc48uGPElM y0KZzzyY2gffLi5uHkPjYWiAGlqZViUykmT+TM49IsHgu79ko5kwDbNvpXbYHp1V3LPK Hu1ipP6zvPfNc+sOvANifL+k2W9bx7FjdED+pGHS3qyV7aoyKZgiMRpx6PqEPPIinGNJ rgc3oEFsTq6Rt9yc5sf+m1uiWtK+MzGiWrgGtcjTz9SX4sbuNt3M+s8DU4R8E2FDkpqx BFdg== X-Gm-Message-State: AOAM53336z8qXXe3bb1v0LQIbdG0on0VD8BVB4Y08NI/CNtLQud3/h5w kFjgOc8kBfkYmDIWgjuKEtc= X-Google-Smtp-Source: ABdhPJyRXhblfxKZZzMwo1E1jb7IocdZJ/LyW5foE6eLyy1+VfE1z4HiF9dPd0ptYUnSW8fOnwajGQ== X-Received: by 2002:a5d:4148:0:b0:20a:d2de:d960 with SMTP id c8-20020a5d4148000000b0020ad2ded960mr2920501wrq.61.1651321939407; Sat, 30 Apr 2022 05:32:19 -0700 (PDT) Received: from zarathustrawsp500.localnet (93-43-201-114.ip93.fastwebnet.it. [93.43.201.114]) by smtp.gmail.com with ESMTPSA id r3-20020a7bc083000000b003942a244f32sm1692096wmh.11.2022.04.30.05.32.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Apr 2022 05:32:18 -0700 (PDT) From: Vincenzo Pupillo To: Eli Zaretskii 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 Message-ID: <3233184.5fSG56mABF@zarathustrawsp500> In-Reply-To: <83ee1e95jo.fsf@gnu.org> References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <4464915.LvFx2qVVIh@zarathustrawsp500> <83ee1e95jo.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, eggert@cs.ucla.edu, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In data sabato 30 aprile 2022 13:25:31 CEST, Eli Zaretskii ha scritto: > > From: Vincenzo Pupillo > > Cc: larsi@gnus.org, 55163@debbugs.gnu.org, monnier@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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 08:50:19 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 12:50:19 +0000 Received: from localhost ([127.0.0.1]:56106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkmYF-0004iQ-0A for submit@debbugs.gnu.org; Sat, 30 Apr 2022 08:50:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkmYC-0004i9-Ji for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 08:50:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44028) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkmXz-0008QE-UR; Sat, 30 Apr 2022 08:50:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=yOxie8+tJ3cu0sOMGjtl1IRQn07X/C+Ukwuyi8hcqJY=; b=VepWmDPglY7z FOsWP3AYzDNm9tNzb2K5XUVZutrgZ7OpFiudL3IvBNTcnTFVP9vI0Hu1LLvFkxFzFNCYe6GVLt5A4 pN6ciC0dxfpqfUXwJfQMMDlPBuinma4LKOBUI/d5i5aUpLtSQV6BeuBO7LzkwE/fKIxoksMp6Z7HA VRQFfBAzlT+GD1FiV0QPc4vOHRwMUd5Jz1BDTqSFkXcowyBufVr8vSZM689r7hTInEIo1SywY1Cy6 PhYtB9ZVtFiRAqLKGPC5VhCbzj2P9mptbIU+D3hcm7xQhhF/y6HS56Mdj1uemYUXGpqwIQr5cyHSN 5qW8jIlqe2LX4DolY42rPA==; Received: from [87.69.77.57] (port=2298 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkmXw-0005Tj-He; Sat, 30 Apr 2022 08:50:01 -0400 Date: Sat, 30 Apr 2022 15:50:04 +0300 Message-Id: <83a6c291mr.fsf@gnu.org> From: Eli Zaretskii To: Vincenzo Pupillo In-Reply-To: <3233184.5fSG56mABF@zarathustrawsp500> (message from Vincenzo Pupillo on Sat, 30 Apr 2022 14:32:17 +0200) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <4464915.LvFx2qVVIh@zarathustrawsp500> <83ee1e95jo.fsf@gnu.org> <3233184.5fSG56mABF@zarathustrawsp500> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, eggert@cs.ucla.edu, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Vincenzo Pupillo > Cc: eggert@cs.ucla.edu, larsi@gnus.org, 55163@debbugs.gnu.org, monnier@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? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 09:22:22 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 13:22:22 +0000 Received: from localhost ([127.0.0.1]:56117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkn3F-0005TA-T0 for submit@debbugs.gnu.org; Sat, 30 Apr 2022 09:22:22 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:34474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkn3E-0005Sr-3k for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 09:22:21 -0400 Received: by mail-wr1-f46.google.com with SMTP id q23so14080074wra.1 for <55163@debbugs.gnu.org>; Sat, 30 Apr 2022 06:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3uIxuj8skSVUFjXgzfML/p28Qwi/rc0hHCYWDzrXPfQ=; b=i5S9f5faZYq6uVNplDDQqg7wMUnGYAEh45y8JaYfRd9+M8TL8ijtQIMQEDQl0CQgtD a5XfGdtOwzr7rUXBZDjr4KUZ1zvBtaQdY+67yFOqTTQ8hBf0TLMYb0VaHS6nuRz66Wad 4m09A/DNuSZdpTyyE/0EQl5DqobwDLbL2gFSLyo0bY3XwtZzOxXc/ALEdWNYHEbFGSwt EaHwW2xD3aixFzScs71Gj+6E74iDCQdqT4LctQBvUVqC6yoMiRwULPWMyyhbQ/2Htn4M zEAbV+FsOfA74/58VRPWOsm1THV0fBTAQFiaYC+foftEnp55pjD50Q053rXfXvZkoO08 I5FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3uIxuj8skSVUFjXgzfML/p28Qwi/rc0hHCYWDzrXPfQ=; b=oY7n+KKJCGcoOlo4fuBQjbphWSHT62WmYUggiIJGS9WvDgOTiJIo9zidJdj1DyGxXA sS8AuQ0ij12fw8dOU3amwA+iydl3+6w0P4WkzJYNbCSCh8QZo4IRRb2yT5YTCuLXjLL3 7WSjcdzG/HdZwDX6veWeGZYjVg3+/Q+WfbK1VKteTaUMpxFi+OdbTgGFPMAsCLvNLXQ6 NWM4tFmsUjHXOJIAQMT2eRFdkEGuPBe6RGkXTWShsnF+Jc1WXL+Mkfu2JI4SofsnrlQ4 bJ8h6SsAPjY1YONhAHiKYmbeC7nFE5ES5A6t6W8jvErZKZwXcMyAlSZ8jl1A5Wea989g kVbw== X-Gm-Message-State: AOAM5322waqQYz5vOff7e0xU4sZgIgVJATsFx5onSz5NxnvoGUzl3RI0 hjkU8Q1dFQbpg0tDgeTD0xU= X-Google-Smtp-Source: ABdhPJzUjFjUvLAdewd02T3DMm5823/2lfuNhK1mO6M5u3g0scOvBOfdWGG9oWHwZvyCZ8oK1jiDmw== X-Received: by 2002:a5d:6c65:0:b0:20c:5230:f145 with SMTP id r5-20020a5d6c65000000b0020c5230f145mr2975091wrz.337.1651324934130; Sat, 30 Apr 2022 06:22:14 -0700 (PDT) Received: from zarathustrawsp500.localnet (93-43-201-114.ip93.fastwebnet.it. [93.43.201.114]) by smtp.gmail.com with ESMTPSA id l2-20020adfb102000000b0020c547f75easm1653026wra.101.2022.04.30.06.22.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Apr 2022 06:22:13 -0700 (PDT) From: Vincenzo Pupillo To: Eli Zaretskii 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 Message-ID: <8229750.NyiUUSuA9g@zarathustrawsp500> In-Reply-To: <83a6c291mr.fsf@gnu.org> References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <3233184.5fSG56mABF@zarathustrawsp500> <83a6c291mr.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, eggert@cs.ucla.edu, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In data sabato 30 aprile 2022 14:50:04 CEST, Eli Zaretskii ha scritto: > > From: Vincenzo Pupillo > > Cc: eggert@cs.ucla.edu, larsi@gnus.org, 55163@debbugs.gnu.org, > > monnier@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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 16:51:34 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 20:51:34 +0000 Received: from localhost ([127.0.0.1]:59149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nku3y-0005Zz-Fy for submit@debbugs.gnu.org; Sat, 30 Apr 2022 16:51:34 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nku3x-0005Zl-Bt for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 16:51:33 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B71E21600C2; Sat, 30 Apr 2022 13:51:26 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ProwfvsPsoRI; Sat, 30 Apr 2022 13:51:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 934FC1600D1; Sat, 30 Apr 2022 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HJU1eDPzdSwZ; Sat, 30 Apr 2022 13:51:25 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 151D31600C2; Sat, 30 Apr 2022 13:51:25 -0700 (PDT) Message-ID: <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> Date: Sat, 30 Apr 2022 13:51:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <83pmky99hm.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Lars Ingebrigtsen , v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 17:04:04 2022 Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 21:04:04 +0000 Received: from localhost ([127.0.0.1]:59161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkuG4-0005tb-9f for submit@debbugs.gnu.org; Sat, 30 Apr 2022 17:04:04 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkuG2-0005t8-P8 for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 17:04:03 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4FD701600C2; Sat, 30 Apr 2022 14:03:57 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FnI2OmK0deOH; Sat, 30 Apr 2022 14:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 776521600D1; Sat, 30 Apr 2022 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SjcrfizNJbQ8; Sat, 30 Apr 2022 14:03:56 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 257341600C2; Sat, 30 Apr 2022 14:03:56 -0700 (PDT) Message-ID: Date: Sat, 30 Apr 2022 14:03:55 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Lars Ingebrigtsen References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> <87pmkz53vf.fsf@gnus.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <87pmkz53vf.fsf@gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: Eli Zaretskii , Vincenzo Pupillo , 55163@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 01:38:49 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 05:38:49 +0000 Received: from localhost ([127.0.0.1]:59365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nl2ID-0001bc-87 for submit@debbugs.gnu.org; Sun, 01 May 2022 01:38:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nl2IB-0001bN-1j for 55163@debbugs.gnu.org; Sun, 01 May 2022 01:38:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60544) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nl2I4-0008AK-TW; Sun, 01 May 2022 01:38:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+nXBdBM7Js4UfSBkvkZ5Si0riuNbbGb8sOucEsqMCbQ=; b=Dt2uIKMEOjjW 5yLd68Bw/Ab30xsauoID+yZVomVE0RM7pBqk12QPuomeuSVqj3BcvVfuE6MubhGhThmt5i9ajpnVC hTb3C27TAMnOIVZEzLinwGJF5Bnz3sdxnfNgILDuI7UXPeVxN2E6kYfvsBubNMG/WIpsX8O+WTHj3 o+Ejtum/eyVse2RHq6zFrPCfDCX8sTBB4gWoR2lzdQp9f2D7BBRyUvNo+4swxdLQbqHJXe7HPytPv 6m5/BwSo1DPcQWnNbiPTLPjYmlKfhQB8UeSIPq13IPdaZHgcjWDYuYfaX9tlCY+tDPYlK5xcVsB06 7wWNsMz+iaDPNHF9Bb9rpQ==; Received: from [87.69.77.57] (port=1400 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nl2Hx-0007KI-Of; Sun, 01 May 2022 01:38:35 -0400 Date: Sun, 01 May 2022 08:38:39 +0300 Message-Id: <83mtg17qxs.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> (message from Paul Eggert on Sat, 30 Apr 2022 13:51:24 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 30 Apr 2022 13:51:24 -0700 > Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, > Lars Ingebrigtsen > From: Paul Eggert > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 01:41:11 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 05:41:11 +0000 Received: from localhost ([127.0.0.1]:59371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nl2KU-0001fU-Pr for submit@debbugs.gnu.org; Sun, 01 May 2022 01:41:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nl2KS-0001fG-2p for 55163@debbugs.gnu.org; Sun, 01 May 2022 01:41:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60566) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nl2KM-0008TA-GF; Sun, 01 May 2022 01:41:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=PBE/w8c6pn1OM9HS+VzLkTj+0+zEj0G0Tjj9iLtYG0M=; b=Zq8JqVIjpWms HamiZzuBecRj1A/7Q2mRJ/ke/HzBGUXLHre4VUDGSCWMF+7H5hASJsIToAjKd0/fyRnJDu3V9tkBp YoN/q4GAUpEkSmehz0It2QxueaOsnRSgd4g6xZ13ZLonk9NQ/Sl7QNhz9bHpbsSsdcmKgkLauUg+R tT5HN/HBYvlwkEmLG3LjgBOOUwHKTy7x5Hx64cAZjgCYwpSIyjVs740BP+dWNLfwmppxhnY69EG26 19HX9rCyIShDt8rdp3UOYaSs217ahdo+3ORe9l7qmop3CukkUAh5PVy1hzxQOfZ51YuFpZedKo0R6 UV67o/QlK4/hDgjfO0uUDQ==; Received: from [87.69.77.57] (port=1534 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nl2K5-0001N3-Ec; Sun, 01 May 2022 01:41:00 -0400 Date: Sun, 01 May 2022 08:40:51 +0300 Message-Id: <83levl7qu4.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Sat, 30 Apr 2022 14:03:55 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> <87pmkz53vf.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org, monnier@IRO.UMontreal.CA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 30 Apr 2022 14:03:55 -0700 > Cc: 55163@debbugs.gnu.org, Eli Zaretskii , > Vincenzo Pupillo , > Stefan Monnier > From: Paul Eggert > > 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? From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 11:00:14 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 15:00:14 +0000 Received: from localhost ([127.0.0.1]:33939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlB3W-0002nm-8b for submit@debbugs.gnu.org; Sun, 01 May 2022 11:00:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlB3U-0002fp-Nh for 55163@debbugs.gnu.org; Sun, 01 May 2022 11:00:13 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 27C671600B3; Sun, 1 May 2022 08:00:07 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EPVnKYUEkv3r; Sun, 1 May 2022 08:00:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 129EB1600D1; Sun, 1 May 2022 08:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LpIuTt49seLz; Sun, 1 May 2022 08:00:05 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D32041600B3; Sun, 1 May 2022 08:00:05 -0700 (PDT) Message-ID: <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> Date: Sun, 1 May 2022 08:00:05 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <83mtg17qxs.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 11:08:08 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 15:08:08 +0000 Received: from localhost ([127.0.0.1]:33952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlBBA-0004yl-KA for submit@debbugs.gnu.org; Sun, 01 May 2022 11:08:08 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlBB9-0004yX-Eu for 55163@debbugs.gnu.org; Sun, 01 May 2022 11:08:07 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0942F1600B3; Sun, 1 May 2022 08:08:02 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qvA5sB49ee_u; Sun, 1 May 2022 08:08:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4F6C81600D1; Sun, 1 May 2022 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w6Eft_ip8iDH; Sun, 1 May 2022 08:08:01 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1D38D1600B3; Sun, 1 May 2022 08:08:01 -0700 (PDT) Message-ID: <51023b72-7cdd-950d-5877-58ab1deea9c3@cs.ucla.edu> Date: Sun, 1 May 2022 08:08:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> <87pmkz53vf.fsf@gnus.org> <83levl7qu4.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <83levl7qu4.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org, monnier@IRO.UMontreal.CA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 11:42:07 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 15:42:07 +0000 Received: from localhost ([127.0.0.1]:33974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlBi3-0005nW-Dr for submit@debbugs.gnu.org; Sun, 01 May 2022 11:42:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlBi0-0005n1-MZ for 55163@debbugs.gnu.org; Sun, 01 May 2022 11:42:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39068) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlBhu-0006lP-58; Sun, 01 May 2022 11:41:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3d9Yn0gr4c6oSvK+tYvzyLRd6cApFXzkB2VwBX1GBmc=; b=B2hgAADx3t47 S9SmA3P3nKoD15Ozoa4H5fIhxJtYaMjMeEJGLR8eyzqdLGtQdQqp6BcyczgWZ5idA93tUHQ1PJo6+ V4jWLRWs8GNndRNObCX3EDS6A9eXfUKbMuAdxzbJ6ziBRkl+MxVd5JYhdhZhFTUKue2XlatXp64Uc L6Tgb74sn+uT0WQQ3A/IwgVEYDx7YZKAVXgzfUm+XiV63zJFkn3kY30jjk8fNdhXvb5p+sennLXoL 1OdpGOX3ZWd+bANbBdpgFLl2NYGwaX+KXpxl6rIIDVbSfnzWCRbbQRiKk4Ici+Wd5lBRRjahwjZ2q kYZ1Kbk0aTNNLWkM5JuDeQ==; Received: from [87.69.77.57] (port=3593 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlBht-0007GG-Kj; Sun, 01 May 2022 11:41:57 -0400 Date: Sun, 01 May 2022 18:42:04 +0300 Message-Id: <83pmkx5kfn.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> (message from Paul Eggert on Sun, 1 May 2022 08:00:05 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 1 May 2022 08:00:05 -0700 > Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org > From: Paul Eggert > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 12:17:17 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 16:17:17 +0000 Received: from localhost ([127.0.0.1]:34030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlCG5-0006hc-9Z for submit@debbugs.gnu.org; Sun, 01 May 2022 12:17:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlCG4-0006hQ-8R for 55163@debbugs.gnu.org; Sun, 01 May 2022 12:17:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 60E5F1600D4; Sun, 1 May 2022 09:17:10 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id MhsfsLVzw2pt; Sun, 1 May 2022 09:17:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A6E291600D5; Sun, 1 May 2022 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Y6DzDMLyLRiR; Sun, 1 May 2022 09:17:09 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7762F1600D4; Sun, 1 May 2022 09:17:09 -0700 (PDT) Message-ID: Date: Sun, 1 May 2022 09:17:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <83pmkx5kfn.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 12:43:10 2022 Received: (at 55163) by debbugs.gnu.org; 1 May 2022 16:43:10 +0000 Received: from localhost ([127.0.0.1]:34054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlCf8-0007Jc-Af for submit@debbugs.gnu.org; Sun, 01 May 2022 12:43:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlCf6-0007JQ-9I for 55163@debbugs.gnu.org; Sun, 01 May 2022 12:43:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40098) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlCf0-0005x7-BW; Sun, 01 May 2022 12:43:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5WzyC/owPZgdilLTT7wtaRIM9o222oP1Hxuuc2AxaOM=; b=I/PB40sY1AHd RiWCVg01TB2b1Ir8pqztBflyzjjd5zmP58xdwm1Zzc/DMLvJuwRouh/QPvCICNUI14IOT/nfUHMs6 WmOUxjYDN9MNkTRBzlLJNQmNf5FLrJeNZ3DXagORDpQXGrbah5rL5wuZz6U/SQrHXwxudx3mHtXUw LNYO4aVNyQxDqZUNd2i2atE49o3UA+PkUKvieBJMjVZDRdiroBu0BnX3J+qeGpaR9BdGI1m1uB0zX Uaxv0Cs9NSUWIAar4YSyHOknIL/TC92sxwy23vSAxCur7p7a8wx3z/QROE8fiyYMe1wNDlAGnPh7t PVRMd3ycGwnSUwNPiA67JQ==; Received: from [87.69.77.57] (port=3379 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlCez-0002gz-Qp; Sun, 01 May 2022 12:43:02 -0400 Date: Sun, 01 May 2022 19:43:08 +0300 Message-Id: <83ilqp5hlv.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Sun, 1 May 2022 09:17:09 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 1 May 2022 09:17:09 -0700 > Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org > From: Paul Eggert > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 02 13:27:23 2022 Received: (at 55163) by debbugs.gnu.org; 2 May 2022 17:27:23 +0000 Received: from localhost ([127.0.0.1]:37911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlZpT-0001Kt-5s for submit@debbugs.gnu.org; Mon, 02 May 2022 13:27:23 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlZpR-0001Kg-93 for 55163@debbugs.gnu.org; Mon, 02 May 2022 13:27:21 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 60A041600ED; Mon, 2 May 2022 10:27:15 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qFpYTUXlaJXi; Mon, 2 May 2022 10:27:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A6F341600EF; Mon, 2 May 2022 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qiuZ-lFqXiK6; Mon, 2 May 2022 10:27:14 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 768F61600ED; Mon, 2 May 2022 10:27:14 -0700 (PDT) Message-ID: Date: Mon, 2 May 2022 10:27:14 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> <83ilqp5hlv.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode In-Reply-To: <83ilqp5hlv.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 02 13:58:09 2022 Received: (at 55163) by debbugs.gnu.org; 2 May 2022 17:58:09 +0000 Received: from localhost ([127.0.0.1]:37926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlaJE-0002P8-Tb for submit@debbugs.gnu.org; Mon, 02 May 2022 13:58:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlaJD-0002Oj-3d for 55163@debbugs.gnu.org; Mon, 02 May 2022 13:58:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33288) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlaJ6-0005dB-T0; Mon, 02 May 2022 13:58:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ohVsYw+oddXqL5SqIPR4RKSyp2GdhstRtw67dbGVA8U=; b=lVhE+5ixyU57 tdUrCxUXKmRVPF2k3h3fKneut59K+ljd++JW6+5u9IBmMPi/sVOXZ1OdVomnjP8xteY/IlrmTNHuk hEowM8XUI9yfOIAHWrz9iS/IjLiQK/RHNcPGsPenfBc+HcZbN8shV1uZo20E5dn8evXyYNSV6d24L znNCZ75ZvhA111xH8MmtAkbn1H7ALOqSovcfJr62TWphSn00Jk31elM4I0o75Ow7rnXOxjtS2lRA9 Mu6Hu7awGKAbkiKGb0hsVwFmq5ya3bt/H/HlAFOV6mRA+dQ07/n7AdqBAxUawT4F4uTXsBYY+UM2e lFFHclR3iS5whQar6+UyLg==; Received: from [87.69.77.57] (port=1183 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlaJ6-0007PT-9c; Mon, 02 May 2022 13:58:00 -0400 Date: Mon, 02 May 2022 20:58:10 +0300 Message-Id: <83wnf34y19.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Mon, 2 May 2022 10:27:14 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> <83ilqp5hlv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 2 May 2022 10:27:14 -0700 > Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org > From: Paul Eggert > > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 02 19:17:50 2022 Received: (at 55163) by debbugs.gnu.org; 2 May 2022 23:17:50 +0000 Received: from localhost ([127.0.0.1]:38287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlfIc-00036Y-F3 for submit@debbugs.gnu.org; Mon, 02 May 2022 19:17:50 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlfIa-00036K-Ee for 55163@debbugs.gnu.org; Mon, 02 May 2022 19:17:48 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EFF3B1600F4; Mon, 2 May 2022 16:17:42 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CENG-uoVGovm; Mon, 2 May 2022 16:17:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2D87F1600FC; Mon, 2 May 2022 16:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FqOymbZG9xaN; Mon, 2 May 2022 16:17:42 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0B8341600F4; Mon, 2 May 2022 16:17:42 -0700 (PDT) Message-ID: <03ad7708-7e43-245a-1198-ce35e335e84f@cs.ucla.edu> Date: Mon, 2 May 2022 16:17:38 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> <83ilqp5hlv.fsf@gnu.org> <83wnf34y19.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <83wnf34y19.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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? From debbugs-submit-bounces@debbugs.gnu.org Mon May 02 22:32:42 2022 Received: (at 55163) by debbugs.gnu.org; 3 May 2022 02:32:42 +0000 Received: from localhost ([127.0.0.1]:38361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nliLC-0007to-6n for submit@debbugs.gnu.org; Mon, 02 May 2022 22:32:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nliL6-0007tY-Rj for 55163@debbugs.gnu.org; Mon, 02 May 2022 22:32:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46244) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nliL0-00082Q-Bv; Mon, 02 May 2022 22:32:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3v5hmdWI0/YDVDCVhX9WhP1pKy/AJhg0tnBAt01JxjI=; b=fcoi/QBJfTay bNRIW5wTH0+04De9bHOaxfLo7sgT32niy+zB+V9qv271g7YhpMM4CMh0qYQ7os5KMAaD1DTImzhK6 qPNG6c4K/bB4mkdnyOULBrcD8uqpMslFPWjQh9EAmoiEtk9Vthx/FDXS+USWNHgsnQKTLbmACvPwj r+t4ZecUNarRKNgn9FcvICM55XIbddzSWMPXKlbS+2xkOysLBKxT7qTpwXGn1V9pUr1ay99qpfuzY 26B/dmN0/g2IaDkixu6PfaV3wuTKq/Qrk/FEiQlQf2GYQwwIKqLsW+ON1hph8ThFQnBalUfcBOy9h 4IOGxZtWn1ItUQAfecpScg==; Received: from [87.69.77.57] (port=4874 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nliKz-0006t8-HS; Mon, 02 May 2022 22:32:30 -0400 Date: Tue, 03 May 2022 05:32:39 +0300 Message-Id: <83sfpr4a7s.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <03ad7708-7e43-245a-1198-ce35e335e84f@cs.ucla.edu> (message from Paul Eggert on Mon, 2 May 2022 16:17:38 -0700) Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> <83ilqp5hlv.fsf@gnu.org> <83wnf34y19.fsf@gnu.org> <03ad7708-7e43-245a-1198-ce35e335e84f@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 2 May 2022 16:17:38 -0700 > Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org > From: Paul Eggert > > >>> 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 02 22:52:32 2022 Received: (at 55163) by debbugs.gnu.org; 3 May 2022 02:52:32 +0000 Received: from localhost ([127.0.0.1]:38366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlieN-0008OA-UX for submit@debbugs.gnu.org; Mon, 02 May 2022 22:52:32 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlieM-0008Ny-Jj for 55163@debbugs.gnu.org; Mon, 02 May 2022 22:52:30 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 093061600FC; Mon, 2 May 2022 19:52:25 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id haS69g6FJcJq; Mon, 2 May 2022 19:52:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5DD261600FF; Mon, 2 May 2022 19:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kek0Uham37CW; Mon, 2 May 2022 19:52:24 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 37CED1600FC; Mon, 2 May 2022 19:52:24 -0700 (PDT) Message-ID: Date: Mon, 2 May 2022 19:52:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Content-Language: en-US To: Eli Zaretskii References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <83y1zo9n3o.fsf@gnu.org> <87y1zof944.fsf@gnus.org> <83wnf89mcj.fsf@gnu.org> <0a39a220-6298-8ed4-87bd-414702cd9b57@cs.ucla.edu> <83ee1facp0.fsf@gnu.org> <87tuab543p.fsf@gnus.org> <83pmky99hm.fsf@gnu.org> <56e6d32c-7583-dbd9-85ee-e43d32a6feb1@cs.ucla.edu> <83mtg17qxs.fsf@gnu.org> <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> <83pmkx5kfn.fsf@gnu.org> <83ilqp5hlv.fsf@gnu.org> <83wnf34y19.fsf@gnu.org> <03ad7708-7e43-245a-1198-ce35e335e84f@cs.ucla.edu> <83sfpr4a7s.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <83sfpr4a7s.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55163 Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From unknown Fri Aug 15 16:17:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 31 May 2022 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator