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")
    nil
    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 Swiggy.java something like this:

    ...
    public class Swiggy {
      // Explicitly load the library when this class loads
      static {
        System.loadLibrary("swiggy");
      }
      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]
    42

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))) 
    x))

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 
#'user/jse
"Type: " :cljs/quit " to quit"
ClojureScript:cljs.user> (def something (js* "{x: 100}"))
#<[object Object]>
ClojureScript:cljs.user> (.x something)
100
ClojureScript:cljs.user> (aget something "x")
100
ClojureScript:cljs.user> (aset something "y" 99)
99
ClojureScript:cljs.user> (.y something)
99

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

$ script/repljs 
#'user/jse
"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)")
#<undefined>

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.

Motivation

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.

Solution

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:

    (b/bind 
      ; As the text of the textbox changes ...
      pattern
      ; 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 ...
      (b/tee
        ; The first path sets the color of the text box depending
        ; on whether the regex was valid
        (b/bind 
          (b/transform #(if % "white" "lightcoral")) 
          (b/property pattern :background))
        ; The second path sets the text of the status label
        (b/bind 
          (b/transform #(if % "Ready" "Invalid regex")) 
          status)))

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).

Conclusion

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)))
  root)

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: , ,

JSplitPainInTheAss: A less abominable fix for setDividerLocation

June 12th, 2011 9 comments

Update: Some discussion of this idea and code updates are in the gist here. Hubris.

If you use Swing much there will come a time when you’d like to create a splitter, aka JSplitPane. Overall, it works fine, but it has one lame, lame, lame feature; if you want to set the divider’s initial position proportionally, you’re screwed. I say feature, because the documentation for JSplitPane.setDividerLocation clearly states that it won’t work if the component hasn’t been “displayed” yet.

I bet that 95% of the time the programmer using this function is calling it at start-up before anything is displayed. Way to cover the 5% case there.

Anyway, you’ll go to Google and try to find a solution to this problem and you’ll find a lot of discussion and many variations on the same workaround. But they inevitably rely on sub-classing (isn’t that the solution to everything in Swing?) and hacking in some logic to fix things right before the splitter gets painted the first time. Nasty.

I’ve been thinking about this in terms of Seesaw, a Clojure/Swing API I’ve been working on. I want setDividerLocation to cover the 95% case and I don’t want to sub-class anything if I can help it. It’s not composable. So I thought about it a bit and came up with a much more elegant solution that works on a vanilla JSplitPane. Since I think this will be much more interesting to the Java Swing developers toiling away out there, I’ve coded it in pure Java. Here it is, a simple function:

If you can’t see any code, look here.

By the way, this code is insanely shorter in Clojure. Just sayin’.

The basic idea is to keep putting off the call to setDividerLocation using invokeLater until the splitter is realized on the screen. No fuss, no muss. … strike that. The invokeLater approach did indeed work, but under certain circumstances, a split pane that wasn’t displayed very soon would result in an infinite cascade of invokeLater events. The main problem with this is that the processor never gets to sleep, etc, etc. So I came up with an alternate approach which takes advantage of a HierarchyChange event to detect when the split pane is displayed (learn something new every day) optionally followed by a resize listener because the hierarchy event may arrive before the split pane’s been laid out by its parent. Swing’s exhausting.

Cheers!

Categories: java, swing 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) {
    super(text);
  }
  @Override
  public void paintComponent(Graphics g) {
    super.paintComponent(g);
    final int w = getWidth();
    final int h = getHeight();
    final int d = 5;
    g.setColor(Color.RED);
    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 []
  (flow-panel 
    :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]
  (invoke-later
    (->
      (frame :title "Seesaw (paintable) example"
             :content (content))
      pack!
      show!)))

(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: , ,