Archive for category Uncategorized
I’ve been wanting to spend some time checking out Octopress, and the series on rebar plugins provides me with a good opportunity to do this. Instead of spending my free time writing up a second post this week, I’ve opted to move the series to a custom location and use Octopress as a publishing engine.
My reasons for doing this are several. Firstly, as I mentioned, I wanted a chance to check out the Octopress wrap around Jekyll, and I must admit that so far I’m finding it nice and high level. Secondly, I wanted better handling of code highlighting than the free wordpress account gives me, and the pygments integration in Jekyll does the job very nicely. I also wanted to be able to provide sample code for each of the posts, and by publishing the series using github pages, I can use a single git repository to manage both the sample code and the gh-pages publication branch. All in all, it seems like a pretty neat solution.
From now on, rebar plugin tutorials will be published to http://hyperthunk.github.com/rebar-plugin-tutorial/.
A good example of how rebar-plugins can add useful features to your build, the rebar-dist-plugin allows you to produce an archive for your project which can be distributed rather than forcing people to use git/mercurial/etc to obtain and build your sources.
The plugin comes with some pre-defined assemblies (which are the plugin’s unit of configuration) for packaging up a rebar generated release, or project (i.e., the ebin, include and priv directories). Future releases will add other pre-packaged options such as sources, docs and so on.
Using the plugin is pretty simple, and there is some documentation on the project wiki which is mostly up to date.
A recent post on the erlang-questions mailing list got me thinking about the way that I manage multiple (concurrent) versions of Erlang/OTP at the moment. This only works on unix-like operating systems, but it has been useful until now.
Basically, I choose a common folder, which on OSX tends to be ~/Library/Erlang and somewhere similar on other *nixes. Under this directory I keep a subdirectory into which multiple ERTS versions can be installed and another site directory into which common/shared libraries and applications can be installed.
~/Library/Erlang/Current -> /Users/t4/Library/Erlang/Versions/R13B04
I then set my
$ERL_LIBS environment variable to the site directory and symlink the current folder as I wish. I also configure tools like epm and/or sutro to use the site directory as their target install folder, giving me a consistent way to install things.
The main thing lacking from this approach is that I have control over which libs/apps in the site directory are compatible with which installed versions of ERTS. A good solution to this that doesn’t force me to use an entire tool-chain in order to take advantage of it, sounds very promising.
Someone emailed me to ask how to get Joe’s example driver code to compile on snow leopard. The solution is to pass the right flags to gcc:
t4$ gcc -o exampledrv \
-arch x86_64 \
-fPIC -bundle \
-undefined suppress \
$CFLAGS complex.c port_driver.c
This will generally still fail at runtime unless you rename (or symlink to) the .dylib you’ve created so that your shared library has the .so extension, for which the erts code is explicitly looking. Caveat: this last point may have been fixed in recent Erlang/OTP releases, but I’m a little out of touch! Using rebar to build your port driver sources circumvents this naming issue either way.
More of a quick splurge than anything – I was looking over some old code and noticed a unit test that creates a lazy list of tests, each of which asserts some properties about a bisection based search over a set of stub objects which are all based on an existing superclass and have a property defined which returns a randomised value each time you interact with it. Unusual but kind of cool. Here’s the code…
def check_detect_using_bisect(searchbase, subject):
searchbase = list(searchbase)
item = searchbase[max(0, min(subject, len(searchbase) -1))]
universe = sorted(searchbase, key=salsa_key)
search_result = detect(cmp, item, universe, key=salsa_key)
reason = "item (%i) mapped_to (%i)" % (universe.index(item), universe.index(search_result))
assert_that(search_result, is_(not_none()), reason)
assert_that(search_result.salsaId, is_(equal_to(item.salsaId)), reason)
[ (yield testcase) for testcase in check_detect_using_bisect() ]
This is surprisingly tricky, but in the end (with a bit of help from the safari java console) I determined that the problem is with DNS resolution and have a work-around. Whether this affects everyone or just those of us lucky to be behind a corporate firewall, I don’t know. The fix for me, was to install Java 1.5 and set my java preferences to always choose the 1.5 JVM for running web apps/applets, after which everything seems to play nicely.
Installing java 1.5 on Snow Leopard is itself quite tricky. The secret is to get hold of the java 1.5 update for Leopard and open it using Pacifist, which allows you to navigate into the /System/Library/Frameworks/JavaVM.framework/Versions directory within the installer package, select the 1.5.0 folder and the symlink to it (1.5) then right click and select “install to default location”. Props to this blogger for revealing the secret to that old chestnut. Please be very careful though – if you don’t delete the existing symlink first (which has 1.5 pointing to the current 1.6 install), then you’ll blow away your existing installation!
Unfortunately this means I no longer have an excuse not to attend boring finance meetings whilst working from home.