A Lazy Sequence Recent https://brehaut/feeds/everything 2018-09-25T04:48:14.041Z Andrew Brehaut andrew@brehaut.net A dark mode less mixin https://brehaut.net/blog/2018/a_dark_mode_less_mixin 2018-09-25T04:48:14.041Z <p> With the release of macOS Mojave and it’s dark mode color scheme, I wanted to get a dark mode set up for <em>A Lazy Sequence</em>. There is currently no support for this in browser CSS, but it has made it into the editors draft of the <a href="https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme">Media Queries Level 5</a> CSS spec under the <code>prefers-color-scheme</code> media query. </p> <p> I’ve written about the simplest pair of <a href="http://lesscss.org/">Less</a> mixins to abstract it away and build a stylesheet without concern for future changes. The only slightly tricky thing is it leverages the <a href="http://lesscss.org/features/#detached-rulesets-feature">detached rulesets</a> feature of less, but its a textbook example of one: </p> <pre><code class="brush: css;">.darkmode(@rules) { @media screen and (prefers-color-scheme: dark) { @rules(); } html.dark & { @rules(); } } .modeColor(@light, @dark) { color: @light; .darkmode({color: @dark}); } </code></pre> <p> The mixin includes an <code>html</code> class so that it’s easy to test the style without waiting for the future to arrive. I found I was overriding only <code>color</code> in 95% of the cases so I made a quick special case for that. </p> A generic function to forward events https://brehaut.net/blog/2018/a_generic_function_to_forward_events 2018-09-04T03:38:54.994Z <p>Here’s a neat function made possible with recent TypeScript releases (2.8 onward):</p> <pre><code class="brush: javascript;">interface IEventSink&lt;T&gt; { register(f: (v: T)=&gt;void): void; raise(v: T): void; } type ForwardableEventSinks&lt;TSrc, TDest&gt; = { [K in keyof (TSrc &amp; TDest)]: (TSrc &amp; TDest)[K] extends IEventSink&lt;infer V&gt; ? IEventSink&lt;V&gt; : never; } function forwardOne&lt;TSrc, TDest&gt;(src: ForwardableEventSinks&lt;TSrc, TDest&gt;, dest: ForwardableEventSinks&lt;TSrc, TDest&gt;, eventName: keyof ForwardableEventSinks&lt;TSrc, TDest&gt; ): void { src[eventName].register(v =&gt; dest[eventName].raise(v)); } </code></pre> <p><code>forwardOne</code><sup>1</sup> takes two objects of different types that expose the same event sink (same name, same type argument), and makes connects the source to the destination. This is really handy when building components by composition.</p> <p>The trick here is in the utility type <code>ForwardableEventSinks</code>. This combines three features of the type system – <a href="https://www.typescriptlang.org/docs/handbook/advanced-types.html#mapped-types">mapped types</a>, <a href="https://www.typescriptlang.org/docs/handbook/advanced-types.html#intersection-types">intersection types</a>, and <a href="https://www.typescriptlang.org/docs/handbook/advanced-types.html#conditional-types">conditional types</a> – to find the common subtype of the <code>TSrc</code> and <code>TDest</code> that contains only the exposed event sinks where they match.</p> <p>The only thing here that’s a little non-obvious is the specific way the intersection is described: <code>[K in keyof (TSrc &amp; TDest)]: (TSrc &amp; TDest)[K] …</code> Note here that on both sides of the mapping the type in question is the same intersection. While we know that any value in <code>keyof (TSrc &amp; TDest)</code> is going to be in both <code>keyof TSrc</code> and <code>keyof TDest</code> (that’s basically the definition of intersection after all), the type checker wants to be a bit fussier there and I was finding it would raise an error if eg I tried to do <code>TSrc[K]</code>. Maybe this is a bug? I’m not smart enough to figure it out. </p> <p>Conveniently this particularly formulation of the type proved to not only be correct, and checkable, but also the tidiest version of the idea I could express.</p> <ol class="footnotes"> <li>This is trivial to then extend to a second version – say <code>forwardAll</code> – that takes an array of event names.</li> </ol> Making a Boss FS-6 substitute https://brehaut.net/blog/2018/boss_fs_6_clone 2018-08-18T09:09:28.258Z <figure> <img src="https://brehaut.net/media/files/images/fs6-clone.jpg" /> <figcaption>The finished footswitch and TRS cable.</figcaption> </figure> <p> One of today’s jobs – along side child-proofing some shelving – was to assemble a remote foot-switch for my <a href="https://www.boss.info/us/products/rc-1/">Boss RC-1</a> loop recorder pedal that I use for practice. The RC-1 is a useful tool, but I do find the overloaded foot-switch commands to start, stop, undo, etc, confusing and hard to remember which can be an impediment during practice. </p> <p> The pedal has an input for a remote foot-switch that simplifies the operation dramatically, and Boss want you to shell out a good chunk of change for their official foot switch. The official foot-switch has a couple of extra features (switching from momentary to latching, and indicator LEDs) that might be useful with other pedals, but are unnecessary for the RC-1. The actual requirements are very simple: it’s really just two momentary switches connected to a <abbr title="Tip, Ring, Sleeve; a stereo 1/4 inch socket">TRS</abbr> socket. I followed a <a href="https://www.instructables.com/id/Boss-FS-6-Clone-Build-your-own/">plan on Instructables</a>. </p> <p> I deviated from the Instructables plans in a couple of places: I couldn’t find the exact parts in a couple of places so had to select near equivalents, I installed the hardware into the enclosure before I started soldering (there’s a lot of room in the enclosure so it is easy to do), and (because the hardware was already installed) I used significantly shorter lengths of wire to connect all the parts. The barrel on the jack socket I bought was a little deeper than the case, so a random O-ring from the workbench supplies was needed as a spacer. </p> <p> I ordered the parts from <a href="https://www.mammothelectronics.com/">Mammoth</a> in the US as I couldn’t find the momentary switches locally<sup>1</sup>. I’m sure they are available, but my google-fu was insufficient. Mammoth also do the nicely powder coated enclosures too so that was a bonus, and somewhat offset the international shipping. Oddly the two switches came with a different complement of washers; no idea what that is about. </p> <ol class="footnotes"> <li>If anyone knows of a good suppler in New Zealand I would love to hear about it. Since I ordered the parts I did discover an Australian parts supplier, <a href="http://www.pedalpartsaustralia.com/">Pedal Parts Australia</a>, who may be useful for future projects.</li> </ol> Choosing properties for property-based testing https://brehaut.net/blog/2018/choosing_properties_for_property_based_testing 2018-07-23T04:06:54.101Z <blockquote> <p>…Everyone who sees a property-based testing tool like FsCheck or QuickCheck thinks that it is amazing… but when it times come to start creating your own properties, the universal complaint is: “what properties should I use? I can’t think of any!”</p> <p> The goal of this post is to show some common patterns that can help you discover the properties that are applicable to your code. </p> <footer> — Scott Wlaschin, <a href="https://fsharpforfunandprofit.com/posts/property-based-testing-2"><em>Choosing properties for property-based testing</em></a>. </footer> </blockquote> <p> I’ve been referring to this article a lot recently while coming up with properties. It is an invaluable resource. </p> Fall of Delta Green Lethality rules https://brehaut.net/blog/2018/fall_of_dg_lethality 2018-07-07T22:59:59.149Z <p> The rules for the <code>H</code> modifier for hurt lethality on page 93 of <em>The Fall of Delta Green</em> completely flummoxed me. If that&#39;s you too, ignore the text there: the example is correct, and a clearer presentation of the rules can be found in the appendix on page 352 in the procedural resolution of lethality. </p>