matoro

> Wow, I think your runner is literally too fast for doctest! > > Could you check if #712 fixes it? No, that does not do the trick unfortunately. However...

> Does the current version do the trick for you? I've moved to `std::chrono` but am not currently using `sleep_for` as that is causing issues with older versions of clang...

That seems to have gotten rid of the timeout issue, but introduced three new failures (at least I think they are new). Luckily these failures are deterministic at least. ```...

> Seems like it just exits unexpectedly at some point, assuming it just throws an exception, are you able to attach a debugger to figure out what's going on here?...

Hi @Saalvage , were you able to try logging into the account I provisioned above? This machine is still available so that you can check out the issue firsthand.

Turns out this also affects HPPA (PA-RISC), at least the machine I just got. I am wondering if this is simply something that shows up on very slow hardware in...

After digging into this for quite a while I finally understand what is going on. My very first suspicion was correct - clock resolution is the problem. I used this...

Simply adding a sleep to the test that is expected to time out is sufficient to solve the timeout issues, no need for the test of https://github.com/doctest/doctest/pull/712. This is sufficient...

Observed this `test_capture_pane_start` failure on Gentoo also. ``` ================================================================= FAILURES ================================================================== __________________________________________________________ test_capture_pane_start __________________________________________________________ session = Session($1 libtmux_9bmi4d2z) def test_capture_pane_start(session: Session) -> None: """Assert Pane.capture_pane() with ``start`` param.""" env =...

> I suppose the question to ask is does this problem occur when you use standard frames rather than jumbo frames, i.e. using an MTU of 1500? I have no...