Tracked under #6.
Scope
Provide a Rust-side hook to redirect whisper.cpp's diagnostic output (currently eprintln!-shaped) into log / tracing or a custom sink.
Symbols
whisper_set_log_callback, whisper_log_callback.
set_debug_mode (per-context flag, separate but related).
Why deferred
whisper_set_log_callback is a global hook — registers across all instances in the process. Mixing it with Rust logging frameworks (log, tracing) needs more design than a 1:1 port:
- Process-wide registration is hostile to libraries that want to ship an
Arc<dyn Subscriber>-style integration.
- The C callback runs on whichever thread emitted the log; the Rust side has to be Sync.
- Initialising the hook before any whisper.cpp call requires either an
OnceCell or a constructor hook, both of which introduce ordering concerns.
Whispery routes its own diagnostics through eprintln! / tracing already, so it doesn't need this.
Acceptance
Open design questions to resolve before implementation:
- Process-wide singleton (
whispercpp::set_log_handler(impl Fn(...))) vs per-Context hook? Upstream is process-wide.
- Auto-bridge to
log crate (a whispercpp = { version = "...", features = ["log"] } feature gate)?
- Auto-bridge to
tracing (separate feature)?
- Behaviour for callers who never set a handler —
eprintln! (current upstream default) or silent?
Probably wants an RFC-style design issue / PR before implementation.
If you have a logging integration story you'd want to support, drop a comment.
Tracked under #6.
Scope
Provide a Rust-side hook to redirect whisper.cpp's diagnostic output (currently
eprintln!-shaped) intolog/tracingor a custom sink.Symbols
whisper_set_log_callback,whisper_log_callback.set_debug_mode(per-context flag, separate but related).Why deferred
whisper_set_log_callbackis a global hook — registers across all instances in the process. Mixing it with Rust logging frameworks (log,tracing) needs more design than a 1:1 port:Arc<dyn Subscriber>-style integration.OnceCellor a constructor hook, both of which introduce ordering concerns.Whispery routes its own diagnostics through
eprintln!/tracingalready, so it doesn't need this.Acceptance
Open design questions to resolve before implementation:
whispercpp::set_log_handler(impl Fn(...))) vs per-Context hook? Upstream is process-wide.logcrate (awhispercpp = { version = "...", features = ["log"] }feature gate)?tracing(separate feature)?eprintln!(current upstream default) or silent?Probably wants an RFC-style design issue / PR before implementation.
If you have a logging integration story you'd want to support, drop a comment.