Ashlar Infrastructure is in Play August 22, 2010 | 06:14 pm

Ashlar‘s infrastructure is now live. Basically, we have a compiler and a runtime (ashlarc and ashlar, respectively). Ashlar compiles code down to a component (JAR + properly configured metadata). When Ashlar executes, it loads the component (OSGi install + processing), checks the metadata for any additional components required, fetches those additional components via Ivy, and loads them. Only after all that is done does it invoke the component (OSGi start + processing), which fires off any module in the component with code to execute.

So, in short, you don’t have to muck about with the classpath in Ashlar: we resolve that automatically. If you need to do fancy Ivy stunts, you can muck about with ~/.ashlar/ivy.settings. If you don’t want to think about Ivy or if you mess up your ivy.settings, Ashlar will automatically generate an appropriate one.

We’ve got ashlar and ashlarc. I’d like two other programs eventually: ashlard to deploy components to a local Ivy repository that Ashlar uses, and ashlarx to be a REPL and execute scripts.

For testing, I’m using Cuke4Duke by way of my gradle-plugins. The functional tests act on the actual distribution: the very same code that will be zipped up to make a release. So I can’t get into a situation where the tests pass as long as I’m in the context of a unit test case, but compiled code bombed out on us.

As for the language itself: at this point, all the language can do is print out integers and rational numbers. Not terribly exciting. But the language itself is where the attention is going next: first, some rudimentary type-checking; then, mathematical operations.

Things are about to get a bit slower, because now that I’ve got to this point, I’m shifting some of my free-time focus back to other pending projects. But it’s a pretty exciting place to be.

  • Hamlet D’Arcy

    The OSGi stuff built into the language is a really good idea. Kudos for actually implementing it as well!