1up Arcade Revived

Several years back I got into the hobby of arcade game restoration. I even created a blog documenting some of the work I did at 1up-arcade.com. I haven’t had the opportunity to do it for quite some time, though, and I let the website expire (it now appears to redirect to an Australian arcade – which is cool!).

I didn’t want to let the posts disappear off the internet, though, so I set up a subdomain, set up a fresh WordPress installation, and uploaded them.

Check it out here:

1up Arcade – Arcade game restoration

Raspberry Pi Emulation on a Mac

I use a Raspberry Pi as a controller for our X-Carve CNC machine, and it recently stopped booting (my guess is due to SD card corruption from being improperly shut down). I wanted to test out some configuration changes to allow for the SD card to be mounted completely read only, but I didn’t want to have to keep on rebooting the Pi. So I decided to look into emulation (running the Pi in a VM).

The Pi uses an ARM processor, which means that traditional virtual machine approaches like VirtualBox or VMWare wouldn’t be suited. I found a few gists online of people who have done similar things on their Macs that I thought could be useful as a starting point.

I used this as my basis: https://gist.github.com/thomasweng15/af0929114efce3524d55d10f170ff30d

First, one-time setup procedure (I put this in a file setup_qemu.sh)

#!/usr/bin/env bash

# # install qemu
# brew install qemu

# # download the latest stretch kernel and the necessary dtb file
# $ curl -OL https://github.com/dhruvvyas90/qemu-rpi-kernel/raw/master/kernel-qemu-4.14.79-stretch
# $ curl -OL https://github.com/dhruvvyas90/qemu-rpi-kernel/raw/master/versatile-pb.dtb

# # download and unzip the latest raspbian lite
# $ curl -o raspbian_lite_latest.zip -L https://downloads.raspberrypi.org/raspbian_lite_latest
# $ unzip raspbian_lite_latest.zip

export QEMU=$(which qemu-system-arm)
export RPI_KERNEL=kernel-qemu-4.14.79-stretch
export RPI_FS=2019-04-08-raspbian-stretch-lite.img
export RPI_FS_ZIP=2019-04-08_raspbian_lite_stretch.zip
export PTB_FILE=versatile-pb.dtb

# First time setup
# wipe old img file (uncomment this if you are share that's what you want to do!)
if [ -f $RPI_FS ]; then
    rm $RPI_FS
fi
if [ ! -f $RPI_FS ]; then
    unzip $RPI_FS_ZIP
fi

$QEMU -kernel ${RPI_KERNEL} \
    -cpu arm1176 \
    -m 256 \
    -M versatilepb \
    -dtb ${PTB_FILE} \
    -no-reboot \
    -serial mon:stdio \
    -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" \
    -drive "file=${RPI_FS},index=0,media=disk,format=raw"

# Paste the line below (after the comment). press enter, then ctrl-d when it is done booting
# sed -i -e 's/^/#/' /etc/ld.so.preload; sed -i -e 's/^/#/' /etc/ld.so.conf; sed -i -e 's/^/#/' /etc/fstab

Next, the script to run QEMU (I put this in run_qemu.sh):

#!/usr/bin/env bash

export QEMU=$(which qemu-system-arm)
export RPI_KERNEL=kernel-qemu-4.14.79-stretch
export RPI_FS=2019-04-08-raspbian-stretch-lite.img
export PTB_FILE=versatile-pb.dtb

$QEMU -kernel ${RPI_KERNEL} \
    -cpu arm1176 \
    -m 256 \
    -M versatilepb \
    -dtb ${PTB_FILE} \
    -serial mon:stdio \
    -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" \
    -drive "file=${RPI_FS},index=0,media=disk,format=raw" \
    -net user,hostfwd=tcp::5022-:22 \
    -net nic

pylint_django error – NoSuchChecker

I just spent an inordinate amount of time tracking down an issue with pylint-django that I had a hard time finding any clues on the internet about, so I’m documenting it here.

I use pylint and pylint-django to perform automated checks on my Django projects and ensure a certain code quality is maintained. This combination has proven very useful. Recently, though, I ran into an issue where one project would fail to validate with a strange error:

$ pylint --rcfile pylintrc myproject
Using config file /app/pylintrc
Traceback (most recent call last):
  File "/usr/bin/pylint", line 11, in <module>
    sys.exit(run_pylint())
  File "/usr/lib/python3.6/site-packages/pylint/__init__.py", line 16, in run_pylint
    Run(sys.argv[1:])
  File "/usr/lib/python3.6/site-packages/pylint/lint.py", line 1312, in __init__
    linter.load_plugin_modules(plugins)
  File "/usr/lib/python3.6/site-packages/pylint/lint.py", line 495, in load_plugin_modules
    module.register(self)
  File "/usr/lib/python3.6/site-packages/pylint_django/plugin.py", line 18, in register
    name_checker = get_checker(linter, NameChecker)
  File "/usr/lib/python3.6/site-packages/pylint_plugin_utils/__init__.py", line 30, in get_checker
    raise NoSuchChecker(checker_class)
pylint_plugin_utils.NoSuchChecker: <class 'pylint.checkers.base.NameChecker'>

Investigation

I thought maybe this had to do with some incompatibilities between pylint, pylint-django, and possibly astroid, but strangely, the versions in this project were exactly the same as the other project. So I dug into the code where the exception was being reported.

get_checker is a part of pylint_plugin_utils, and it is used by pylint-django to augment the base PyLint checkers. It was trying to find pylint.checkers.base.NameChecker in the list of registered “checkers” for pylint. The file pylint/checkers/base.py" did exist in thesite-packagesfolder, but strangely, it was being registered assite_packages.pylint.checkers.base.NameChecker`.

Pylint has a register_plugins function that it uses to register all the default plugins. It does this by calling modutils.load_module_from_file on each of the files it finds starting from the checkers directory included with the library.

load_module_from_file figures out the proper import path using a function modpath_from_file, which in turn uses modpath_from_file_with_callback to check that each path it traverses has a __init__.py file. It looks at each path in sys.path in order to determine if the file attempting to be loaded has a valid import path.

What was throwing things off was the presence of __init__.py in the site-packages directory. /usr/lib/python3.6 was in sys.path before /usr/lib/python3.6/site-packages, and because there was a __init__.py file in site-packages, the import mechanism thought that site-packages was itself a module in the /usr/lib/python3.6 directory. It was therefore assigning this as the module name. Now where was that coming from?

Fix

It turns out it was a rogue package that stuck that empty file there (singletons). I removed that file (and thankfully had control over the project where that file originated and removed it from the source), and that fixed the issue.

Cloud9 as a Development Environment

I first encountered Cloud9 (the IDE, not the professional gamers) a couple years ago, when I was looking for a nice HTML/CSS editor for the students in my Exploring Computer Science course to use on their own laptops. I settled on it because it had good highlighting, didn’t require them to understand anything on the command line, but still focused on raw code as opposed to WYSIWYG stuff.

Since I stopped teaching high school, I hadn’t thought much about it. As a boot camp instructor, it was important to me that I teach my students how to use “real” tools, and so we focused on local tools.

At the moment though, I find myself temporarily without a dev machine, and my mind turned back to Cloud9. I’m mainly working in libraries (hurrah for free access to computers!), and while I can thankfully count on them to have Google Chrome, I can’t count on much else.

So, how can I do some real development without a real dev machine? I started up a new (free) account to find out.

Continue reading →