fogbound.net




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 https://www.arduino.cc/en/main/software and install it.
  2. Download Teensyduino from https://www.pjrc.com/teensy/td_download.html and install it.
  3. Download a “basic project template” for Teensy. The original is at https://github.com/apmorton/teensy-template but I’ve been using the fork at https://github.com/a-j-f/teensy-template 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!


Wed, 11 Nov 2015

Mac Ports and X-Code Command-line tools

— SjG @ 1:59 pm

I was setting up a new Mac with Mac Ports… and ran into a weird problem.

First, installed Xcode from the App store. Took a long time, but was done. I mistakenly thought it had installed the command-line tools, because now I could run commands like “svn” from the command line. The Department of Tautologies reminds you that some command-line tools are command-line tools, and others are not.

So I tracked down my build problem to the fact that command-line tools were not installed. Following every guide everywhere, I typed:
xcode-select --install
But instead of the expected glorious dialog box and installation, I got the virtually-un-Googlable error:
xcode-select: error: no developer tools were found, and no install could be requested (perhaps no UI present), please install manually from 'developer.apple.com'.

To make a long story short, the problem was that I ran the xcode-select as root. Eventually, I found that running it as an ordinary user worked as expected.

After that, command-line tools are properly installed, and ports work as God intended them to.

Aside:
There are a lot of deceptive distractions out there.
Typing, for example, xcode-select -p returns the correct /Applications/Xcode.app/Contents/Developer path that you’d expect.
Similarly, the error in the port build was that the directory /usr/include does not exist.
Don’t be deceived. These are lies!


Sun, 18 Oct 2015

Yii mystery on Mac

— SjG @ 3:07 pm

I upgraded the Mac to Yosemite a year or so ago. Yesterday, I wanted to do some development on a project that I’d been idly thinking about. Unfortunately, it required a dependency in a package I’d installed via Mac Ports. I tried to upgrade it, but got an error that I was compiling for the wrong Darwin version. This means I haven’t actually updated any of my Ports since upgrading to Yosemite! For shame.

Rather than fix Mac Ports for Yosemite, and then again when I upgrade to El Capitan, I decided it was time to do that upgrade and then fix it. I went through and did so, and upgraded all my ports, and it all seemed to go well. I went from PHP 5.3 to PHP 5.5, and MySQL from 5.1 to 5.5, and it went without a snag — the web server came up and my old configuration was good, databases same. Everything seemed sweet and easy!

Ha! Sweet and easy with software? Not so fast, buckeroo! Working on another project, I found that Yii was crashing — but only from the command line!
exception 'CDbException' with message 'CDbConnection failed to open the DB connection: could not find driver' in /Users/samuelg/project/unicorn_rainbows/framework/db/CDbConnection.php:399

I quickly through a page up with phpinfo(), and saw that all the usual suspects were valid:

  • I was running the PHP I thought I was (Mac Ports version 5.5, not the built-in Mac OS version)
  • It was using the php.ini file I thought it was (in /opt/local/etc/php55/)
  • PDO was installed
  • PDO’s MySQL driver was installed
  • PHP’s configured recognized the drivers
  • Paths to any config files were correct
  • Ports were all normal
  • Default path to MySQL socket file was correct

Of course, this all makes sense, because my web pages that access the database were working.

So why not from Yii’s console program from the command line?

A quick php -version revealed the problem. It wasn’t the database configuration at all! Well, not exactly.
samuelg$ php --version
PHP 5.6.14 (cli) (built: Oct 15 2015 16:20:41)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

Wait, what? PHP 5.6? But… how?

samuel$ port installed | grep php
...
php55-mysql @5.5.30_0+mysqlnd (active)
php55-sqlite @5.5.30_0 (active)
php56 @5.6.6_0+libedit
php56 @5.6.14_0+libedit (active)

Yup, somehow, I’d installed some PHP 5.6 packages as well!

To solve the problem quickly, I uninstalled PHP 5.6. I could have upgraded everything to 5.6 (or just inactivated them, I suppose), but I just wanted to work on my original problem, not spend my day on system configuration.


Mon, 29 Jun 2015

Sorting lots of files into directories, by date

— SjG @ 10:32 am

A process handles periodic tasks, and each time it does, it spits out some telemetry. The telemetry gets written off into a file each time. This process could be any of a number of interesting things: a procmail script doing something with incoming email, a Twitter-bot responding to searches, an IRC-bot responding to events, or whatever. The only important thing in this case is that it creates a variable number of log files each day, and the log files all get dumped into a single directory.

Before long, the log directory will be filled with thousands of files, and will be unmanageable. But, for some reason, we want to keep all these logs, and maybe actually use them. So the key is a script to move the logs into sub-directories based on date.

It turns out it’s easy to write a bash script to create directories in a YYYY-MM format, and move the files into them appropriately. The key is in the stat command. Conveniently, the implementation of this command is completely different and incompatible between Mac OS/BSD and Linux. Jesus H. Christ.

Linux:

#!/bin/bash
for i in *.log
do
filemonth=`stat --format=%y $i | cut -c 1-7`
mkdir -p $filemonth
mv $i $filemonth/$i
done

In Linux, the stat command will give you the data in an ISO format, and using the cut command, you can extract YYYY-MM information. The -p flag to mkdir makes it silently exit without complaining if a directory by that name already exists.

MacOS (or presumably other BSDs):

#!/bin/bash
for i in *.log
do
filemonth=`stat -f%Sm -t %Y-%m $i`
mkdir -p $filemonth
mv $i $filemonth/$i
done

In this case, we’re telling stat that we want the modified date as a string, and we specify the time format.

Either of these would be easy to modify to single day resolution (changing which columns you cut in the Linux version, or the timestamp format in the Mac version).