You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal of debug_logger is to serialize the state of the widget tree in real time, to a stream that can be read by an external debugging application which can inspect the stream and display what the widget tree looked like at a given time, and inspect internal values and stuff.
While said debugging application has proven extremely invaluable for me for debugging masonry, I don't expect anybody else to use it, as its UX right now is absolutely abysmal. I do intend to improve it eventually.
In the meantime, debug_logger is a pretty clunky, unwieldy tools. Among other problems:
It requires trace calls in a bespoke format to be added everywhere in the code.
It feels superfluous with tracing already in the codebase.
Its performance for non-trivial cases is terrible.
Now, I think debug_logger is an idea that has some real potential. In my ideal vision, it would be a record-replay framework of sorts, one that would produce a lightweight record of the widget tree and application state over time. It would probably use the tracing crate as the serialization layer, and it would do some fancy caching to only record changed information to avoid unnecessary overhead.
I need to write a full design document for that ideal logger, and then get started on implementing it.
The text was updated successfully, but these errors were encountered:
The goal of debug_logger is to serialize the state of the widget tree in real time, to a stream that can be read by an external debugging application which can inspect the stream and display what the widget tree looked like at a given time, and inspect internal values and stuff.
While said debugging application has proven extremely invaluable for me for debugging masonry, I don't expect anybody else to use it, as its UX right now is absolutely abysmal. I do intend to improve it eventually.
In the meantime, debug_logger is a pretty clunky, unwieldy tools. Among other problems:
Now, I think debug_logger is an idea that has some real potential. In my ideal vision, it would be a record-replay framework of sorts, one that would produce a lightweight record of the widget tree and application state over time. It would probably use the tracing crate as the serialization layer, and it would do some fancy caching to only record changed information to avoid unnecessary overhead.
I need to write a full design document for that ideal logger, and then get started on implementing it.
The text was updated successfully, but these errors were encountered: