My goal is to make it as easy to pick and choose which patches to Arc you want applied as it is, in most programming languages, to choose which libraries you want to use.
I collectively call patches, libraries, and tarballs “hacks”, as in “I’m using the arc3.1, ac1, and extend0 hacks”.
Dependencies aren’t handled automatically yet because I’m still thinking about the right way to do dependencies. Which means that currently you have to list every hack you want to use and all of their dependencies. Which is a pain. So this is a work in progress.
The input to the hackinator is a list of hacks. By default, each run of the hackinator creates a new, separate Arc directory, so that each run is independent. (You can also use the hackinator more like an installer by specifying a destination directory). The hacks are downloaded if needed, the tar files such as arc are unpacked, the libraries installed, and the patches applied. Finally, unless the
--norun option is given, Arc is run. Thus to run Arc, instead of:
$ cd arc3.1 $ mzscheme -f as.scm
you can say:
$ hack ycombinator.com/arc/arc3.1.tar
which will run an unadulterated copy of Arc 3.1. Or include some patches and libraries:
$ hack \ ycombinator.com/arc/arc3.1.tar \ awwx.ws/exit-on-eof2.patch \ awwx.ws/erp0.arc
In Linux and Mac OSX, you should be able to download and run the hackinator without anything else needing to be installed.
The hackinator hasn’t been ported to Windows.
$ wget http://awwx.ws/hack
make it executable:
$ chmod +x hack
$ ./hack hackinator version 4 Usage: ... $
(if you get an error message, please email me andrew.wilcox [at] gmail.com and copy and paste the output that you see. Ideally the hackinator should “just work” for everyone... emailing me with your error output will make that possible!)
$ hack config mzscheme /usr/bin/mzscheme $ hack config mzversion 4
Specifies the MzScheme executable to run. Defaults to running “
mzscheme” from your shell
The version of MzScheme that you’re using. Can be “3” or “4”, defaults to “4”. Ignored if
mzargs is set.
The command line arguments to use to run Arc. Defaults to “-m -f as.scm” for MzScheme version 3, and to “-f as.scm” for version 4.
Configuration variables are stored in the
~/.hackinator/config file, and may be set and displayed through
$ hack config
displays the current configuration settings.
$ hack config <variable> <value>
sets a configuration variable. For example:
hack config mzscheme ~/plt-4.1.5/bin/mzscheme
$ hack config <variable>
unsets the variable, so that the default will be used.
$ hack \ ycombinator.com/arc/arc3.1.tar \ awwx.ws/exit-on-eof2.patch \ awwx.ws/erp0.arc /tmp/RmrD3taXYd ycombinator.com/arc/arc3.1.tar awwx.ws/exit-on-eof2.patch awwx.ws/erp0.arc mzscheme -f as.scm Use (quit) to quit, (tl) to return here after an interrupt. arc> (erp (+ 1 2)) (+ 1 2): 3 3 arc> ^D $
libdirectory and set up to be loaded when Arc starts, patches are applied, and Arc is run.
--norunoption, MzScheme is started and Arc is run after the hacks have been applied.
Hacks can be found on the net (“http://awwx.ws/erp0.arc”) or located on the local filesystem (“./my.hack”).
If a hack name starts with “.”, “/”, or “~”, the hackinator will treat the name as a file path on the local filesystem.
A hack name starting with “scheme://” is used as a URL to download the hack from.
“http://” is the default, so that “awwx.ws/erp0.arc” works like “http://awwx.ws/erp0.arc”.
Files with the
.hack extension contain a list of hacks, which are downloaded and applied in the same way as if they had been listed on the command line. For example,
$ cat my.hack ycombinator.com/arc/arc3.1.tar awwx.ws/exit-on-eof2.patch awwx.ws/erp0.arc $ hack ./my.hack /tmp/RmrD3taXYd ycombinator.com/arc/arc3.1.tar awwx.ws/exit-on-eof2.patch awwx.ws/erp0.arc mzscheme -f as.scm Use (quit) to quit, (tl) to return here after an interrupt. arc>
Within the hack list file, plain file names that don’t contain a / are resolved to the same location as the hack list file. For example,
These are then loaded from
Don’t run Arc after the hacks have been downloaded and applied.
Specify the directory where the arc tar gets unpacked, the arc files stored, and the patches applied. A random directory in your TMP directory is used if
--directory is not specified. The directory is created if it doesn’t already exist.
First delete the directory specified by
--directory, if it already exists.
Don’t print out the location of the work directory and the names of the hacks as they are applied.
You can publish your own hacks through any service that lets you upload files to a location where they can be downloaded from a URL.
Note that for the hackinator to work correctly, you shouldn’t change a file once you’ve published it at a particular URL. If you’ve changed or updated your hack, publish the new version at a different URL. This can be as simple as incrementing a version number for each revision you publish: “foo0.arc”, “foo1.arc”, etc., or using a different directory path for each version: “v0/foo.arc”, “v1/foo.arc”.
Your own website
If you have your own website, just put your hacks on your website.
If you like git and are using github.com, once you’ve tagged your release, your released file will be found at a URL like this:
To find the URL in github, go to your repository, click on the “Source” tab, click on the “all tags” menu, and select your tag. Then navigate to the file you want to publish, and click on “raw”. That will be the URL to use.
You can host your files at Google Code Project Hosting, though you’ll have to fill in a description for your “project” to get your own file upload area.
The hackinator is in the public domain.