Archive for the ‘clojure’ Category

On Clojure, Swig, and the UnsatisfiedLinkError

September 16th, 2011 3 comments

This week I did some Clojure work with a swigged-up C++ library that works great from Java. I was surprised when things didn’t go as smoothly in Clojure. In particular, loading native libraries in the REPL doesn’t seem to work. I’m writing this down in case someone else has the same problem in hopes that it’ll save them an hour or two of head-scratching and library path fiddling.

So, to set the stage, let’s make a tiny Swig library, compile it and try using it from the REPL. I’m using Leiningen just to save some time:

    $ lein new swiggy
    $ cd swiggy
    $ cat >swiggy.i <<EOF
    > %module Swiggy
    > %{
    >   int get_something() { return 42; }
    > %}
    > int get_something();
    > EOF
    $ swig -java -package swiggy -outdir src/swiggy swiggy.i
    $ gcc -I$JAVA_HOME/include -L$JAVA_HOME/lib -shared swiggy_wrap.c -o libswiggy.dylib
    $ javac src/swiggy/Swiggy*.java
    $ export JAVA_OPTS="-Djava.library.path=. -verbose:jni"
    $ lein repl
    ... snipped tons of irrelevant -verbose:jni output ...
    user=> (System/loadLibrary "swiggy")
    user=> (swiggy.Swiggy/get_something)
    java.lang.UnsatisfiedLinkError: swiggy.SwiggyJNI.get_something()I (NO_SOURCE_FILE:0)

That’s interesting. libswiggy.dylib loaded happily and yet there’s an UnsatisfiedLinkError. The thing to note here is that it’s complaining about linking the get_something() method, not the library itself. That’s unexpected. Also note that I have the -verbose:jni flag set, but nothing was printed about linking the method to the backing native code in the library. hmmm.

So, I googled. And found a couple references to this problem without real solutions. Unfortunately, the usual reaction to this problem is immediately “Did you set LD_LIBRARY_PATH and java.library.path?” The exception is the same and that’s normally the problem in Java. It turns out that putting the loadLibrary() call within a Java class that’s loaded by Clojure is enough to trick the system into correctly linking the native method. That is, edit something like this:

    public class Swiggy {
      // Explicitly load the library when this class loads
      static {
      public static int get_something() {
        return SwiggyJNI.get_something();

then recompile and give it another try:

    $ javac src/swiggy/Swiggy*.java
    $ lein repl
    user=> (swiggy.Swiggy/get_something)
    [Dynamic-linking native method swiggy.SwiggyJNI.get_something ... JNI]

That’s better. Does anyone know what causes this? Is it related to the classloader used by the repl or something?

If your in the situation where you can’t or don’t want to modify the swig interface file to include this change, all is not lost. Simply create your own dummy Java class with the loadLibrary call and reference it from Clojure. You can even use Leiningen’s :java-source-path property to get it to auto-compile it for you. I suppose gen-class should also work, but the Java’s pretty trivial.

Categories: clojure Tags: , , ,

Briefly, the “arity-reduce” pattern in Clojure

August 20th, 2011 4 comments

Update: As noted on Reddit, this pattern, as usual, is both old and well-known: induction or structural induction. Duh. :)

Update2:: Or catemorphism perhaps (see comments).

I think it’s a good policy to read as much source code as I write. Writing code will make you better, and you’ll even stumble across some genuinely good approaches to software. However, it’s hard to compete with closely studying other people’s code. With that in mind, I’ve been learning Clojure since late last year and making a point to read the source code for the standard library regularly. It’s really great code and I guess it’s idiomatic Clojure pretty much by definition (with the exception of some of the core preamble).

While exploring Clojure, there’s a pattern that I’ve encountered which I’ll call the “arity-reduce” pattern. If it has an official name, I’m not aware of it. In any case, I’ve seen it many times, but never seen it called out in books or blogs. It came up again today in a 4clojure problem so I figured I’d write it down.

To motivate things, let’s image we’re implementing clojure.core/max, which takes one or more numeric arguments and returns their maximum value. Here’s how I might have approached it when I started learning Clojure:

(defn my-max [x & more] 
  (if more 
    (let [y (first more)] 
      (recur (if (> x y) x y) (next more))) 

This works, but the meaning of the what we’re trying to accomplish is lost in the details of the implementation. Here’s the official implementation:

(defn max
  "Returns the greatest of the nums."
  {:added "1.0"}
  ([x] x)
  ([x y] (if (> x y) x y))
  ([x y & more]
   (reduce max (max x y) more)))

Note how nice and declarative this is. It basically describes the solution to the problem:

  • Given a single argument, return it
  • Given two arguments, return the greater
  • Given more arguments, take the max of the first two args, rinse and repeat.

Maybe I’m slow, but for me, this was an eye-opener. With Clojure I’ve had to learn that whenever I write an anonymous function for use in map or reduce, I should ponder whether a built-in function that does what I need already exists (this is especially true with using sets, maps, and keywords as functions). Similarly, I should always ask my self if multiple arities of the same function would be clearer than jamming the whole implementation into one.

Here are some places where this pattern is used in Clojure:

And a few more that are made clearer by multi-arity definitions although they don’t explicitly use reduce in the “more” case:

  • <, >, and the rest of the comparison functions
  • and
  • or
  • The .., ->, and ->> threading macros

Cheers and happy Clojuring!

Categories: clojure Tags:

Dorothy: Graphviz from the comfort of Clojure

August 12th, 2011 2 comments

I’ve used Graphviz quite a bit in the past. When I did, I was almost always generating dot files from code; I never wrote them by hand other than to experiment with various Graphviz features. Well, string-slinging is a pain. Generating one language from another is a pain. So, inspired by Hiccup, I threw together Dorothy over the last couple evenings. It’s a Clojure DSL for generating DOT graph representations as well as rendering them to images.

For a few hours work, the documentation is pretty thorough, so I’ll leave off with one simple example which is translated from the Entity Relationship example in the Graphviz gallery. Any feedback or criticism is welcome and encouraged.

and here it is displayed in Dorothy’s simple built-in viewer:

Entity Relationship graph

Categories: clojure Tags: ,

I did a bad thing with ClojureScript

July 20th, 2011 2 comments

UPDATE: Don’t do this. It’s a joke and (js*) is an internal detail of ClojureScript. If you need to access native code, access it through the js namespace.

Tonight ClojureScript was announced and made available. I’m interested in how JavaScript interop works for environments like node.js, CouchDB, etc. So far, it seems like (js*) is the main entry point to JavaScript land and functions like (aset) can also be used:

$ script/repljs 
"Type: " :cljs/quit " to quit"
ClojureScript:cljs.user> (def something (js* "{x: 100}"))
#<[object Object]>
ClojureScript:cljs.user> (.x something)
ClojureScript:cljs.user> (aget something "x")
ClojureScript:cljs.user> (aset something "y" 99)
ClojureScript:cljs.user> (.y something)

It happens that repljs (the ClojureScript repl) runs in Rhino which is ripe for abuse:

$ script/repljs 
"Type: " :cljs/quit " to quit"
ClojureScript:cljs.user> (def f 
  (js* "new Packages.javax.swing.JFrame(\"ClojureScript!!\")"))
#<javax.swing.JFrame ... >
ClojureScript:cljs.user> (js* "~{f}.setVisible(true)")

Yes. I am a bad person. I will try to do something useful with ClojureScript shortly.

Also note the interpolation syntax, ~{f}, for referring to Clojure bindings in JavaScript.

Categories: clojure Tags: ,

Seesaw Widget Binding

July 11th, 2011 8 comments

Lately I’ve been working on the problem of binding widgets and widgets (and data) together in Seesaw. I think it’s in a state to throw it out there and solicit feedback from anyone who’s interested. This work is similar to the arrow work done in Hafni, but takes a somewhat different approach and builds on top of the pretty extensive infrastructure that’s already in place in Seesaw.

The full source the for example shown here is here.


Let’s say you were creating a search box where the user can enter a regular expression. You’d like to give some feedback whether the expression is valid or not, say by turning the text box red and updating a status label. Additionally, you’d like an “enabled” checkbox which enables or disables the search. Yeah, it’s contrived, deal with it :)

So, the usual approach would be something like this:

  • Set up the widgets
  • Add a selection change listener to the check box. When it fires, check its value and set the enablement of the search box
  • Add a document change listener to the text box. When it fires, parse the regex, set the color of the text box and update the status label appropriately

Not horrible, but kind of a hassle. If you turn your head and squint, you can kind of see a couple data flows going on here. First, the boolean value of the checkbox flows to the boolean enablement of the searchbox. Second, the text of the search box is transformed into a regex and then into a color (or status label) depending on success of failure. That color is then fed into the background color of the search box.

Seesaw’s binding (from Java Beans Binding, better names welcome) framework let’s you express this dataflow more directly.


So, the framework’s workhorse function is (seesaw.bind/bind). It takes a list of “Bindables” (see below) and hooks their values together into a chain. When a value at the start of a chain changes, it’s passed through the rest of the chain. bind returns a composite Bindable which can be composed into other chains.

So, for example, we can bind the value of a text box to an atom:

  (let [txt (text)
        a   (atom)]
    (bind txt a))

when the user types in the text box, the atom’s value changes to match it. There are several bindables already supported:

  • Text boxes, labels, sliders, atoms, etc are all bindable in the way you (or at least I) would expect.
  • (property widget property-name) – bind to a property of a widget
  • (selection widget) – bind to the current selection of a widget
  • (transform f) – transform a value with a function and pass it along
  • (some pred) – like (clojure.core/some) only pass along truthy values returned by a predicate.
  • (tee ... bindables ...) – split (demux) the chain into several independent chains.

Now back to our example. Here’s the annotated code for binding the search pattern logic. Here pattern is a text box, and status is a label:

      ; As the text of the textbox changes ...
      ; Convert it to a regex, or nil if it's invalid
      (b/transform #(try (re-pattern %) (catch Exception e nil)))
      ; Now tee into two chains ...
        ; The first path sets the color of the text box depending
        ; on whether the regex was valid
          (b/transform #(if % "white" "lightcoral")) 
          (b/property pattern :background))
        ; The second path sets the text of the status label
          (b/transform #(if % "Ready" "Invalid regex")) 

Kinda cool? Similarly, we can hook a checkbox to the textbox enablement:

    (b/bind (b/selection (select f [:#enable]))
            (b/property  (select f [:#search]) :enabled?))

In this example, we’re using Seesaw selectors to find the checkbox (:#enable) and search text box (:#search).


I think this covers a lot of the tedious UI state management tasks that come up. Although atom binding is supported, it doesn’t seem like something you want to be doing often. It’s just doesn’t seem Clojure-y to me. Maybe a bindable atom that works more like (clojure.core/swap!) than (clojure.core/reset!) would be more appealing.

I’m looking for feedback, so if you find this interesting, useful, or offensive, please let me know!

Categories: clojure, seesaw Tags: ,

Ad Hoc Stylesheets in Seesaw

June 22nd, 2011 2 comments

Following up on my last post, I decided to try that distributed pi calculation in Clojure. That’s not going so great, mostly due to my own weak sauce. Luckily, it’s not the subject of this post.

While I was doing that, I kind of got sidetracked into making a little UI that shows the estimate for pi over time, using Seesaw of course. As I fiddled with the look (UIs are such a timehole), I realized I already had the building blocks for rudimentary stylesheet support. I wrote a simple function that iterates over a map (the “stylesheet”), looks up widgets with selectors, and then applies styling using the seeseaw.core/config! function:

(defn apply-stylesheet [root stylesheet]
  (doseq [[sel style] stylesheet]
    (apply config! (select root sel) (reduce concat style)))

The end result was a nice separation of style from structure with only four lines of code.

Yes, it’s still ugly, but I never claimed to be a designer :)

Here’s the full code which uses Seesaw 1.0.7. Note that I can style classes of widgets (e.g. JButton) as well as individual widgets by id.

If you see no code, look here

Note that I’ve omitted my abomination of a pi calculation. The Clojure mailing list will probably hear from me shortly :)

Categories: clojure, seesaw Tags:

Clojure and Akka: A match made in …

June 15th, 2011 2 comments

Akka has been in the news lately. It’s an actor framework, STM, etc rolled into one and generally joined at the hip with Scala. Despite that, it does have a Java API, so after seeing an interesting Akka talk by Nilanjan Raychaudhuri at Detroit Cloud Dev Day over the weekend, I thought I’d try using it from Clojure. Why? Because it’s there!

Source code for everything here can be found on github

Now, Clojure already has pretty equivalent concurrency constructs built into the language, so the utility of this little adventure is a little suspect. But Clojure’s constructs are strictly local, so Akka’s support for distributed actors keeps it interesting (*).

Anyway, after an evening with Clojure and Akka, I have to say they weren’t made for each other. I decided to do a straight port of the Java-based Pi calculation example from the Akka tutorial. I figured porting from Java to Clojure would be simpler than Scala to Clojure. It turns out that Akka, at least in the example, makes heavy use of sub-classing and further more the class literals of those sub-classes. In particular, you need a class literal to create a new instance of an actor. You can’t just “new it up” on your own. Now, Clojure has (proxy) which will let you extend Java classes just fine, but it creates a new instance of an anonymous class. It doesn’t really give you a class to work with. There’s also (gen-class), but I wanted to see if I could avoid that for the time being.

As luck would have it, Akka also supports actor factories in addition to the class literal approach, so I was able to add an additional layer of proxy fun and get the effect I wanted. Wrap it in a macro and you get something like this:

(defactor worker [] []
  (onReceive [work]
    (let [result (calculate-pi-for (:start work) (:num-elements work))]
      (.. this getContext (replyUnsafe (Result. result))))))

and then use it like this:

(make-actor worker)

Not beautiful by any stretch, but ok for an evening experiment.

One interesting “feature” of Akka that I stumbled upon is an error message like this:

You can not create an instance of an actor explicitly using 'new MyActor'.
You have to use one of the factory methods in the 'Actor' object to create a new actor.
Either use:
'val actor = Actor.actorOf[MyActor]', or
'val actor = Actor.actorOf(new MyActor(..))' 

Well, I was using factories throughout, but it turns out that the way this is enforced is with a thread local “current actor under construction” variable which apparently doesn’t play nicely if actor creation is nested within factories. Once I flattened out my actor creation, the error went away. Here’s the output from a run (full of warnings because I didn’t bother with actually installing Akka and just used Maven to get the jars):

61 [21:29:42] [~/Documents/projects/clojak]$ lein run -m clojak.pi
Can't load 'akka.conf'.
One of the three ways of locating the 'akka.conf' file needs to be defined:
        1. Define the '-Dakka.config=...' system property option.
        2. Put the 'akka.conf' file on the classpath.
        3. Define 'AKKA_HOME' environment variable pointing to the root of the Akka distribution.
I have no way of finding the 'akka.conf' configuration file.
Using default values everywhere.
        Pi estimate:             3.1435501812459323
        Calculation time:        11841 millis

In conclusion, here are my observations from this experience:

  • My conversion of the PI calculation function to Clojure is an unreadable atrocity.
  • It’s probably worth investigating why this is more than 10x slower than the sample output in the tutorial.
  • (*) Although I got it working with actor factories, this evidently makes distributing the actors difficult/impossible, which kind of eliminates any benefit that Akka would bring to Clojure.
  • By resorting to (gen-class), I should be able to generate “real” classes in Clojure for use by Akka. A simple stubbed implementation that delegates to a map of functions should make it pretty easy to use. I did something similar in Seesaw’s nascent applet support.
  • Clojure’s Java interop is generally awesome, but it works better with some API styles than others.

There’s a good chance that I just don’t know what I’m doing, so feel free to correct any egregious mistakes.

Ok. That’s it. Source code’s here.

Categories: clojure Tags: , ,

Painting Widgets with Seesaw

June 10th, 2011 1 comment

The functionality describe here will be in the 1.0.7 release of Seesaw in the next week or so.

Say for some reason, you want a label with a red X on it. A bad, bad label. If you’re working with Swing in Java, you’ll create a new class, extend JLabel, override paintComponent, make some drawing calls, etc. Not terrible, but not that fun either. Something like this:

public class BadLabel extends JLabel {
  public BadLabel(String text) {
  public void paintComponent(Graphics g) {
    final int w = getWidth();
    final int h = getHeight();
    final int d = 5;
    g.drawLine(d, d, w - d, h - d);
    g.drawLine(w-d, d, d, h - d); 

That’s pretty minimal if we ignore imports and stuff. Enabling anti-aliasing would be nice. It’d also be nice to set the width of the lines. And if you wanted to draw the X on a button or something else, you could pull all the drawing code into a function, but you couldn’t avoid a new, possibly anonymous, class for each type of component you want to use it on.

In Seesaw, we use the paintable macro to do all the dirty work for us. Give it a function to handle the painting and a description of the widget you want, and you’re done. It handles anti-aliasing and there’s functions that make styling the lines a little less tedious.

Below is the equivalent Clojure code using Seesaw. Note that here we can easily apply the red X to a label or a button. Of course this also puts the widgets in a frame and displays them too. I’ll spare you that part in Java :)

The code for this example is also here.

(ns seesaw.examples.paintable
  (:use [seesaw core graphics]))

(defn draw-a-red-x 
  "Draw a red X on a widget with the given graphics context"
  [c g]
  (let [w          (width c)
        h          (height c)
        line-style (style :foreground "#FF0000" :stroke 3 :cap :round)
        d 5]
    (draw g
      (line d d (- w d) (- h d)) line-style
      (line (- w d) d d (- h d)) line-style)))

(defn content []
    :border 5
    :items [
      (label           :text "I'm a good label!" :font "ARIAL-BOLD-40" :foreground "#00AA00")
      ; *** Make a label and button with a red X on them ***
      (paintable label :text "I'm a bad label!"  :font "ARIAL-BOLD-40" 
                              :paint draw-a-red-x)
      (paintable button :text "I'm a bad button!"  :font "ARIAL-BOLD-40"
                                :paint draw-a-red-x)]))

(defn -main [& args]
      (frame :title "Seesaw (paintable) example"
             :content (content))

(paintable) is still a macro so it comes with all the limitations associated with them. Unfortunately with Swing you have to sub-class to paint on a widget and in Clojure you can’t (as far as I know) sub-class at run-time.

Categories: clojure, seesaw, swing Tags: , ,

A Brief Note on Seesaw Selectors

June 8th, 2011 No comments

Just wanted to note that I finally got around to a full implementation of CSS-style selectors in Seesaw, the Clojure UI library I’ve been working on. The updated doc for the (seesaw.core/select) function has most of the details, but here are a couple examples:

      ; All JLabels, no sub-classes allowed
      (select root [:<javax.swing.JLabel!>])

      ; All JSliders that are descendants of a JPanel with id foo
      (select root [:JPanel#foo :JSlider])

      ; All JSliders (and sub-classes) that are immediate children of a
      ; JPanel with id foo
      (select root [:JPanel#foo :> :<javax.swing.JSlider>])

To implement the selectors, I hacked up the zipper-based selector code in the very cool Enlive project. It was surprisingly straightforward:

  • Modify zipper construction to create a zipper over a Swing widget hierarchy instead of an HTML doc
  • Hack up the parser a little bit to allow my Java-class-matching extensions
  • Update the predicate sets to work on widgets instead of DOM nodes

Hats off to Christophe Grand for writing such a well-factored piece of Clojure code that I could get this working in an evening.

I’ll write more (like what this could be useful for) when it’s not the middle of the night.

p.s. this will be in the 1.0.6 release on Clojars sometime this week after I beat on it a bit more.

Categories: clojure, seesaw, swing Tags: , ,

Nice Weather for Some Clojure (UIs)

May 24th, 2011 9 comments

Summary: I tried build something slightly non-trivial with Seesaw and learned some things.

And so it came to pass that it seemed like I needed to start dog-fooding Seesaw a bit. I’ve been steadily adding features and building tiny toy apps to demonstrate them. Others (and others) have apparently found it useful, but I haven’t tried anything myself.

So, I decided to write Gaidica, a little app that displays weather info for user-selected cities. The whole process wasn’t terrible, but shows that there’s work to do. I’d guess about 4 hours of work including fixing Seesaw bugs as I hit them and at least an hour puzzling over Clojure XML stuff. Here’s a screenshot of the forecasts:

The code is all available on github.


Just to make sure we’re on the same page, Seesaw is an API/DSL for building user interfaces in Clojure. It happens to be built on Swing as you’ll see below, but please don’t judge it too harshly. I’m working hard to make it so you never need to know that Swing’s even there.

The Data

I decided to use Weather Underground’s XML API for the data. It provides the data in a simple format and as a bonus, includes icons for weather conditions, which saved me some work. Additionally, I got to do some XML wrangling in Clojure. Let’s just say that that deserves a blog post of its own.

In any case, I just point Clojure’s (xml/parse) function at the URL and get back some results. All this is done in a background thread using (future) to keep the UI responsive.

The Good

I mostly want to focus on the bad in this post, but despite any difficulties I had, building this was more enjoyable in Clojure+Seesaw than the equivalent Clojure+Swing or raw Java code. The lack of (proxy) and (reify) usage is testament to that.

Seesaw’s table support, seen in the webcam tab below, really paid off. Compared to the equivalent JTable-wrangling you’d have to do, it was downright dreamy.

Here’s the code to create that table:

(defn make-webcam-table [] 
    :id :webcam-table 
        [{:key :handle :text "Name" } 
         :lat :lon 
         {:key :updated :text "Last Updated"}
         {:key :image :text "Image"}]]))

The Bad

I learned a lot during this exercise. One thing I noticed is that Swing is a pain in the ass. I think when you’re in the depths of a Java-based Swing app, you don’t even notice it because you’re already so mired in Java verbosity. It’s a form of Stockholm Syndrome I guess.

Most of the pain centered around, you guessed it, layout. I wanted to do it with the vanilla Swing layouts provided by Seesaw (border-panel, vertical-panel, etc), but after fiddling with component alignments and lame resize problems, I eventually surrendered and ran back to MigLayout. It’s powerful and pretty easy to use, but it’s yet another little language to learn. Luckily Seesaw already has Mig support.

Otherwise, most of the other issues I had were just missing functionality. Swing methods not yet wrapped by Seesaw. The nice thing is that since Seesaw’s a fairly thin wrapper, it’s easy to drop down to raw Swing when needed. Some random functionality that I’m going to address as a result:

  • Manipulation of the widget hierarchy needs to be seamless. This has historically been a problem in Swing (invalidate(); revalidate(); repaint()!!)
  • Widget styling. Sprinkling fonts and colors throughout the code is a hassle. The main question is whether I just add convenience options for this, or go whole hog and try for a CSS-style styling.
  • Saner defaults for “vanilla” layouts. I think I can tune some of the defaults and add some dials to make it less frustrating. It still really bugs me that I had to use Mig for something so simple.


From the perspective of a potential Seesaw user, already suspicious of Swing, all of this is a problem. I’ll take it as a challenge to continue making Seesaw a buffer between them and the occasional craziness of Swing. Feedback welcome!

Categories: clojure, seesaw, swing Tags: , ,