From 9c1f7193530ff4cbf63d532b80045b0c473b3ed8 Mon Sep 17 00:00:00 2001 From: iximeow Date: Sun, 23 Jun 2024 17:27:15 -0700 Subject: describe more in changelog, adjust order for legibility --- CHANGELOG | 55 ++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/CHANGELOG b/CHANGELOG index 3178110..737c207 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -24,42 +24,55 @@ added `yaxpeax_arch::display::DisplaySink` after revisiting output colorization. style text in some unfortunate circumstances, such as when the console that needs to be styled is only written to after intermediate buffering. -`DisplaySink` also includes specializable functions for writing text to an + `DisplaySink` also includes specializable functions for writing text to an output, and the implementation for `alloc::string::String` takes advantage of this: writing through `impl DisplaySink for String` will often be substantially more performant than writing through `fmt::Write`. +added `mod color_new`: + this includes an alternate vision for `YaxColors` and better fits with the + new `DisplaySink` machinery; ANSI-style text markup can be done through the + new `yaxpeax_arch::color_new::ansi::AnsiDisplaySink`. + + this provides more flexibility than i'd initially expected! yours truly will + be using this to render instructions with HTML spans (rather than ANSI + sequences) to colorize dis.yaxpeax.net. + + in the future, `mod colored` will be removed, `mod color_new` will be renamed + to `mod color`. + +deprecated `mod colored`: + generally, colorization of text is a presentation issue; `trait Colorize` + mixed formatting of data to text with how that text is presented, but that is + at odds with the same text being presented in different ways for which + colorization is not generic. for example, rendering an instruction as marked + up HTML involves coloring in an entirely different way than rendering an + instruction with ANSI sequences for a VT100-like terminal. + added `yaxpeax_arch::safer_unchecked` to aid in testing use of unchecked methods these were originally added to improve yaxpeax-x86 testing: https://github.com/iximeow/yaxpeax-x86/pull/17, but are being pulled into yaxpeax-arch as they're generally applicable and overall wonderful tools. thank you again 522! +added `mod testkit`: + this module contains tools to validate the correctness of crates implementing + `yaxpeax-arch` traits. these initial tools are focused on validating the + correctness of functions that write to `DisplaySink`, especially that span + management is correct. + + `yaxpeax-x86`, for example, will imminently have fuzz targets to use these + types for its own validation. + made VecSink's `records` private. instead of extracting records from the struct by accessing this field directly, call `VecSink::into_inner()`. made VecSink is now available through the `alloc` feature flag as well as `std`. -significantly reduced `mod colored`: - generally, colorization of text is a presentation issue; `trait Colorize` - mixed formatting of data to text with how that text is presented, but that is - at odds with the same text being presented in different ways for which - colorization is not generic. for example, rendering an instruction as marked - up HTML involves coloring in an entirely different way than rendering an - instruction with ANSI sequences for a VT100-like terminal. - - the changes to `mod colored` reflect this, and rely on impls of `DisplaySink` - to know what they are displaying into and what is the correct mechanism to - present styled text. - - with this in mind: - * the module `yaxpeax_arch::color` now only exists with the `colors` feature - * removed `color::Colorize`, `color::Colored` - * `enum Colored` is closest in spirit to `enum Color` - * `trait YaxColors` no longer takes displayable types in its functions, no longer returns displayable types. - * `trait YaxColors`' sole function is as an inlining-friendly settings - mechanism for `DisplaySink` impls that care about coloring output - * dropped dependency on `crossterm` +meta: the major omission in this release is an architecture-agnostic way to +format an instruction into a `DisplaySink`. i haven't been able to figure out +quite the right shape for that! it is fully expected in the future, and will +probably end up somehow referenced through `yaxpeax_arch::Arch`. ## 0.2.8 -- cgit v1.1