This caused a pretty bad and subtle bug in the asynchttpserver.
As far as I can understand, the fact that the returned future was
being completed first meant that the underlying async procedure
could continue running and thus clean() the FutureVar
and request new data. The control then went back and the
FutureVar was completed again causing an error.
Add yearday calculation to getLocalTime and getGMTime, so that yearday is not 0 for TimeInfo instances under JS backend.
Yearday 0 has no sense and contradicts the behaviour under C backend, where yearday is an int from 1 to 365, i.e. cannot be 0 even theoretically.
Implement ConsoleOutputFormatter that is backward compatible
with the previous implementation.
Implement JUnitOutputFormatter which can be added externally.
* Fix kqueue.nim and ansi_c.nim to support dragonfly.
* Fix ioselectors.nim, threads.nim to support dragonfly.
* Fix deprecated dealloc call in tioselectors.nim.
* Fix tfsmonitor.nim test to run only on Linux.
* Fix osproc.nim return wrong exit codes.
* Fix getAppFilename() for dragonfly.
* Fix proper exit code handling.
* Fix 2 problems. First, 0 is a valid fd on Unix (easily gotten if user first
closes all fds and then starts using memfiles). Use -1 instead for an invalid
fd. Second, it is best practice to conserve open fds on Unix and file handles
on Windows. These handles are not needed unless the user wants to remap the
memory with ``mapMem`` (or a hypothetical future ``proc resize``). Adding a
new bool param ``allowRemap=false`` to ``memfiles.open`` solves this cleanly
in a "mostly" backward compatible way. This is only "mostly" because the
default ``false`` case does not keep unneeded resources allocated, but that
most sensible default means that any ``mapMem`` callers need to fix all their
open calls to have allowRemap=true, as this PR also does for tmemfiles2.nim.
* Include backwards compatibility note.
