Re: parallel test failures
David Bremner writes: > Tomi Ollila writes: > >> >> Anyway, the log.gz did not show any tests failing but parallel exiting >> nonzero possibly for some other reason. Cannot say. Probably stracing (even >> with --seccomp-bpf) would make it happen even less likely :/ >> > > Thanks to both of you for your feedback / suggestions. I did read today > that timeout exits with 124 when the time limit is reached. I haven't > investigated further (nor do I know how the timelimit should be reached, > since the whold build+test cycle takes about 10s on this machine. Maybe a timeout is not so crazy. I ran a couple of trials with NOTMUCH_TEST_TIMEOUT=0, and it eventually hung (after 6, and 110 repetitions) in T355-smime, as far as I can tell on the first test. I'm currently running some trials to see if I can duplicate that without parallel execution, but that of course takes longer. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: notmuch-tree: mark the initial message at point as read
Hm, when no tree buffer is involved, then `notmuch-show-command-hook' probably is required. Anyway, there seems to be some undead code and rethinking all this would be a good idea. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: notmuch-tree: mark the initial message at point as read
> I try to understand whether adding notmuch-tree-command-hook to
> post-command-hook in notmuch-tree.el (not in this change) actually
> have any effect.
You're right, that's unnecessary, and it gets worse.
`notmuch-tree-command-hook' is unnecessary too and if it weren't,
then it would fail because its added to the buffer-local value of
`post-command-hook', but that buffer is not the current buffer
when the hook is run.
Using `post-command-hook' in any form for this is questionable in the
first place. The idiomatic approach would be to use the `point-entered'
text property hook. Or `notmuch-tree-{previous,next}-message' could
just do the marking explicitly.
It's also not okay that `notmuch-tree-show-message-in' keeps recreating
the window.
`notmuch-show-command-hook' forces redisplay to update values that pass
along, but don't and shouldn't use. There is more than one function to
mark a message as read and they don't all end up doing the same thing.
What effectively does the marking is
(defun notmuch-tree-show-message-in ()
...
(when notmuch-show-mark-read-tags
(notmuch-tree-tag-update-display notmuch-show-mark-read-tags))
...)
I am going to refactor this mess, but that will take a while.
Jonas
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: parallel test failures
Tomi Ollila writes: > > Anyway, the log.gz did not show any tests failing but parallel exiting > nonzero possibly for some other reason. Cannot say. Probably stracing (even > with --seccomp-bpf) would make it happen even less likely :/ > Thanks to both of you for your feedback / suggestions. I did read today that timeout exits with 124 when the time limit is reached. I haven't investigated further (nor do I know how the timelimit should be reached, since the whold build+test cycle takes about 10s on this machine. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
