Ask HN: What problem are you close to solving and how can we help?
Short version: I&#x27;m close to figuring out how to encourage more prototyping of software by making tests super easy to write during the prototyping process, and so de-risking rewrites. But one problem I&#x27;ve been stymied by is how to represent expectations of screens when they contain graphics.<p>Long version: My Mu project (<a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu</a>) is building a computing stack up from machine code. The goal is partly to figure out why people don&#x27;t do real prototyping more often. We all know we should throw the first one away (<a href="https:&#x2F;&#x2F;wiki.c2.com&#x2F;?PlanToThrowOneAway" rel="nofollow">https:&#x2F;&#x2F;wiki.c2.com&#x2F;?PlanToThrowOneAway</a>), but we rarely do so. The hypothesis is that we&#x27;d be better about throwing the first one away if rewriting was less risky. By the time the prototyping phase ends, a prototype often tacitly encodes lots of information that is risky to rewrite.<p>To falsify this hypothesis, I want to make it super easy to turn any manual run into a reproducible automated test. If all the tacit knowledge had tests (stuff you naturally did as you built features), rewriting would become a non-risky activity, even if it still requires some effort.Turning manual tests into automated ones requires carefully tracking dependencies and outlawing side-effects. For example, in Mu functions that modify the screen always take a screen object. That way I can start out with a manual test on the real screen, and easily swap in a fake screen to automate the test. Hence my problem:<p><i>How do you represent screens in a test?</i><p>Currently I represent screens as 2D arrays of characters. That is doable a lot of the time, but complicates many scenarios:<p>* Text mode character attributes. If I want to check the foreground or background color, I currently use primitives like `check-screen-in-bg` which ignores spaces in a 2D array, but checks that non-spaces match the given background attribute. In practice this leads frequently to tests that first check the character content on a screen and then perform more passes to check colors and other attributes.<p>* Non-text. Checking pixels scales poorly, either line at a time or pixel at a time. A good test should seem self-evident based on the name, but drawing ASCII art where each character is a pixel results in really long lines or stanzas. So far I maintain separate buffers for text vs pixels, so that at least text continues to test easily.<p>* Proportional fonts. Treating the screen as a grid of characters works only when each character is the same width. If widths differ I end up having to go back to treating characters as collections of pixels. So Mu currently doesn&#x27;t support arbitrary proportional fonts.<p>* Unicode. Mu currently uses a single font, GNU Unifont (<a href="http:&#x2F;&#x2F;unifoundry.com&#x2F;unifont&#x2F;index.html" rel="nofollow">http:&#x2F;&#x2F;unifoundry.com&#x2F;unifont&#x2F;index.html</a>). Unifont is mostly fixed-width, but lots of graphemes (e.g. Chinese, Japanese, Korean, Indian) require double-width to render. That takes us back to the problems of proportional fonts. Currently I permit just variable width in multiples of some underlying grid resolution, but it feels hacky.<p>Can people think of solutions to any of these bullets in a text-based language? Or a more powerful non-text representation?