obsolete timestamp with cdr 1 about ekg HOT 14 CLOSED

Excellent! Even though I can't reproduce any failure, this helps narrow things down, and I found some weirdness, which I fixed. To test out, please evaluate the following on your system and try again; I hope it will be fixed. If so, I'll check it in and push this fix to the triples module.

(defun triples-backups-maybe-backup (db &optional filename)
  "If it is time for DB to be backed up, then back it up.
FILENAME is optional, as in `triples-connect', if not given will
default to the standard triple database given in
`triples-default-database-filename'."
  (let* ((backup-info (triples-backups-configuration db))
         (strategy-func (intern (format "triples-backups-strategy-%s"
                                        (plist-get backup-info :strategy)))))
    (unless backup-info
      (error "`triples-backups-setup' needs to be called on this database before trying to back up."))
    (unless (fboundp strategy-func)
      (display-warning
       'triples
       (format "Triples backup strategy %s not found, defaulting to `triples-backups-strategy-daily'"
               strategy-func)
       :error))
    (when (funcall (or (symbol-function strategy-func) #'triples-backups-strategy-daily)
                   (plist-get backup-info :last-update-time))
      (triples-backup db filename (plist-get backup-info :num-to-keep))
      (apply #'triples-set-type db 'database 'backup (plist-put backup-info :last-update-time (time-convert (current-time) 'integer))))))

(defun triples-backups-strategy-daily (last-update)
  "Backup strategy to create a change daily at most.
LAST-UPDATE is the time of the last update."
  (>= (/ (- (float-time (current-time)) (float-time last-update)) 86400)
      1))

from ekg.

Thank you for reporting this bug. I don't think this error message is coming from ekg, and I haven't seen anything like it. Without further information, I'm not sure it's possible to proceed. What would help is if you could edebug into ekg-capture-finalize and see where in that function the message appears. Given that, I might be able to speculate on what could be going wrong.

from ekg.

I have the exact same message "obsolete timestamp with cdr 1" when I ekg-capture-finalize. I tried with emacs -q and only ekg and triples installed and get the same message.

toggle-debug-on-error gives no extra message at all, edebug-mode the same.

By the way, I also get the ewoc-locate: Wrong type argument: ewoc, nil error-message that was reported, #15.

I am an elisp-noob, but if I can do anything to help find the issue please advise.

from ekg.

I single-stepped through ekg-capture-finalize while watching the Messages window for the warning. I also wasn't able to identify the line of code where the warning originated, even though I stepped into called functions too. Then I ran out of time.

from ekg.

@notuntoward thank you for stepping through. Do you mean to say you got to the end without seeing the message? Did it come after the function exited? I think at this point don't bother stepping inside, just trace through and see what line it's coming from, which will help.

For both you are @molekular, can you try on an emacs run with -Q? Then load the triples library and emacsql-sqlite library, then ekg, and try again.

In addition, let me know if this happens every time, or only in certain circumstances.

from ekg.

I tried with emacs -Q: loaded the packages triples, emacsql-sqlite and ekg, loaded the respective libraries, ran ekg-capture and ekg-capture-finalize.

Message appears: "obsolete timestamp with cdr 1". At the same time the capture-buffer disappears and is replaced by the scratch-buffer. In the messages-buffer there is only "obsolete timestamp with cdr 1".

Yes, it happens every time, so nothing has been captured yet.

from ekg.

Looks like this is coming from decode_lisp_time, perhaps there's something interesting with your systems that is handling time in some strange way. What kind of system is this on, what is the value of the system-configuration variable?

Can you also run in a scratch buffer (time-convert (current-time) 'integer) and let me know what you get?

from ekg.

Also, can you try after evaluating (setq debug-on-message "timestamp")? That should cause you to enter the debugger when the message is printed, and then please paste the backtrace here.

from ekg.

@ahyatt, when I stepped through ekg-capture-finalize, the error message did show up in the messages window, but it was after I exited the function, so I couldn't figure out what caused it.

Here's that other information:

system-configuration is a variable defined in ‘C source code’.

Its value is "x86_64-w64-mingw32"

Value is string indicating configuration Emacs was built for.

Probably introduced at or before Emacs version 19.23.

When I run (time-convert (current-time) 'integer), I get:

1677710555 (#o14377752333, #x63ffd4db)

Doing (setq debug-on-message "timestamp") produced something more diagnostic, I hope:

Debugger entered--Lisp error: "obsolete timestamp with cdr 1"
  time-subtract((25599 54578 904559 0) (1677447982 . 1))
  #f(compiled-function (last-update) "Backup strategy to create a change daily at most.\nLAST-UPDATE is the time of the last update." #<bytecode -0x17c81e3a386fc3b0>)((1677447982 . 1))
  triples-backups-maybe-backup(#<emacsql-sqlite-connection emacsql-sqlite-connection-58e1b02728> nil)
  ekg-save-note(#s(ekg-note :id 33017693769 :text #("sadflkjadslfjs" 0 14 (fontified t wrap-prefix "")) :mode org-mode :tags ("date/2023-03-01") :creation-time 1677710638 :modified-time 1677710642 :properties nil))
  ekg--save-note-in-buffer()
  ekg-capture-finalize()
  funcall-interactively(ekg-capture-finalize)
  command-execute(ekg-capture-finalize)

from ekg.

That fixed it. I don't see the timestamp error message anymore. Thanks!

from ekg.

Awesome, thank you for your help in debugging this! I'll commit the fix today and the triples library should be released as a new version in GNU ELPA tomorrow. Nothing needs to be done on the ekg side.

from ekg.

The "obsolete timestamp with cdr" warning was added to Emacs-27 to try and catch uses of an old (HI . LO) timestamp representation (which clashes with the new (TIME . HZ) representation). It clearly misfires here.
It was removed in Emacs-28.

from ekg.

Thank you for the explanation, @monnier!

from ekg.

Thank you so much, this fixed it for me too.

from ekg.