[pull] master from GaijinEntertainment:master#1000
Merged
Conversation
…very Three small follow-ups to the Atom-feed surfacing PR: - site/blog/build_blog.py (render_index): move the visible RSS link to its own line below the intro and style it to match the BLOG section label — mono, uppercase, amber (var(--amber)). Inline styles only, no CSS changes. - site/blog/build_blog.py (render_atom_feed): add <author><name>Boris Batkin</name></author> to the feed root. RFC 4287 recommends it; W3C feed validator warns without it; major readers display "no author" otherwise. - site/index.html, site/downloads.html: add the same <link rel="alternate" type="application/atom+xml"> auto-discovery tag the template-generated pages already carry, so a reader pointed at https://daslang.io/ or /downloads.html also finds blog/feed.xml. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
libhv defaults to its `file_logger` which writes to `bin/libhv.YYYYMMDD.log`.
That file is invisible under `popen`/CI runners — when something inside the
HTTP server hangs or fails to bind, there's no way to see what libhv is
trying to do.
This commit reads `DASLIVE_HV_LOG` at `Module_HV` construction and routes
libhv accordingly:
DASLIVE_HV_LOG=stderr (or =1) -> hlog_set_handler(stderr_logger)
DASLIVE_HV_LOG=stdout -> hlog_set_handler(stdout_logger)
DASLIVE_HV_LOG=silent -> hlog_disable()
`DASLIVE_HV_LOG_LEVEL=DEBUG/INFO/WARN/ERROR` separately overrides the level
(default INFO).
Default unset preserves the existing file-logger behavior — no change for
non-CI users.
Smoke (Windows, `--headless`):
set DASLIVE_HV_LOG=stderr
set DASLIVE_HV_LOG_LEVEL=DEBUG
daslang-live foo.das -- --headless
-> stderr: "INFO http server listening on 0.0.0.0:9090 [HttpServer.cpp:184:http_server_run]"
"DEBUG hloop_new tid=4572 [hloop.c:431:hloop_new]"
"INFO EventLoop started, pid=99632 tid=4572 [HttpServer.cpp:151:loop_thread]"
"DEBUG hloop_run tid=4572 [hloop.c:454:hloop_run]"
Motivation: dasImgui CI hangs on both Linux and macOS in dasHV's HTTP
serving (script's update loop iterates, but /status never responds). Need
visibility into libhv's event loop state to diagnose — file_logger is
unreachable from the popen'd subprocess on the runner.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…yling site/blog: RSS link polish, feed author, landing auto-discovery
…oute-env dasHV: env-gated libhv log routing (stderr / stdout / silent)
Until this commit, ref_time_ticks() returned raw QueryPerformanceCounter
ticks on Windows (~10 MHz) and clock_gettime nanoseconds on Linux/macOS.
Any caller that did raw arithmetic on the result -- the natural
let deadline = ref_time_ticks() + int64(timeout_sec * 1_000_000)
while (ref_time_ticks() < deadline) { ... }
deadline pattern -- silently got 30 s on Windows (lucky math at 10 MHz)
and 30 ms on POSIX (1000x too short). Recently surfaced as a CI hang in
dasImgui's playwright harness, which read deadlines that elapsed instantly
on Linux/macOS runners.
Normalize ref_time_ticks() to nanoseconds on Windows by dividing the QPC
counter by the cached QueryPerformanceFrequency. The conversion uses a
split whole+remainder fold so the intermediate never overflows int64.
QPF is cached once per process (invariant after boot, race-tolerant).
Helpers (get_time_usec, get_time_nsec, ref_time_delta_to_usec) become
trivial subtraction/division now that the unit is uniform; the Windows
ref_time_delta_to_usec also loses a long-standing QPC-for-QPF typo that
made it return garbage in the old implementation. The POSIX helpers are
unchanged in semantics, just tidied for symmetry.
All in-tree callers (C++ and .das, including dastest, daslib/profiler,
strudel, examples, MCP tools) already use the safe `let t0 = ref_time_ticks()`
+ `get_time_usec(t0)` pattern, so no caller changes are needed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous commit's split conversion (whole+rem with two idiv per call) doubled the cost of ref_time_ticks() from ~22 ns to ~40 ns on modern Windows. That matters for the function profiler, which brackets every profiled call: ~36 ns of profiler skew per function vs ~14 ns before. Precompute `qpc_ns_per_tick = 1e9 / freq` once when QPF divides 1e9 cleanly. On every Win 7+ box that's the case (QPF is fixed at 10 MHz, ns_per_tick = 100), so the hot path collapses to one multiply and the call returns to ~23 ns -- within 1 ns of the bare QueryPerformanceCounter cost. The split fallback stays for paranoid completeness on non-divisible QPF (theoretical; not observed on shipping Windows hardware in years). Microbench on this box (QPF=10MHz, MSVC /O2, 50M iterations): ref_old (raw QPC, returns ticks) 22.3 ns/call 1.00x ref_new_split (whole+rem -> ns, previous) 39.8 ns/call 1.79x ref_new_fast (ticks * ns_per_tick) 23.0 ns/call 1.03x Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Update the handmade RST blurb for builtin::ref_time_ticks to reflect the new contract: monotonic timestamp in nanoseconds, raw subtraction valid since the unit is uniform across Windows/Linux/macOS. The previous wording described the return value as opaque "ticks", which was platform-dependent and led to caller-side deadline-math bugs (the dasImgui CI hang). Sphinx clean build succeeded, zero new warnings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…cks-normalize-ns ref_time_ticks: normalize to nanoseconds on every platform
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )