[jmw182]

Port the pyrtma client logger to the c++ rtma library, deprecating the external cc_logger library. Written with github copilot (GPT-5.6-terra).

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[jmw182]

I'm burning through copilot tokens on this first day of the month, but I'm considering building this on top of spdlog.

Response from copilot:

Yes, spdlog would improve several weak spots in the current implementation:

• Reliable rotating-file sinks, including size limits and backup handling.
• Better console formatting and platform-safe output.
• Thread-safe sinks and optional asynchronous logging.
• It already uses fmt, so it complements the dependency already added.

You would still need an RTMA-specific sink that converts spdlog::details::log_msg into MDF_RTMA_LOG and sends it through the owning RTMA_Module. You would also need a small wrapper to retain the PyRTMA-compatible API and behavior: enable_rtma, per-sink levels, dynamic client-name updates, child names, and disabling RTMA output after send failures.

So it is not substantially more complicated overall. The initial integration is more work, but it replaces hand-rolled file rotation and console code in RTMA_Logger.cpp, which are the parts most likely to accumulate platform and concurrency bugs.

I would prefer spdlog if this logger is intended to become a supported RTMA API. Keep the wrapper thin:

RTMA_Logger
  -> spdlog::logger
      -> stdout_color_sink_mt
      -> rotating_file_sink_mt
      -> rtma_sink_mt  // custom sink

The custom rtma_sink_mt should:

1. Map level to MT_RTMA_LOG*.
2. Populate the fixed MDF_RTMA_LOG layout and truncation rule.
3. Skip sends when disconnected.
4. Disable itself on send failure to prevent logging recursion.

The main tradeoff is dependency weight and exported ABI complexity. Since fmt is already a public dependency, adding spdlog is a reasonable next step, preferably pinned and fetched through CMake just as fmt is.

[jmw182]

I'm not sure if integrating spdlog is worth the cost of time and/or tokens at the moment, but this branch needs some work to at least be on par with cc_logger. I had put some effort into the cc_logger formatting (approximating that of the python rich logger), but copilot does not appear to have copied much or any of that over (e.g. no use of color).

I updated quicklogger to use the logger, which would eliminate the need for the DEBUG_TEXT message.

[jmw182]

I did some more iteration with copilot to bring this up to feature parity with cc_logger and fix some issues it found. Some fixes are likely overkill but could avoid future problems (e.g. loggers in multiple threads).