Ironically, after posting about “Blogging Friction”, I took a break from blogging at all for awhile. When it came time that there was something I wanted to post about again, things didn’t work. Yet again, things had changed on GitHub and GitHub Pages. First GitHub stopped allowing access via passwords. You had to move to SSH access. Then, for GitHub Pages, you had to add “Deploy Tokens”, another kind of SSH token.
Recently, I needed to write a simple simulation in multiple programming languages. For the simulations to operate, they needed a source of random numbers from two statistical distributions: a uniform distribution and a standard distribution. The numbers from the distributions needed to be “random”, but not too random. I needed each generator in each language to produce the same sequence of “pseudo-random” numbers. And I needed the same sequence every time the simulators were run.
Let’s face it. I’m an infrequent blogger. But I’m not an infrequent writer. So why does the (vast) majority of what I write never make it onto the blog? The answer is friction. And why is that? Here is my process. Think of something that I want to write down so I remember it. Realize that what I’ve written might be useful to someone else too. (It could happen!) Look at what I have to do in order to get my thoughts from my editor to the blog.
A little word game that I’ve been writing requires a list of acceptable words. For the game, acceptable words should be defined similarly to popular word games the player already knows like Scrabble® or Words with Friends. Luckily word lists for such games are readily available. For my little game, the list from Words with Friends seemed like the best choice. But it has about 175,000 English words. Way to many to use routinely in development.
Recently I’ve written about doing some fairly low-level operations in Scheme, specifically how to get the window size of a terminal where the program is running. This was part of a little project to write a simple terminal-based text editor in Scheme along the lines of the kilo editor by following a tutorial entitled “Build Your Own Text Editor”. Another part of that project that was surprisingly difficult to accomplish in Scheme was putting the terminal in “raw” mode.
Doing some experimenting with the Scheme programming language recently has been a lot of fun. It’s even simpler in most ways than Clojure. As part of that experimentation, I’ve been looking into implementing a simple, terminal-based text editor along the lines of kilo by following along with the tutorial series “Build Your Own Text Editor”. Working through those tutorials, one of the first things that smacks you in the face is just how low-level the C programming language is and how very different it feels when compared to Scheme or, really, any other Lisp variant.
As part of repository maintenance, I often use a script to delete a group of directories, even if those directories are not empty. It looks something like this: (require '[clojure.java.io :as io]) . . . (defn delete-children-recursively! [f] "Given a file, delete it. If the file is a directory delete its contents first. This version does not handle symlinks." (when (.isDirectory f) (doseq [f2 (.listFiles f)] (delete-children-recursively!
I wanted to add an estimate of words and characters in wiki pages for a program I am writing CWiki There was some guidance on this topic (in Python) here. Of course the original Markdown.pl was a good source for matching regular expressions too. What follows is a copy of the “seed page” “About the Word Count” from the CWiki wiki program: Begin Quote Up at the top of each page, below the author and creation/modification dates, there is a line showing the number of characters in the page along with an estimate of the number of words in the page.
Anyone who looks into my experimental outliner with notes, clown, is sure to notice that the native data format is EDN (Extensible Data Notation). The canonical data representation for outlines is OPML (Outline Processor Markup Language) and it is well suited for that purpose. It’s a dialect of XML especially adapted to outliners. So, why use EDN? Rich Hickey gives a good rationale at the link above. But for me it boils down to a few things.
Because of the ability to attach “watch” functions to Clojure atoms, it is very easy to create and use a simple undo/redo mechanism. The approach is to create a stack that holds every change to the state of the atom, as detected by a watch function. To undo something you just pop the last state off the stack. You can repeat it until you recover the original state of the atom as it existed when you attached the watch function.