Ragnar Dahlén

Clojure Cup 2013, Pong and core.async

2013-10-01T00:00:00+00:00

Last weekend, Thomas, Jon, Paul and I teamed up to participate in the very first Clojure Cup.

It was great fun and resulted in Torus Pong, a multi-player take on the classic game of Pong (with a twist). You can check it out at pong.clojurecup.com.

If you feel so inclined, please give it a vote here.

The source code is available under the uSwitch GitHub organization at: https://github.com/uswitch/torus-pong

Thomas has written a great post about the process leading up to the “finished” game, the current status, some lessons learned and things we didn’t have time for (lots!).

In this post, I thought I’d share some more techincal information around the implementation, in particular how we leveraged channels and processes provided by core.async to help us decouple different components and handle asynchrony and communication. Hopefully, it can provide an interesting example of an application using core.async. Saying that, all code was written in 48hrs so treat it accordingly.

Most code examples shown have been simplified to illustrate a point, and may not be exactly as they are in the game source code.

The Game

In essence, our idea was to allow multiple players to play a game of Pong together. Each player would gets his own paddle and an even share of the whole playing field field, but with a different opponent on each side.

The last playing field would be connected to the first, forming a circular list of playing fields, or, with a bit of imagination, a torus.

The Problem(s)

As a team, we are all quite green when it comes to game development. This means I’m probably missing a lot of terminology and well-known solutions to typical game programming problems, so bare with me.

During our design discussions in between work on thursday and friday, a couple of distinct problems emerged. I would say the three most important ones were:

game core: how does the game actually work and how do we implement its rules?
communication: how do handle communication between players and server?
rendering: what should the game look like to the user?

I think one reason we were able to complete anything at all was finding these parts, understanding their interactions and then pulling them apart as much as possible, enabling parallel design, implementation and change.

Game Core

I won’t spend any time on the game rules and their implementation, but we’ll look brifefly at the interface to the core game logic.

This interface is a single pure function that given a game-state and some commands from players, produces a new game-state. This function is called each time the game should advance and is responsible for enforcing the rules of the game, physics, scoring etc.

The implementation ended up looking something like this:

(defn advance
  "Given a game-state and some commands, advance the game-state one iteration"
  [game-state commands]
  (-> game-state
      (apply-scoring)
      (handle-commands commands)
      (check-for-winner)
      (advance-fields)
      (play-sounds)
      (update-ball-fields)))

Engine

Given the core game function, we needed something that was responsible for feeding it with commands, and applying it to the current game-state when appropriate. We called this part the engine, and this is where core.async enters the picture.

We modeled the engine as a process that: - takes and accumulates commands from a command channel - advances the game at some interval, determined by a timeout expiring - puts each new game-state to a game-state channel

Visually, this looks like this (blue boxes are channels):

The implementation uses alts! to wait for either a command to appear or the timer to elapse, taking the appropriate action in each case.

(defn engine-process
  [command-chan game-state-chan]
  (go (loop [game-state game-core/initial-game-state
             commands   []
             timer      (timeout params/tick-ms)]
        (let [[v c] (alts! [timer command-chan] :priority true)]
          (condp = c
            command-chan (when v
                           (recur game-state (conj commands v) timer))
            timer        (let [new-game-state (game-core/advance game-state commands)]
                           (>! game-state-chan updated-game-state)
                           (recur new-game-state [] (timeout params/tick-ms))))))))

Talking to Clients

Being a browser based game, we chose WebSockets for client/server communication. Kevin Lynagh has released an excellent library called jetty7-websockets-async which bridges the gap between the jetty7 WebSocket implementation and core.async in a very elegant way.

The library works as follows:

you hand it a channel on which you want new WebSocket connections to be put as clients connect
you can then take new WebSocket connections from this channel, where each connection is represented by a channel pair:
- in: on which you can put messages that should be sent to client
- out: from which you can take messages received from the client

The Connection Process

We have a singleton process that accepts new connections from a connection channel, and then spawns a separate process to handle further communication with the client. A slightly simplified version of the code that does this is as follows:

(defn connection-process
  [conn-chan command-chan]
  (go (loop [conn (<! conn-chan)]
        (when conn
          (let [{:keys [in out]} conn
                id (next-id!)]
            (client-process id in out command-chan)
            (recur (<! conn-chan)))))))

We read from the connection channel. When we get a new connection we pull out the in and out channels, generate a new unique id for the client and spawn a client process, passing it the id, the in and out channels as well as the shared command-chan.

The Client Process

The main responsibility of the client process is to forward commands from the out channel of the client to the command channel consumed by the engine, decorating them with a player id:

The implementation:

(defn client-process
  [id in out command-chan]
  (go
    (>! command-chan [:player/join id])
    (loop [msg (<! out)]
      (when msg
        (let [command (clojure.edn/read-string msg)]
          (>! command-chan (conj command id))
          (recur (<! out)))))
    (>! command-chan [:player/leave id])))

The code works as follows:

notify engine that a new player has joined by sending a [:player/join id] command to command-chan
repeatedly read messages from WebSocket out channel, parse them as EDN, tack on the client id and forward to engine
when nil is read from out, meaning the connection has been closed, notify game engine that the player has left by sending a [:player/leave id command, and exit the process.

Propagating Change

So far we can accept new players, feed their commands to the game engine and advance the game.

The final part is propagating information about new game states to clients. This is handeled by a process we called the game-state emitter.

This process consumes new game-state data put on the game-state channel by the engine process. It then broadcasts this data in some form to connected clients.

This process needs to know which channel it should use to talk to a specific client. This information is conveyed by an atom with mappings from player ids to in channels. This mapping is maintained by the connection and client processes described above, but I omitted them in this post to simplify matters.

Our implementation ended up always sending the entire game state to all players in the game.

(defn game-state-emitter
  [game-state-chan clients-atom]
  (go (loop [game-state (<! game-state-chan)]
        (when game-state
          (doseq [[player-id client-chan] @clients-atom]
            (>! client-chan (pr-str game-state)))
          (recur (<! game-state-chan))))))

All Together Now

Putting channels, processes and shared state together, we get something like this:

The angry pink box is of course the shared state, ie. the atom described above. We could have eliminated this by introducing a bit more communication, but we didn’t have time to.

Once you get past the core.async concepts, the architecture is really very simple, and worked out quite well for us.

A Word on Buffering

One thing I really like about core.async is the way it forces you to think about contention in a system of communicating processes. By default, all channels are unbuffered and blocking¹, meaning that if you try to put something on a channel, and nobody is there to take it, you will block until someone arrives on the other end (and vice versa).

This is a great default, but it’s also simple to introduce different buffering policies when needed. We didn’t have a lot of time to tune this, but there are definitely places we should improve.

One example is the game-state channel:

When the engine has produced a new game-state, it wants to continue to accumulate new commands and prepare for the next iteration. If the emitter is busy transmitting a previous game to all clients, it won’t pickup the new game-state until its ready. This would block the progress of the engine, which is bad.

We could improve this by using a sliding-buffer of size 1 for the game-state channel. In that case, each new game-state put to the channel would just replace the previous, older one. The engine could continue immediately, and the emitter, when ready, would pick up the latest game-state available. It doesn’t care about older game-states it didn’t have time to distribute.

As the code currently stand, the impact of this issue is reduced by the fact that we’re wrapping each client channel in a sliding-buffer.

It think there are lots of interesting things to explore in this area.

Summary

I’ve tried to explain the way we used core.async in our architecture.

There are lots of things I didn’t mention, like:

how we used it on the client side
how we halfway through the competition changed the entire structure of the game, but only had to introduce one more simple process

There are, of course, also lots of things we didn’t have time to do.

One thing in particular, that I’d really like to do at some point is implement interpolation, input prediction and lag compensation as described in Source Multiplayer Networking. The game play currently requires very low latencies, and I’m almost amazed it works as well as it does, considering the way input, communication and rendering is currently coupled.

If you read this far, played the game and maybe even liked it, please don’t forget to vote.

blocking an actual JVM thread. A great discussion on this, and core.async in general can be found on episode 35 of the Think Relevance podcast.

blocking in core.async is not necessarily the same as ↩

Datomic in the Browser

2013-08-12T00:00:00+00:00

Lately, I’ve been having a lot of fun using Datomic on a couple of projects. One of them is something we’re calling torch, a source code analysis and visualisation tool built on top of codeq. It’s mostly an experiment which will hopefully help us understand and visualise some aspects of our entire Clojure code-base at uSwitch. If you happen to be attending FP Days in Cambridge, you might get to see more of torch.

torch is currently a single-page browser application built in ClojureScript, and in this post, I’ll show how we leverage the power of Datomic from the browser using core.async and the Datomic REST API.

Going Hypertext

A big part of torch is just querying Datomic for facts, possibly deriving some new information, in order to then visualise it.

Our initial prototype was a Java application but for a couple of reasons which are not important for this post, we have since moved to a browser based ClojureScript app.

One thing that was obviously really easy in the Java application was talking to Datomic, we could just use the standard Clojure API. Querying Datomic is most commonly done using its dialect of Datalog, and the process of connecting and performing a query looks something like this:

;; create a connection to the codeq database on the Datomic
;; system running on localhost:4334
(def conn (datomic.api/connect "datomic:free://localhost:4334/codeq"))

;; capture the most recent value of the database known by this peer 
(def db (datomic.api/db conn))

;; perform a query
(let [res (datomic.api/q '[:find ?e ?v
                           :where [?e :db/doc ?v]]
                         db)]
  ...)

The query finds all entities with a :db/doc attribute, and returns the id of each entity and the documentation string.

It does this by calling the q function in the datomic.api namespace, passing in a query expressed using a data structure, and the database value that should be used as the basis for the query¹.

So, moving to a browser based app, how do we query Datomic?

Datomic REST API

Fortunately, Datomic provides a REST API out of the box. If you have a Datomic free system running on localhost:4334, you can start a HTTP server exposing a REST interface to that system on port 9000 like this:

> bin/rest -o "*" -p 9000 free datomic:free://localhost:4334/

The -o specifies allowed origins, we’re being overly liberal in this example. With this process running, we can now fire off queries over good old HTTP.

The query resource, exposed at /api/query requires two parameters:

q — the query
args — a vector of arguments to the query

Both arguments should be the URL encoded EDN representation of its data.

args is a little bit special in that it always needs to include at least one element, {:db/alias "your-storage/your-db"}, identifying which database to query. In our example, it would be {:db/alias "free/codeq"}.

Compared to 99.999% of all HTTP APIs on the web, Datomic also makes the very unorthodox choice of using a sane² format for data interchange, EDN. This means we need to indicate that we accept content of type application/edn.

So how does the same query look using this approach?

curl -H "Accept: application/edn" "http://localhost:9000/api/query?q=%5B%3Afind+%3Fe+%3Fv+%3Ain+%24+%3Awhere+%5B%3Fe+%3Adb%2Fdoc+%3Fv%5D%5D&args=%5B%7B%3Adb%2Falias+"free%2Fenergy-pal-perf"%7D%5D&offset=&limit="

A slight step back from the elegance of the Java/Clojure API, but the ability is there. So how can we use this in ClojureScript?

A Diversion on HTTP

The Google Closure Library provides a few ways to do HTTP requests, the most basic one being the static method goog.net.XhrIo/send which provides an interface very similar to most AJAX-capable JavaScript libraries. We can use this method for writing a very simple function that can GET some EDN from a given URL:

(defn get-edn
  [url callback]
  (goog.net.XhrIo/send url
                       (fn [e] (callback (edn-response e)))
                      "GET"
                       nil
                       (clj->js {"Accept" "application/edn"}))

This should seem fairly familiar; we pass in a URL, a callback, the HTTP verb, maybe a body (nil in this case) and some headers.

Before calling the user-supplied callback, we apply edn-response to the result of the operation to save the caller from having to mess with the XhrIo result object. So, edn-response is a function that receives the result of an XhrIo/send, checks if it was successful and returns either a vector of :ok and the EDN data in the body, or :fail and the status code.

(defn edn-response
  [e]
  (let [res (.-target e)]
    (if (.isSuccess res)
      [:ok (cljs.reader/read-string (.getResponseText res))]
      [:error (.getStatus res)])))

As a consumer of get-edn, you would use it like this:

(get-edn "http://localhost:9000/api/query?q=..."
         (fn [[status value]]
           (.log js/console (str "Got status " status " and value " value)))

Nothing revolutionary here. However, there is a fundamental difference from the in-process Java version. The fact that we have to supply a callback that will be invoked when the operation has completed means that we give up some of our control over the flow of the program. This is unfortunate, but the asynchronous callback based model is simply something we have to live with when doing I/O in JavaScript.

Or is it?

Turning the World Inside Out With core.async

The core.async library is another piece of very inspiring work which we in this particular case can use to invert the control of asynchronous HTTP calls.

We can modify our get-edn function to not take a callback, but instead return a channel on which the result of the operation will be put when the the operation completes. For this example, you can think of a channel as a queue with room for exactly one element. This could look something like this:

(defn get-edn
  [url]
  (let [c (chan)]
    (goog.net.XhrIo/send url
                         (fn [e] (put! c (edn-response e))
                         "GET"
                         nil
                         (clj->js {"Accept" "application/edn"}))
    c))

This time, we create a channel using chan, fire off the request and return the channel immediately. When the request has completed, the callback function will use edn-response as before and then simply put! the resulting value on the channel.

We can use our channel based get-edn like so:

(go
  (let [[status value] (<! (get-edn "http://localhost:9000/api/query?q=..."))]
    (.log js/console (str "Got status" status " and value " value))))

This short snippet contains a lot of core.async concepts but one way of understanding it is as follows:

We call get-edn which will return a channel on which the result of the request will eventually be put!
We use <! to read a value from the channel. If no value is available yet, execution will be parked at this point, and resumed when a value becomes available.
This parking is made possible by the go macro, which wraps our code.

This is really only scratching the surface of what’s possible with core.async.

The important bit is that we’ve regained control of the program flow, we’re no longer forced to hand over a callback that will be used to resume our execution in some other place.

Tying the Knot

We now have a nice way of doing HTTP requests for getting EDN, which we can use to talk to the Datomic REST API.

As we’ve seen, the REST API requires two parameters, q the query, and args, any args to the query. Both are expressed using Clojure data structures, but when transmitted they should be the URL encoded EDN representations of this data. Unsurprisingly, the Closure Library knows how to URL encode strings, and ClojureScript how to generate EDN from Clojure data. We combine this knowledge in the encode function:

(defn encode
  [data]
  (goog.string/urlEncode (pr-str data)))

To perform queries, we need to know where the URL of the REST API, which storage it uses and the database we wish to query. We introduce a connect function that given those parameters returns a map with all information we need to perform multiple queries.

(defn connect
  [rest-api-url storage db-name]
  {:url      rest-api-url
   :db/alias (str storage "/" db-name)})

Calling it connect is a bit of a misnomer given what it currently does. I’ll discuss this in the next section.

We can now implement a q function with an interface that is superficially quite similar to what we have in the Clojure/Java API:

(defn q
  [query conn & args]
  (let [args (into [(select-keys conn [:db/alias])] args)]
    (get-edn (str (:url db)
                  "/api/query"
                  "?q="    (encode query)
                  "&args=" (encode args)))))

Finally, we can perform the same query as above from ClojureScript:

(def conn (connect "http://localhost:9000" "free" "codeq"))

;; perform a query
(let [[status res] (<! (q '[:find ?e ?v
                            :where [?e :db/doc ?v]]
                          conn))]
  ...)

The Database as a Value (?)

It should be noted that the interface of the q function is actually quite different from the native API. We perform the query directly on a connection, rather than a database value. This means we lose the stable basis, which is a big deal. Every query will execute on whatever the latest value of database is when the query is received.

However, the Datomic REST API supports specifying the value of the database you wish the query to be performed against, and it is also possible to query for the current version. This means that it is possible to implement the notion of a database value even in the browser. In the interest of keeping this post to a reasonable length, I’ll stop here.

are completely awesome about Datomic, and you should give it a try and find out what they are.

The Language of the System talk for a very good motivation for this.

This sentence quickly sweeps over at least two things that ↩
Hop forward to ~38:10 of Rich Hickeys ↩

Exploring enlive

2013-04-19T00:00:00+00:00

Templating is perhaps not the most interesting topic in software engineering, but nevertheless a useful technique in practice. Whether you are generating HTML for a web application or creating a PDF from the latest TPS¹ report, some kind of templating might just make your life better.

enlive is a clojure templating library created by Christophe Grand. It is not a general purpose templating solution, rather it is specifically targeted at generating HTML². While this may sound very limiting, it is simply a tradeoff that also enables other things, giving enlive some of its power.

We’ve given enlive a go in one of our internal clojure applications at work for a couple of months and I think it has been an interesting experience.

Besides being a very usable templating library for clojure applications, I think enlive provides a model that is quite interesting in itself, worth exploring simply for educational purposes.

With this series of posts, I hope to collect and share some of my thoughts and creations around enlive and its usage.

lack of namespace support.

http://www.youtube.com/watch?v=Fy3rjQGc6lA ↩
XML is doable too, although it is somewhat limited due to the ↩

Exploring enlive: A Peek Behind the Curtain

2013-04-19T00:00:00+00:00

This post is part of a small series of posts on enlive. See Exploring Enlive for the background.

Understanding enlive

The fundamental model implemented by enlive is slightly different from many other templating solutions¹, and, while it is not necessarily more complicated than other models, I think that understanding it well is key to a good enlive experience. With this post, I hope to share some realisations that helped me understand enlive better.

I will begin by simply stating the following minimal enlive example:

(ns initech.reports
  (:require [net.cgrand.enlive-html :as enlive]))

(enlive/deftemplate tps-report "tps-report.html"
  [report-data]
  [:head :title] (enlive/content
                   (str "TPS Report for" (:date report-data)))

Depending on your background, some of this may make sense, some of it may be more cryptic. The interesting part of the above snippet is the contents of the deftemplate form, which can be read as:

give me a function called tps-report that uses tps-report.html as its template, and when given some report-data finds all title elements that are descendants of head elements (hopefully only one), and replaces their content with a nice string with the date from the report-data.

Let’s see how all this is actually accomplished.

The Enlive Way

The process of constructing a document using enlive can be divided into the following three steps:

Start with one or more source documents
Pick the parts you want from the source document(s)
Modify and/or put the parts together, forming a new document

Enlive Data

The first step is parsing the source documents into what I’ll call enlive data. This is the fundamental data structure used by enlive in the other two steps. While knowing about this data structure is not strictly required, I think it is very helpful for understanding the last step, and it also gives you more power as a user of the library.

A source document is simply a plain old HTML file, no special funny-looking markup or tags. It only serves as a base (or template, if you will) from which you can pick as much, or as little as you want for your output document.

The data structure for enlive data is a very simple tree, represented using nested maps. Each individual map is referred to as a node.

Example

This HTML snippet:

<div id="message">
  <h1>Warning!</h1>
  <p class="wat">Invalid use of robot</p>
</div>

Will be translated into the following enlive data:

{:tag     :div
 :attrs   {"id" "message"}
 :content ({:tag     :h1
            :attrs   nil
            :content "Warning"}
           {:tag     :p
            :attrs   {"class" "wat"}
            :content "Invalid use of robot"})}

As illustrated, a node map has the keys tag, attrs and content. There are a few other node types, for example used to represent a doctype, but you will rarely need to know about those.

Selection

The second step is picking the parts of the template that you wish to use or affect. So, given some enlive data, we want to select a subset of the nodes for some further processing.

Expressed more succinctly, selection is a function of enlive data to a sequence of nodes.

This function could have been expressed using plain clojure, but since enlive targets HTML, it can leverage a more domain specific language for this purpose: CSS selectors.

CSS selectors where initially conceived for CSS stylesheets, where they are used to determine which elements certain style attributes should apply to. However, they are more general than that, it is really a pattern language for matching DOM elements. For example, jQuery uses CSS selectors to select a subset of DOM elements for some function application.

The enlive implementation of selectors is not strictly equivalent to CSS selectors, but most patterns translate quite easily. In enlive, a selector is represented using clojure data rather than strings. Christophe has a good explanation on the syntax in the readme.

Example

;; match all p elements that are descendants of the div element with id 'message'
[:div#message p]

;; match all p elements that have a 'wat' class
[:p.wat]

;; match the second tr of all tables
[:table [:tr (nth-of-type 2)]]

Transformation

The final step is where the action happens.

Each selector has a corresponding transformation, they are specified in pairs. Since selection is a function that selects (returns) a sequence of nodes, it may not be surprising to learn that transformation is a function that is applied to each of the selected nodes. This will yield a new document where each node has been “replaced” by the result of the transformation function. Thus, transformation is a function from a single node to a single node, or to a sequence of nodes.

Let’s take a look at a specific part of the initial example:

[:head :title] (enlive/content
                 (str "TPS Report for" (:date report-data)))

The body of a deftemplate form specifies pairs of selectors (a vector) and transformations. In this case we have one selector, [:head :title] and its corresponding transformation. So what does the enlive/content function actually do?

Looking at the enlive source code, you would find something almost² like this:

(defn content
  [value]
  (fn [node] (assoc node :content value)))

So, enlive/content returns a new function that when given a node, assocs a new value for the :content of that node. Functions returning functions can be hard to grasp at first glance, but we could just as easily declare the same transformation inline in our template:

[:head :title] (fn [node]
                 (assoc node
                   :content (str "TPS Report for" (:date report-data)))))

Understanding selectors and transformations at this level made a great difference for me.

Most transformations provided by enlive are really utility functions that help you construct appropriate transformation functions. These functions will take you far without having to write your own transformation, but knowing what really goes on is always powerful.

Moving On

Hopefully, this post has given some insight into the fundamental workings of enlive. The next, and perhaps most difficult step, is to understand how to best use the constructs enlive provides to actually get what you want; a pretty HTML document.

This may require a change of thinking. Some things which you know are trivial in your favourite templating language might seem verbose when you try to implement them using enlive. While enlive is definitely more suited for certain scenarios, and less for others, I’ve often found that this perceived difficulty is more a result of how you’re used to think about templating, than anything else.

You simply need to approach the problem in a different way, much like the way you change your thinking when moving from object-oriented programming to functional programming.

This might be the topic of a future post.

that scare you.

Funnily enough it is quite similair to XSLT, but don’t let ↩
But not quite: actual implementation ↩

Exploring enlive: enlive, meet haml

2013-04-19T00:00:00+00:00

This post is part of a small series of posts on enlive. See Exploring Enlive for the background.

In Search of Lost Joy

Out of the box, enlive supports only HTML documents as the source for templates. When we started using enlive, one thing we quickly re-discovered was how incredibly dull and cumbersome it is to actually work with HTML.

One popular templating language that aims to remedy this is haml, marketed as a “Beautiful, DRY, well-indented, clear markup” for creating HTML-like documents. A quick taste for the uninitiated:

#message
  %h1 Warning!
  %p.wat Invalid use of robot

↓

<div id="message">
  <h1>Warning!</h1>
  <p class="wat">Invalid use of robot</p>
</div>

However, in all its beauty, haml has slightly a less exciting model for actually generating dynamic content. Like many other templating solutions, it allows you to embed and execute arbitrary code in your template.

Nothing particularly wrong with that, but it would be interesting to see if one could leverage the terse way of describing a HTML-like document provided by haml with the enlive model for transformation and composition.

A Seed is Planted

Unsurprisingly, we were not the first ones to experience the pain of HTML when using enlive, and other people have explored ways of marrying it with haml.

Two noteworthy approaches:

Daniel Higginbotham explains how to use Middleman to comfortably generate HTML from haml templates out of band, and then use the generated HTML in an enlive template: blog post
Yoko Harada uses jRuby and the haml gem to generate HTML: blog post

I think both approaches are interesting and have their strengths and weaknesses, but my main concern with both of them was the added ceremony and slightly awkward integration.

My starting point when exploring this idea further was this: Given an enlive template definition, such as:

(deftemplate tps-report "tps-report.html"
  [report-data]
  ...)

Would it be possibly to somehow just specify a haml document as source instead, and have it all work out nicely:

(deftemplate tps-report "tps-report.haml" ;; <- OMG, different extension!
  [report-data]
  ...)

After a quick look in the enlive source the idea seemed quite possible. All that was needed was, given a source, provide enlive with some enlive data, and leave it to do its magic.

Also, since the goal is to use enlive for the transformation and composition, we don’t care about the parts of haml that concern embedded code.

Given this limitation, how hard can it be to write something that reads a haml document, skips any code related content, and translates it into enlive data?

Enter hamelito

Not entirely trivial, it turned out, but quite fun and a good hacking project for my daily commute:

hamelito is a clojure library that allows you to use a subset of haml as the source for enlive templates

For the parsing, I use excellent parser combinator library kern by Armando Blancas. A pleasure to learn and very well documented.

With exceptionally good timing to my little effort, Christophe also added support for pluggable parsers to enlive, defining an interface for libraries like hamelito.

The result:

(ns blahonga
  (require [net.cgrand.enlive-html             :as enlive]
           [com.github.ragnard.hamelito.enlive :as haml]))

;; To use haml for all templates in the current namespace:
(enlive/set-ns-parser! haml/parser)

(deftemplate tps-report "tps-report.haml" ;; <- mission accomplished!
  [report-data]
  ...)

;; To use haml for a specific template/snippet:
(enlive/deftemplate haml-template {:parser haml/parser} "template.haml"
  []
  ...)

Exit HTML?

Once hamelito was capable enough, we converted our application to use hamelito and haml templates. The actual conversion took exactly four key-strokes and a mouse-click per template¹, thanks to html2haml.heroku.com.

hamelito is still young and I’m sure that throwing more haml documents at it will expose bugs. If you’re curious, please go ahead and try it, I’d be happy for any comments or bug reports.

but was good when experimenting.

copy, paste, click convert, copy, paste ↩