In this (http://vimeo.com/14709925) video dude edits running program that renders opengl stuff in a loop.
When i run this:
(def a 10)
(defn myloop
[]
(while (= 1 1)
(println a)
(Thread/sleep 1000)))
(myloop)
then change value of a, re eval does nothing, value doesn't seem to change. I'm using LightTable IDE. Should i switch to emacs?
One possibility is that the re-evaluation isn't taking place because it is done on the same thread as the running program. Try running myloop in another thread instead with (future (myloop)) instead of (myloop) and then re-def your a after a few prints and see if it changes.
Note that (in current Clojure versions) all vars are dereferenced each time they are encountered, which allows for this dynamic behavior, but re-def-ing except during interactive testing/experimentation/demonstration is frowned upon. See atoms and refs.
Another consequence of this behavior of vars is that dereferencing can impact the efficiency of performance critical tight loops. Where the dynamic behavior is not needed you might see the following idiom to capture the value first (note you shouldn't attempt pre-optimazation in general until bottlenecks are identified).
(def foo 42)
(let [foo foo] ; capture value of foo within scope of let
(loop ...
; do something with value of foo captured before entering loop
... ))
I know this isn't a direct answer to your question - but if you want to mutate state in this way in Clojure, I think it is probably more idiomatic to use one of the constructs for state manipulation (for example, an atom) rather than re-evaluating a def.
This is especially true if you're likely to need multiple threads, which might well be the case if you're working with graphics.
(def a (atom 10))
(defn myloop []
(while (= 1 1)
(println #a)
(Thread/sleep 1000)))
(myloop)
(reset! a 9)
Related
What is the simplest way to trigger a side-effecting function to be called only when an atom's value changes?
If I were using a ref, I think I could just do this:
(defn transform-item [x] ...)
(defn do-side-effect-on-change [] nil)
(def my-ref (ref ...))
(when (dosync (let [old-value #my-ref
_ (alter! my-ref transform-item)
new-value #my-ref]
(not= old-value new-value)))
(do-side-effect-on-change))
But this seems seems a bit roundabout, since I'm using a ref even though I am not trying to coordinate changes across multiple refs. Essentially I am using it just to conveniently access the old and new value within a successful transaction.
I feel like I should be able to use an atom instead. Is there a solution simpler than this?
(def my-atom (atom ...))
(let [watch-key ::side-effect-watch
watch-fn (fn [_ _ old-value new-value]
(when (not= old-value new-value)
(do-side-effect-on-change)))]
(add-watch my-atom watch-key watch-fn)
(swap! my-atom transform-item)
(remove-watch watch-key))
This also seems roundabout, because I am adding and removing the watch around every call to swap!. But I need this, because I don't want a watch hanging around that causes the side-effecting function to be triggered when other code modifies the atom.
It is important that the side-effecting function be called exactly once per mutation to the atom, and only when the transform function transform-item actually returns a new value. Sometimes it will return the old value, yielding new change.
(when (not= #a (swap! a transform))
(do-side-effect))
But you should be very clear about what concurrency semantics you need. For example another thread may modify the atom between reading it and swapping it:
a = 1
Thread 1 reads a as 1
Thread 2 modifies a to 2
Thread 1 swaps a from 2 to 2
Thread 1 determines 1 != 2 and calls do-side-effect
It is not clear to me from the question whether this is desirable or not desirable. If you do not want this behavior, then an atom just will not do the job unless you introduce concurrency control with a lock.
Seeing as you started with a ref and asked about an atom, I think you have probably given some thought to concurrency already. It seems like from your description the ref approach is better:
(when (dosync (not= #r (alter r transform))
(do-side-effect))
Is there a reason you don't like your ref solution?
If the answer is "because I don't have concurrency" Then I would encourage you to use a ref anyway. There isn't really a downside to it, and it makes your semantics explicit. IMO programs tend to grow and to a point where concurrency exists, and Clojure is really great at being explicit about what should happen when it exists. (For example oh I'm just calculating stuff, oh I'm just exposing this stuff as a web service now, oh now I'm concurrent).
In any case, bear in mind that functions like alter and swap! return the value, so you can make use of this for concise expressions.
I'm running into the same situation and just come up 2 solutions.
state field :changed?
Keeping a meanless :changed mark in atom to track swap function. And take the return value of swap! to see if things changed. For example:
(defn data (atom {:value 0 :changed? false}))
(let [{changed? :changed?} (swap! data (fn [data] (if (change?)
{:value 1 :changed? true}
{:value 0 :change? false})))]
(when changed? (do-your-task)))
exception based
You can throw an Exception in swap function, and catch it outside:
(try
(swap! data (fn [d] (if (changed?) d2 (ex-info "unchanged" {})))
(do-your-task)
(catch Exception _
))
I'm trying to reproduce pitfalls of dynamic vars described by Chas - http://cemerick.com/2009/11/03/be-mindful-of-clojures-binding/.
Consider the following snippet:
(def ^:dynamic *dynamic-x* 10)
(defn adder [arg]
(+ *dynamic-x* arg))
(adder 5) ;; returns 15
(binding [*dynamic-x* 20]
(adder 5)) ;; returns 25
(binding [*dynamic-x* 20]
#(future (adder 5))) ;; returns 25 (!)
Actually, I was expecting that 3rd case will return 15, as soon as adding is performed on the separate thread and current thread local value of *dynamic-x* (which I supposed to be 10) should be used. But, unexpectedly for me, it returns 25.
Where am I wrong?
It is the design of future that the dynamic bindings are passed to the other threads in which the future body will be executed (Look into the source of future, which defers to future-call, which uses a function called binding-conveyor-fn which explicitly copies the thread-local bindings).
The motivation for this IMO is that when using future you want to run your computation in the same "logical thread", only you're actually doing it in another Java Thread for performance reasons.
I agree it would deserve to be explicitly documented :)
I began learning Clojure today and I ran into a problem that I would not solve with cleaver Googeling.
I have a simple script where I'd like to increase a counter when a condition is met. I've learned that variables are immutble in Clojure and the way around increasing this is to redeclear it, however this throws a warning.
(defn main[]
(def num 0)
(if [...]
(def num (+ num 1))
)
)
However this throws the following warning:
WARNING: num already refers to: #'clojure.core/num in namespace: user, being replaced by: #'user/num
There are two problems here:
One, you are shadowing a function in clojure.core. This gets a warning because it can lead to unexpected behavior. If you know you won't be using clojure.core/num, you can include the following in your namespace declaration:
(ns my.ns
(:refer-clojure :exclude [num])
....)
Next problem: def is not for creating local values. Using def as anything other than a top level form is almost always a mistake, and any exceptions to this should require very explicit justification. It can only create global mutable vars. Use let for bindings that are specific to one scope, like inside a function.
(defn -main
[& args]
(let [num 0
num (if ... num (inc num))]
...))
Here, num is not mutated, and not created as a global var, but it is a local binding that is shadowed by the second binding.
Short Version:
In Clojure there are special abstractions to represent something that changes over time. The simplest one is called an atom. You start the atom with a value 0, and then you change the atom by applying the function inc to its value.
(def n (atom 0))
(def -main
[& [args]]
(if condition
(swap! n inc))
...)
Long Version:
If I understand correctly, you are asking for a way around immutability. This means that you are modelling some concept (i.e. site visitors) that takes different values (i.e 42) over time. Clojure is very opinionated on how to do this and the techniques it offers (STM) are central to the language. The reason Clojure works differently is to make concurrency easier but you do not need to think about to concurrency in order to increment a counter. To understand the rationale behind Clojure I recommend Rich Hickey's talks, in this case The Value of Values.
In trying to replicate some websockets examples I've run into some behavior I don't understand and can't seem to find documentation for. Simplified, here's an example I'm running in lein that's supposed to run a function for every element in a shared map once per second:
(def clients (atom {"a" "b" "c" "d" }))
(def ticker-agent (agent nil))
(defn execute [a]
(println "execute")
(let [ keys (keys #clients) ]
(println "keys= " keys )
(doseq [ x keys ] (println x)))
;(map (fn [k] (println k)) keys)) ;; replace doseq with this?
(Thread/sleep 1000)
(send *agent* execute))
(defn -main [& args]
(send ticker-agent execute)
)
If I run this with map I get
execute
keys= (a c)
execute
keys= (a c)
...
First confusing issue: I understand that I'm likely using map incorrectly because there's no return value, but does that mean the inner println is optimized away? Especially given that if I run this in a repl:
(map #(println %) '(1 2 3))
it works fine?
Second question - if I run this with doseq instead of map I can run into conditions where the execution agent stops (which I'd append here, but am having difficulty isolating/recreating). Clearly there's something I"m missing possibly relating to locking on the maps keyset? I was able to do this even moving the shared map out of an atom. Is there default syncrhonization on the clojure map?
map is lazy. This means that it does not calculate any result until the result is accessed from the data structure it reteruns. This means that it will not run anything if its result is not used.
When you use map from the repl the print stage of the repl accesses the data, which causes any side effects in your mapped function to be invoked. Inside a function, if the return value is not investigated, any side effects in the mapping function will not occur.
You can use doall to force full evaluation of a lazy sequence. You can use dorun if you don't need the result value but want to ensure all side effects are invoked. Also you can use mapv which is not lazy (because vectors are never lazy), and gives you an associative data structure, which is often useful (better random access performance, optimized for appending rather than prepending).
Edit: Regarding the second part of your question (moving this here from a comment).
No, there is nothing about doseq that would hang your execution, try checking the agent-error status of your agent to see if there is some exception, because agents stop executing and stop accepting new tasks by default if they hit an error condition. You can also use set-error-model and set-error-handler! to customize the agent's error handling behavior.
I'm learning about concurrency in Clojure.
I ran into a claim (by Stuart Serra?) at http://dev.clojure.org/display/design/Scheduled+Events, stating:
Clojure functions cannot use time for control flow without blocking or Java interop
Java interop (ScheduledThreadPoolExecutor) is not aware of thread-local bindings
I don't understand these claims and kindly ask for clarification, perhaps an example. Specifically:
What's wrong with ScheduledThreadPoolExecutor as is? Since I'm starting a new (green) thread, I don't expect per-thread bindings to carry over anyway.
I can schedule a normal Clojure function, so what's stopping me to send desired bindings as lexically closed context?
Many thanks!
Ok, I think I got it.
Suppose you try this:
(def pool (atom nil))
(defn- thread-pool []
(or #pool
(reset! pool (ScheduledThreadPoolExecutor. 1))))
(def ^:dynamic *t* 0)
(binding [*t* 1]
(future (println "first example:" *t*)))
(binding [*t* 1]
(.schedule (thread-pool) (fn [] (println "second example:" *t*)) 0
TimeUnit/SECONDS))
(binding [*t* 1]
(.schedule (thread-pool) (bound-fn [] (println "third example:" *t*)) 0
TimeUnit/SECONDS))
The output will be:
first example: 1
second example: 0
third example: 1
In the first case, the future macro wraps the body with the private function binding-conveyor-fn, which preserves the calling thread's bindings frame in the lexical scope, and restores it before calling the wrapped function.
In the third case, bound-fn pushes the calling thread's bindings onto the frame, executes the function body, and pops the bindings.
In the second case, no one saves per-thread bindings - a Java class certainly doesn't know about them, and so we drop to the root value of the t Var.
I hope someone out there finds this interesting.