James Friend - mac

Running a Hypercard stack on a modern Mac

James — Thu, 06 Feb 2014 14:32:17 +0000

Updated: now works on Yosemite

A bunch of people have emailed me about getting Hypercard stacks running under emulation. Here is a pretty easy guide to running a Hypercard stack on a recent Mac (eg. running Mavericks, Mountain Lion, etc):

Place the Hypercard stack you want to access somewhere within your user folder: eg. Documents, or Desktop.

Download this zip file [95mb] containing the SheepShaver classic Mac emulator bundled with Mac OS 9 and Hypercard.

Extract and open hypercard.sheepvm. This should boot Mac OS 9.

On the Mac OS 9 desktop there should be a disk called "Unix". This is a virtual disk which actually lets you access files on your computer (eg. outside the emulator). Opening it is equivalent to opening your OS X /Users/ directory.

From there, navigate to your user folder (eg. your OS X username) and then to the folder you placed your Hypercard stack (in the first step).

Copy your Hypercard stack from the 'Unix' disk to somewhere on the OS 9 'Macintosh HD' disk.

Double-click the Hypercard stack in the location you placed it on the OS 9 'Macintosh HD' disk (or open it from within Hypercard).

Tags:

mac

hypercard

emulation

Why port emulators to the browser?

James — Fri, 18 Oct 2013 06:42:40 +0000

In a discussion on Hacker News about emulators being ported to the browser, I drew attention to my own project, PCE.js, which emulates a Macintosh Plus and an IBM PC/XT. Some of the questions brought up included why someone would undertake such a project, and also the legal considerations of including the software ROM required to boot the machine.

So, why port emulators of outdated computers to the browser? Well, to start with, I feel very strongly about the importance of learning from the past – not making the same mistakes again and again due to a lack of historical perspective. I was really inspired by Bret Victor's talk at the DBX conference, in which Bret demonstrated a bunch of technologies from the 1970s which attempted to solve problems that we're still wrestling with today. It's a great talk, and it precipitates the question; why haven't we figured this stuff out yet? Why do today's 'solutions' feel lame in comparison to these prototypes from several decades ago? If anything, it seems like we've gone backwards. The great past ideas Bret mentions, like Sketchpad, NLS, and Smalltalk, should inspire us to aim higher as we create the future.

Similarly, lots of great thinking and design can be found in old systems. The original Macintosh, with influence from the Xerox Alto, solved lots of user interface issues which people are still failing to think about today. A trivial example is that Mac OS, in 1984, had considered ‘angle of escape’ in its drop down menus. That is to say, menus don’t close when the mouse cuts a corner on the way to a submenu. It seems minor, but it’s something which Windows didn’t fix until 2001 (Windows XP), and plenty of web apps still do wrong to this day. The awesome usability and simplicity of the original Mac is something which should be available as a working, interactive demo to the newest generation of designers, makers and creators.

I also feel that the historical significance of these systems means they should be available to explore with a minimal barrier to entry. Making that happen, though, requires including the system ROM, OS and other software such as applications and games, along with the demo, which goes beyond what’s covered by ‘fair use’ in copyright terms. However I’d go as far as to say that making this stuff accessible has, to a degree, a moral imperative, and that it outweighs the negative of the technical infringement on copyright. Such software is, after all, ‘abandonware'; it hasn’t been sold commercially for a long time, and it’s also just really outdated, not likely to be used to any financial gain.

Being able to explore and interact with these once-pioneering systems, the Macintosh and the IBM PC, has great historical and educational potential, and that’s why I wanted to make them available in the most accessible way possible; in the browser, without any extra searching, downloading, installing. Batteries included, no assembly required.

Tags:

PCE.js - Classic Mac OS in the browser

James — Fri, 20 Sep 2013 04:56:44 +0000

I've just completed porting Hampa Hug's excellent PCE emulator to run in the browser, using Emscripten. I've mainly focused on the pce-macplus build. This is pretty awesome because it means you can run classic Mac OS in the browser. Check it out: PCE.js - Classic Mac OS in the browser.

I've also got the pce-ibmpc build working (emulating an IBM compatible, up to a 286 CPU), and and pce-atarist, an Atari ST emulator also, with browser demos coming soon for each.

A dump of the source is available here but I'll try to clean it up and make it available on GitHub when I get the chance.

Update: source on GitHub, and I've added an IBM PC Demo.

Tags:

Installing Pygame on Mac OS 10.8 Mountain Lion

James — Wed, 07 Aug 2013 08:34:15 +0000

I decided to install and play around with Pygame today, mainly as an excuse to write some Python for a minor departure from all the Javascript/Coffeescript I've been writing lately. Unfortunately the process wasn't entirely frictionless, due to Pygame not yet accounting for Apple's move to XQuartz as the recommended X11 implementation for Mac OS as of 10.8 Mountain Lion. As a result I ran into some compilation errors while Pygame was building it's native extensions, which fortunately were not too hard to fix as I had some familiarity with changes to X11 on Mountain Lion.

TL;DR you need to set some environment variables before installing Pygame

What didn't work

Running pip install pygame would fail as follows:

building 'pygame.display' extension
cc -fno-strict-aliasing -fno-common -dynamic -I/usr/local/include -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Ddarwin -I/Library/Frameworks/SDL.framework/Versions/Current/Headers -I/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/display.c -o build/temp.macosx-10.8-x86_64-2.7/src/display.o
In file included from src/display.c:30:
/Library/Frameworks/SDL.framework/Versions/Current/Headers/SDL_syswm.h:58:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
             ^
1 error generated.
error: command 'cc' failed with exit status 1

While building the native extention 'pygame.display', Xlib.h (a particular X11 header, required by SDL) is not found, as XQuartz's /opt/X11/include directory has not been specified to search for headers.

By setting some environment variables, we can configure the Pygame build process to build correctly. I found these in a few other blog posts, but they specified only -arch i386 for CFLAGS, LDFLAGS and ARCHFLAGS, which allowed the build process to complete, but import pygame fails (when running 64bit Python):

>>> import pygame
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/site-packages/pygame/__init__.py", line 95, in <module>
    from pygame.base import *
ImportError: dlopen(/usr/local/lib/python2.7/site-packages/pygame/base.so, 2): no suitable image found.  Did find:
/usr/local/lib/python2.7/site-packages/pygame/base.so: mach-o, but wrong architecture

What actually got Pygame working

The environment variables (gcc flags) required to allow Pygame to correctly build fat binaries (for both 32bit and 64bit Python) are:

export CC='/usr/bin/gcc'
export CFLAGS='-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -I/opt/X11/include -arch i386 -arch x86_64'
export LDFLAGS='-arch i386 -arch x86_64'
export ARCHFLAGS='-arch i386 -arch x86_64'

Then pip install pygame and python -c 'import pygame'. If no error is returned by Python, then you should now have a working installation of Pygame.

Additional details

I'm using homebrew-installed Python/pip, and I've set my $PATH with /usr/local/bin before the system-installed Python.

If you haven't installed Python/pip via homebrew (you're using the system-installed Python), you would likely need to run sudo pip install pygame.

If you're using another install method, such as easy_install, this fix should still work.

Before running pip install pygame, I had also installed Command Line Tools for XCode (walkthrough), as well as XQuartz, and the following homebrew packages: brew install sdl sdl_image sdl_mixer sdl_ttf smpeg portmidi.

If homebrew fails to install smpeg you might need to do the following:

brew tap homebrew/headonly
brew install --HEAD smpeg

Tags:

Setting up a new Mac for Node.js and Drupal development

James — Tue, 26 Mar 2013 14:00:01 +0000

UPDATE: I am now of the opinion that you're probably better off installing homebrew with a prefix of somewhere inside your user directory, eg. ~/.homebrew/. I mention this below as an alternative, but now this would be my primary recommendation. Some parts, however, such as configuring the Apple-included Apache installation, and the custom DNS resolvers, are system-wide changes, so you might not want to couple them to a particular user account. Perhaps consider brew installing a user-local copy of Apache, but use a system level installation of dnsmasq.

Original article text follows:

So you've got a fresh, clean Mountain Lion install and you need to get up and running for local development. Recently I spent a day doing just that, so I thought I'd write it all down, to save me from having to look all this stuff up again.

Install Xcode Command Line Tools

Available from the Apple Developer downloads area. You'll need an Apple ID.

This package includes llvm-gcc, which is a (mostly) compatible replacement for gcc. It will work for most homebrew formulas which build with gcc.

Install homebrew

homebrew can be conveniently installed with one line in the Terminal. As with all curl-to-sh style install scripts, you should read the script first to make sure it's not going to do anything bad. Don't say I didn't warn you :)

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

The most convenient approach to using homebrew is to make /usr/local writable to admin group, if you don’t mind a (sort of) security risk. Bear in mind, /Applications is writable by that group by default anyway, so unless you've locked that down also, this won't really make your system much more insecure than it already is.

sudo chmod -R g+w /usr/local

Unfortunately without doing this, homebrew doesn't work particularly well in its default install location. Alternatively install somewhere user-local like ~/homebrew if you're really concerned about security and locking down user permissions on your local machine.

Install Node.js

Node in particular is easier to install from the nodejs.org installer package, not homebrew. Due to some past disagreement between the maintainers of npm and homebrew, the homebrew formula for node doesn’t properly install npm. The official installer, however, works pretty well.

To get npm install -g working (without sudo) you may also want to change the global node_modules directory to have a group id of 'admin':

sudo chgrp -R admin /usr/local/lib/node_modules

You may also need to give g+w permissions to that directory tree, if you installed node after running the chmod command above. This comes with the same caveats as homebrew. If you're really security conscious, install node and npm somewhere in your user directory, rather than globally in /usr.

Install Redis & MongoDB (optional)

brew install redis
redis-server
brew install mongodb
mongod

Install MySQL

brew install mysql

Then follow the instructions depending on whether you want MySQL to run as your user account or a different one, where data should be stored and whether you want to start the daemon manually or run at login.

Eg. to set up databases to run as your user account, with data in /usr/local/var/mysql and running at login:

unset TMPDIR
mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

To have launchd start mysql at login:

ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents

Then to load mysql now:

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

Set up the root mysql account. Pick a better password than I have.

/usr/local/opt/mysql/bin/mysqladmin -u root password 123456

Install PHP 5.4 (optional)

PHP is not in the main homebrew packages, so you'll need to 'tap' some extra repos before you can install it.

brew tap homebrew/dupes
brew tap josegonzalez/homebrew-php

Update LoadModule directive in Apache config file to point to new PHP version

# /etc/apache2/httpd.conf
# Apple default:
# LoadModule php5_module libexec/apache2/libphp5.so
# This should be equivalent to $(brew --prefix php54)/libexec/apache2/libphp5.so
LoadModule php5_module /usr/local/opt/php54/libexec/apache2/libphp5.so

Add updated PHP version to the PATH in .bash_profile

# ~/.bash_profile
export PATH="$(brew --prefix php54)/bin:$PATH"

MySQL socket location & PHP PDO extension

When first running a PHP application which connects to MySQL, you may run in to errors relating to the socket through which PHP's PDO extension is attempting to connect to MySQL. This is because PDO is looking for the MySQL socket at /var/mysql/mysql.sock, but it's probably at /tmp/mysql.sock instead.

Some options you have include setting up a php.ini file:

sudo cp /etc/php.ini.default /etc/php.ini
sudo vi /etc/php.ini

and setting pdo_mysql.default_socket=/tmp/mysql.sock therein. If you go for the php.ini approach it might also be worth setting display_errors = On while you're there.

Or you could use a symbolic link to make PHP happy:

sudo mkdir /var/mysql
sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock

I'm not really sure which solution is best, but both seem to do the job.

Set up .dev TLD for local development using dnsmasq

No one likes having to go and edit your hosts file, or something similarly tedious, every single time they create a new local project. By setting up a special TLD and dynamic vhosts, we can avoid ever having to waste time with this stuff again.

brew install dnsmasq
mkdir -pv $(brew --prefix)/etc/

Configure dnsmasq

echo 'address=/.dev/127.0.0.1' > $(brew --prefix)/etc/dnsmasq.conf

Create LaunchDaemon so dnsmasq runs at startup

sudo cp -v $(brew --prefix dnsmasq)/homebrew.mxcl.dnsmasq.plist /Library/LaunchDaemons
sudo launchctl load -w /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

Set up a custom resolver to delegate resolution for .dev domains to dnsmasq

sudo mkdir -v /etc/resolver
sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolver/dev'

Set up dynamically configured mass virtual hosting in Apache

Ideally, all you should need to do to spool up a new site for development is create a directory under /srv/www. This Apache config should let you do just that. Create /etc/apache2/other/mass-vhost.conf:

<Directory /srv/www>
  Order Deny,Allow
  Allow from all
  AllowOverride All
</Directory>

NameVirtualHost *:80
<VirtualHost *:80>
  # get the server name from the Host: header
  UseCanonicalName Off
  # include the server name in the filenames used to satisfy requests
  VirtualDocumentRoot /srv/www/%1
</VirtualHost>

Create your sites directory

sudo mkdir -p /srv/www
sudo chown -R _www:_www /srv/www
sudo chmod -R g+w /srv/www

Add your user account to the _www group so you can write to /srv/www

sudo dseditgroup -o edit -a `whoami` -t user _www

Start Apache (and configure it to start automatically at startup)

sudo apachectl start

Install Drush

brew install drush

Set up a test Drupal site

Create a database in MySQL

cd /srv/www
drush dl drupal
mv drupal-* dtest

Create a Drupal settings.php file and fill it out with your database credentials.

In the site .htaccess file uncomment the directive:

# RewriteBase /

Navigate to http://dtest.dev/install.php Once installed, you should also be able to enable Clean URLs.

And you're done!

Tags: