<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Parsing on MacWorks</title><link>https://macworks.dev/tags/parsing/</link><description>Recent content in Parsing on MacWorks</description><generator>Hugo</generator><language>en</language><atom:link href="https://macworks.dev/tags/parsing/index.xml" rel="self" type="application/rss+xml"/><item><title>Engineer Reads</title><link>https://macworks.dev/docs/week/blogs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/blogs/</guid><description>&lt;h1 id="engineering-reads--week-of-2026-06-17-to-2026-06-25"&gt;Engineering Reads — Week of 2026-06-17 to 2026-06-25&lt;a class="anchor" href="#engineering-reads--week-of-2026-06-17-to-2026-06-25"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="week-in-review"&gt;Week in Review&lt;a class="anchor" href="#week-in-review"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The dominant theme across this week&amp;rsquo;s reading is the persistent friction between idealized abstractions and messy, underlying hardware or operational realities. From the hidden environmental state that breaks reproducible C++ builds to the way mean latency metrics discard the user&amp;rsquo;s actual lived experience, the literature is heavily focused on the dangers of lossy compression in systems design. We are increasingly aware that whenever we try to flatten a complex domain—whether it&amp;rsquo;s AI capabilities, memory management, or performance monitoring—the suppressed complexity inevitably leaks back into the application layer.&lt;/p&gt;</description></item><item><title>2026-06-21</title><link>https://macworks.dev/docs/week/blogs/engineer-blogs-2026-06-21/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/blogs/engineer-blogs-2026-06-21/</guid><description>&lt;h1 id="engineering-reads--2026-06-21"&gt;Engineering Reads — 2026-06-21&lt;a class="anchor" href="#engineering-reads--2026-06-21"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="the-big-idea"&gt;The Big Idea&lt;a class="anchor" href="#the-big-idea"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Managing complexity in production requires isolating risky or unpredictable components from the core system—whether that means deploying strict sandboxes for cybersecurity evaluations, or quarantining a complex legacy-format parser behind an opt-in feature flag.&lt;/p&gt;
&lt;h2 id="deep-reads"&gt;Deep Reads&lt;a class="anchor" href="#deep-reads"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Apex and Grid Tables&lt;/strong&gt; · Brett Terpstra · &lt;a href="https://brett.trpstra.net/link/535/17364843/apex-and-grid-tables"&gt;Source&lt;/a&gt;
Apex 1.1.0 introduces opt-in support for Pandoc-style grid tables, allowing developers to natively process complex ASCII-art tables featuring multiline cells, colspans, and rowspans. Under the hood, Apex preprocesses these grid blocks into standard pipe or HTML tables before the rest of the parsing pipeline runs, ensuring nested blocks like lists render correctly as HTML rather than line-broken text. The author wisely ships this feature disabled by default, acknowledging that grid parsing introduces massive surface area for edge-case collisions with standard Markdown. It is a pragmatic lesson in backward compatibility: ship new capabilities, but isolate their blast radius until field testing validates the parser against legacy workflows. Engineers dealing with complex text pipelines or legacy format migrations should read this for a practical example of cautious, defensive feature rollout.&lt;/p&gt;</description></item></channel></rss>