Last night I puzzled through the execution flow of the ClojureScript One sample app. I even took notes while I was doing it.
I have to say ClojureScript One is an impressive achievement. Someone should build “Clojure One” now :)
It was recently pointed out to me that Seesaw’s “amazing and wonderful”, but not still not that friendly for developers with no background in Java or Swing. By coincidence, I was scheduled to give a talk on Seesaw at Ann Arbor’s CraftsmanGuild, so I took the opportunity to try to improve the situation.
I’m usually not a fan of slides, so I did the talk completely in the REPL. The result was, I think, a nice introduction that assumes no Java or Swing knowledge and shows off some of Seesaw’s cool high-level features.
You might want to view it in its native habitat since this dumb fixed-width layout will hide some of the text. Also, depending on your fonts, my lovingly crafted screenshots might look like crap. Sorry about that.
In any case, here it is. Feedback welcome and encouraged.
I promise this is the last VimClojure post for a while.
I get the feeling that my post describing my VimClojure setup is a little too involved, especially for someone that just wants something working quickly. Also, from what I’ve seen on #clojure, there’s some frustration out there. With that in mind, I put together a minimal example configuration with instructions.
So, without further ado, vimclojure-easy.
Feedback welcome.
Last week I had three separate conversations with people about using Clojure’s data structures and concurrency primitives from a language that’s not Clojure. Something about parens or insisting on using a less capable language :)
So, this weekend I played around with using Clojure from Ruby, in particular JRuby. I haven’t done much Ruby in about a year, so I spent most of my time remembering that. Anyway, I ended up with a proof of concept: Familiar. See the readme there. Here’s an example:
That’s it. This gives full access to the clojure.core API including lazy seqs, STM, and all those goodies. Good idea? Idiotic? I don’t know, but it was a fun exercise.
In honor of the release of VimClojure 2.3.0, I’ve updated my post on taming VimClojure. Thankfully, very little has changed in the setup. Cheers.
I want to write briefly (ok, not that briefly) about my understanding of Clojure‘s various “update” functions, in other words, functions that take a function argument, apply it to some value and do something with the result. These include swap!, alter, commute, send, send-off, alter-var-root, update-in, alter-meta!, vary-meta, and probably several more. From here on out, I’ll call a function in this family an update function and the function passed to it a transform function.
Note that update functions are most commonly encountered when using Clojure’s reference types, i.e. vars, refs, atoms, and agents. Their signatures are all very consistent:
(<update-fn> old-state <tranform-fn> & args)
;=> new-state
That they’re so consistent is a testament to the thought that has gone into the design of Clojure’s core API.
Nonetheless, a newcomer to Clojure, overwhelmed by all the other new concepts they’re learning, might find update functions a little confusing. They might find themselves calling reset! a lot because swap! is scary. Of course, if the value passed to reset! (or ref-set) depends on the previous value of the ref, you’ve thrown away all the nice concurrency guarantees that atoms and refs are supposed to give you. For example, the prototypical id generator:
; BADBAD Don't do this!
(defn id-generator []
(let [id (atom 0)]
(fn []
(reset! id (inc @id)))))
Of course, everyone knows to use (swap! id inc) for a canonical example like this, but in the thick of a larger app, feeling like you’re in over your head, it’s easier to make mistakes.
So, learning to read (and write) an update function can take you a long way along the road toward writing more idiomatic Clojure. For someone with an OO background, it might be easier if we mentally re-wrote the signature above like this:
state = transform_fn(state, arg0, arg1, ...);
that is, we’re applying some transformation to the current value of state and storing the value back in state. See, swap! and friends are just a function call in disguise. Their signatures are completely consistent with Clojure’s argument order conventions, but they slightly obscure what’s going on because the state and transform function are switched. This makes sense since state is the important argument, but it took me a little while to realize this and make the mental adjustment.
Once I reached this conclusion, I found writing in a functional style with state transitions much more straightforward.
Note that I find this a useful way to *read* update functions. It’s not a replacement for thinking hard about the semantics of the update function you’re using
Here are some general guidlines that I find helpful:
reset! (and its cousin ref-set) is for exactly what its name says: “reset this atom back to some initial state dammit!” Only use it if you’re resetting your app, or if the new value truly doesn’t depend on the old value. In the latter case, randomly generated values or user input come to mind.
swap! means you just wrote a function that’s harder to test or experiment with at the repl. Besides, a descriptive name is more readable than most anonymous functions.
(dosync) blocks and calls to swap! will be more difficult to reason about than one where the state transitions are localized.
args! I’ve often fallen into the trap of passing an anonymous function when I needed to pass args to my state transition function.
; A contrived example
(def signal (atom :red))
(def transitions { :red :green, :green :yellow, :yellow :red })
(swap! signal #(get transitions %)) ; <- NO
(swap! signal transitions) ; <- YES
and finally, as a wise man once said “functions and data!”
In conclusion, I hope this sheds some light on an area of Clojure that I’ve personally found to require a great deal of mental deprogramming. As I’ve gained confidence with these concepts, my code has been easier to read, easier to test, and easier to reason about. Happy Clojuring.
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.
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:
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:
Cheers and happy Clojuring!
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:
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.
$ 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.