Until a few months ago I didn’t use Emacs themes. A
custom-set-faces form in my init file gradually accumulated face specs like a lint-roller.
Then I started to use Solarized. Mostly light, sometimes dark. Switching between them using
M-x load-theme worked fine.
Later I liked the look of Material. Although too high-contrast to use full-time, it works well in certain situations.
After I installed it I had two annoyances:
I didn’t love the 3D “button” look it gives org-mode headings. Must tweak.
Switching between the Solarized and Material themes using
load-theme definitely did not work well: If the old theme defined a face, but the new theme did not, the old face would remain in effect. So for example I might switch to Material then back to Solarized, and get a weird mix of mostly Solarized but with Material org headings.
Here’s what I’m doing to address both issues.
If you’ve heard of Racket “at-expressions”, maybe you think they’re “that funny Scribble notation in which you write Racket documentation.”
In fact at-expressions are a general, alternative way to write s-expressions. They can be used in various handy ways.
Let’s look at using at-expressions for a few practical things like:
- “string interpolation”
- regular expressions
- “here” strings
This revises my Keyword structs post to fix some mistakes, discuss the
match pattern, and rewrite the macro to use
syntax-parse and support default arguments.
A good rule of thumb in Racket is to use a
struct instead of
list when you’re juggling more than two or three items.
It’s been a few weeks since I’ve blogged. Bad me. This is a catch-up post.
Hacker School has a tool called Blaggregator created by Sasha Laundy. We can submit feeds for our blogs. Blaggregator provides an aggregate page, and puts new-post messages on Zulip, the chat tool.
My first-ever open source contribution, a couple years ago, was to a project called Pygments. My motivation? GitHub was displaying Racket source code poorly. Pygments didn’t have a Racket lexer. GitHub was using a Scheme lexer for Racket code. The Scheme lexer was highlighting square brackets in red as an “error”. This was really distracting and ugly.
I contributed a new Racket lexer to Pygments, and waited for that to roll into a Pygments release and in turn be deployed on GitHub. Finally Racket code looked good! Later Dave Corbett substantially improved the Racket lexer beyond my small start.
A few days ago, I was confused to see that Racket code was displaying poorly again on GitHub. The square brackets were highlighted in red as errors — again??
Cartoon-me’s thought balloons: WAT, OMFG, FML, &c. Why are we going in circles?
I’m at the end of week 6 at Hacker School, which marks the halfway point. There are overlapping 12-week batches. As a result, the previous batch never-graduated yesterday.
My early weeks here included some pairing, and it was fun, but I spent more time learning and coding solo. My previous week was nearly the opposite. I spent most of my time pairing with Sumana Harihareswara.
If you’re coming to Racket from another REPL language (such as another Lisp), this post might be real Captain Obvious material.
But if you’re coming to Racket from an edit/compile/debug language like C or C++, it might be unclear what a typical workflow is. You might have questions like:
- How do I compile?
- How do I debug?
Last week I decided to pivot from Clojure hands-on to Haskell hands-on.
Here are my notes about being puzzled about some Clojure code and diving into the implementation to figure it out. Although I figured it out the hard way, the exploration turned out to be interesting for me.
I spent most of late Thursday and Friday working on open source projects that pre-date Hacker School.