Sat, 12 Sep 2020

Those pesky /usr/local/include headers under MacOS Catalina

— SjG @ 11:04 am

Here’s another of those “system upgrade moves stuff around” problems. My work iMac seems to be suffering a slow disk failure. It gets slower and slower as it tries to run.

Queue restoring TimeMachine backups onto a new iMac. A lot of stuff just works. But things like building xsendfile for the Apache development server under Mac ports threw lots of errors. The compiler couldn’t find the headers:

mod_xsendfile.c fatal error: stdio.h: no such file or directory

There are lots of suggestions out there to run xcode-select --install, but I’d already done that.

Turns out that XCode has stopped storing the SDKs in /Library/Developer/CommandLineTools/SDKs and moved them to /Applications/ I spent a bit of time trying to figure out how to pass that path to the Mac Ports version of apxs2 to use the new include path, but eventualy gave up and just did the hacky thing:
ln -s /Applications/ /Library/Developer/CommandLineTools/SDKs

Another issue, just so I rememebr next time, was that the web server and the command line were mysteriously running different versions of PHP. The key, of course, was that I had forgotten to run port select, e.g., for this project, I needed port select php php70.

Tue, 12 May 2020

Remembering things for my future forgetful self: developer’s edition

— SjG @ 3:57 pm

I need to record a bunch of training tutorials for a web site. I want to use consistent, fake data, so I set up a local copy of the site. I dumped out the database, and created my test data. As the site evolves, I can continue to check out revisions and run migrations, but still have my customized test data.

So far, so good. But a problem arises. When recording, the URL for my demo site shows up. This will confuse the customer. There’s an easy fix for this, of course, which is to change my demo site to respond to the true site’s hostname, and map it in my /etc/hosts file.

It works great! Except that I’m forgetful. I’ll be adding a new feature on my dev machine, get it approved on the staging server, and eventually check it out of revision control to launch it to the live server. I’ll check, and get confused. Where are my changes? I may go so far as to start looking at the filesystem of the live server and issuing informational commands in the revision control system, which will only confuse me more, as the changes are live. Eventually, I’ll notice that some of the data is demo-like data, and then I’ll kick myself for having wasted half an hour on something so stupid. I’ll comment out the line in my /etc/hosts, and everything will be back to normal… until it comes time to record new tutorials.

It’s time to remind future me. First step is in the terminal. I added the following to my .zshrc file:

export inhost=`egrep '127\.0\.0\.1\' /etc/hosts | wc -l`
export commented=`egrep '#127\.0\.0\.1\' /etc/hosts | wc -l`
if [[ "$inhost" -eq 1 && "$commented" -eq 0 ]]
    echo " ____  _______        ___    ____  _____ _"
    echo "| __ )| ____\ \      / / \  |  _ \| ____| |"
    echo "|  _ \|  _|  \ \ /\ / / _ \ | |_) |  _| | | "
    echo "| |_) | |___  \ V  V / ___ \|  _ <| |___|_|"
    echo "|____/|_____|  \_/\_/_/   \_\_| \_\_____(_)"
    echo ""
    echo "-----------------------------------------"
    echo " is remapped in /etc/hosts!!! "
    echo "-----------------------------------------"

This works well. When I’ve edited the /etc/hosts, my terminal comes up like:

Terminal with warning

But, future me may not go directly to the terminal to diagnose the issue. Future me may foolishly try to compare the current state of the site to the dev or staging version. Never fear! I can save future me from this idiocy.

First, I set my standard test browser to open up new windows and tabs with a “home page” instead of a blank page. That “home page” is http://localhost. I set up the default virtual host, and create an index page with the following barebones code:

<!DOCTYPE html>
<html lang="en">
  <meta charset="UTF-8">
$server = dns_get_record('');
if ($server[0]['ip'] == '')
{ ?>
  <h1 style="color:red">WARNING!</h1>
  <pre style="color:red">
----------------------------------------- is remapped in /etc/hosts!!!
  <?php } else { ?> we good.<?php } ?>
  <form class="search-form-home__form" action="" id="search" method="post">
       <input id="q" maxlength="2048" name="query" type="text" value=""/>
       <input type="hidden" name="cat" value="web"/>
       <input type="submit"/>

Now when future me opens up a new browser tab or window, he’ll be greeted with a nearly blank page with a search box. Or possibly a warning!

Warning in browser!

So, by spending a bunch of time now, I can save future me a bunch of time (and frustration). It’s not clear that it will be worth it, but it was definitely worth trying.

Fri, 27 Mar 2020

Fixing obsolete Karma test framework

— SjG @ 3:20 pm

Somewhere along the line, I did some software update on my MacBook machine that broke the Karma tests for an AngularJS 1.x application. I don’t know when this happened. I haven’t done work on this project on any computer except on my work desktop in a long, long time.

However, with Covid-19 and the work-from-home regimen, I need to make this work on the MacBook.

When I’d run the tests, I’d get a lovely crash:

27 03 2020 14:35:38.395:ERROR [reporter]: Can not load reporter "junit", it is not registered!
   Perhaps you are missing some plugin?
 27 03 2020 14:35:38.473:INFO [karma]: Karma v2.0.5 server started at
 27 03 2020 14:35:38.474:INFO [launcher]: Launching browser PhantomJS with unlimited concurrency
 27 03 2020 14:35:38.475:ERROR [karma]: { inspect: [Function: inspect] }

Naturally, the first thing I’d do is make sure I’d installed the correct plugin: npm install karma-junit-reporter --save … Node happily reinstalled the plugin, and nothing changed. The source of the issue turned out to be a conflict between the project-installed karma-cli and bits and bobs of an old global install.

I had to clean up the globally-installed stuff that was lurking in /usr/local/bin and /usr/local/lib/node_modules (which is to say, deleted /usr/local/lib/node_modules/karma, /usr/local/lib/node_modules/karma-jasmine, and /usr/local/lib/node_modules/jasmine) leaving everything in the local project install with the exception of karma-cli, which is still globally installed.

Wed, 2 Jan 2019

Using Makefiles for Teensy Development on Mac OS

— SjG @ 9:24 am

Even if you don’t want to use the Arduino IDE for building your application, or want to do fancy things that only the evil, convoluted syntax of Makefiles can provide, you can do Teensy development on the Mac from the command line. While there are a lot of guides out there on how to do it, I hadn’t seen a complete step-by-step set of instructions.

So with no further ado, here are the steps for building Teensy applications on Mac OS using the Makefiles and the mighty command line.

  1. Download the Arduino IDE from and install it.
  2. Download Teensyduino from and install it.
  3. Download a “basic project template” for Teensy. The original is at but I’ve been using the fork at which has been updated more recently and uses the Teensy CLI Loader for uploading to the device.
  4. Update the Makefile to set your Teensy model
  5. Type make to build, or make upload to install on your Teensy

If you’re wanting to monitor the serial console of your Teensy over USB, install a terminal program like CoolTerm. Alternatively, if you use Homebrew or MacPorts you can use a console-based terminal program like minicom. Once the USB connector is plugged in, your Teensy will show up as something like /dev/cu.usbmodem45504901. The communications settings will be 115200 baud, 8 bit, no parity, 1 stop bit.

Thu, 21 Sep 2017

Time Machine Backups

— SjG @ 3:37 pm

I use Time Machine for my local desktop backups. It’s a nice solution. It sits there quietly backing stuff up, keeping multiple revisions of files, and even keeping it all encrypted so if the external drive gets swiped it’s not going to be easy to get at the data.

Of course, it’s no substitute for a revision control system for code, nor is it good for situations where the office gets annihilated due to stray meteorite or drone strike. It’s not a complete solution, but it’s part of a broader collection of solutions.

Today I was reminded of some of the limitations. I used Time Machine to migrate to a new machine. That’s a pretty sweet process. You wait for a few hours of disk read time, and suddenly a new machine is populated with all your old settings, applications, data, and so on from your old machine.

But I found some things that weren’t quite right. Most of them had to do with processes that keep open files or databases, and don’t get backed up in a clean fashion.

  • Interestingly, Safari didn’t propagate Ublock Origin, which was a manually-added extension. This was the only surprising one of the bunch.
  • MySQL databases. I hadn’t shut down the MySQL server when the backup ran, so the table files from the Time Machine restore were corrupted. I was able to copy the files off the old machine (after shutting down mysqld gracefully), and use those.
  • TimeKeeper‘s datastore files were all corrupted. I had to delete them, and re-export/import the data from the old machine.
  • VMWare Virtual Machines. I knew they’d get corrupted if backed up by TimeMachine for the same reason as the above, but then I forgot that they weren’t backed up. I had to manually copy them off the old machine. This reminded me — if I want backups of my VMs, I need to do it myself!

That’s all thus far. Nothing too surprising, but a good reminder. Just because you’re backing up, doesn’t necessarily mean you’re backing up stuff in a restorable state!