Dear org-mode developers, Ihor,
the following is with GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo
version 1.16.0)
of 2024-02-27
with point on the following frame for a clock table:
#+BEGIN: clocktable :scope ("/home/absolute/path/file.org_archive")
#+END:
org-clock-report with
emacs -Q
(that is, with Org mode version 9.6.15 (release_9.6.15 @
/home/xxxx/src/emacs-master--32b4f9d21b14190f1ed1611515751abe4b90fa68--2024-02-27T09-36+01-00/lisp/org/)
produces a nice clock report table.
If instead I use a very fresh org-mode from main, specifically
Org mode version 9.7-pre (release_9.6.22-1309-g8507ef @
/home/xxxx/src/org-mode/lisp/)
like so:
emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp -Q
org-clock-report
with point on said frame of a clock table produces
Updating dynamic block ‘clocktable’ at line 13...
org-clock-sum: Wrong type argument: fixnump, nil
file.org_archive has 2376 clock lines.
The problem does not occur with file.org which has
only 86 clock lines. I especially archive the nodes
with clock lines, because or performance reasons.
Doing a git bisect produced:
2e901ed23667b04642847701bae2070862b8ee6e is the first bad commit
commit 2e901ed23667b04642847701bae2070862b8ee6e
Author: Ihor Radchenko <yanta...@posteo.net>
Date: Fri Feb 3 15:08:18 2023 +0300
org-clock-sum: Optimize performance
* lisp/org-clock.el (org-clock-sum): Do not re-parse the timestamps,
reusing already-parser element.
lisp/org-clock.el | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
I cannot disclose said file, because it contains loads
of sensitive data. I extracted the clock lines only,
but a single node with a LOGBOOK drawer filled with
this clock lines does not trigger the bug. But I would
be happy to test a patch on my file.org to test it (or
help otherwise).
HTH, Gregor
