Now I'm working on some Swing code and came up with these, which are
obviously going to be useful:
(defmacro do-on-edt [& body]
`(SwingUtilities/invokeLater #(do ~...@body)))
(defmacro get-on-edt [& body]
`(let [ret# (atom nil)]
(SwingUtilities/invokeLater #(reset! ret# [(do ~...@body)]))
(loop []
(let [r# @ret#]
(if r#
(first r#)
(recur))))))
(defmacro future-on-edt [& body]
`(future (get-on-edt ~...@body)))
The do-on-edt macro executes its body on the EDT and returns nil.
The get-on-edt macro does similarly, but returns whatever the body
returns. It blocks until the body has returned, though, which you may
not want, though since it executes on the EDT it should execute fast.
The future-on-edt macro avoids this blocking behavior. It behaves as
if you scheduled its body to run as a future on the EDT instead of on
whatever thread(s) futures usually run on. In actual fact, the future
it returns is executing the blocking get-on-edt. :)
Action listener code can assume it will run on the edt, but plenty of
other things do not; notably, REPL expressions do not, as well as
anything explicitly launched into another thread and anything executed
as a result of load-file or via a main class.
This code, which I offer to the public domain, also furnishes some
simple examples of macro design, as well as of the use of an atom to
move information between threads, plus a recurrence of the one-cell-
vector idiom for having both nil and "meta-nil", distinguishing not-
set-yet from actually-returned-nil. This also showed up in super-lazy-
seq where ultimately one var could end up holding either a boxed
return value or *two* out-of-band values, nil and :skip. (Another
trick for returning out-of-band values is to return a two-element
vector with a value in one cell and an accompanying bit of meta-data
in the other, for example [item found] distinguishing [nil false] from
[nil true]. Other lisps admit of the same trick, using a cons cell
(item . found) for instance, or using nil vs. (item . nil) or any-atom
vs. (item . nil). Don't know if anyone else here is familiar with
dotted-pair notation though, except clojure's author.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
