Been learning some Clojure lately. Just making a simple game with the Quil library where I can move around using the arrow keys, but I ran into a minor (but annoying) problem -- when I hold down an arrow key, my character moves on the screen, but after the first slight movement, there's a delay until the character starts moving again. Once the character starts moving again, the movement is continuous with no problems. Basically what it feels like is that the key being held down isn't being registered by the program for almost a second after the first slight movement. This seems like such a tiny problem but it's very noticeable and annoying. Also I'd like to learn why this happens simply to learn.
By slight movement I mean the key press is instantly registered and the character moves a bit. Also if I keep tapping on the key fast, all the presses are instantly registered and the character moves as you'd expect. The problem only occurs when I hold the key down. Any ideas what could be causing this and how to fix it? Here's the sketch with the :key-pressed handler. Thanks.
(q/defsketch hello-quil
:title "Game"
:size [800 500]
; setup function called only once, during sketch initialization.
:setup setup
; update-state is called on each iteration before draw-state.
:update update-state
:draw draw-state
:key-pressed
(fn [state { :keys [key key-code] }]
(case key
(:up) (if (> (state :p-left) 5) (assoc state :p-left (- (state :p-left) 15)) state)
(:down) (if (< (state :p-left) 395) (assoc state :p-left (+ (state :p-left) 15)) state)
state))
:features [:keep-on-top]
; This sketch uses functional-mode middleware.
; Check quil wiki for more info about middlewares and particularly
; fun-mode.
:middleware [m/fun-mode])
Don't rely on the key event being repeated for you when the key is held down. Use key-released and time in the update functions. Put key-down into your state, set it to true in key-pressed and to false in key-released, then update your character position in update-state when key-down is true.
Related
I'm relatively new to clojure, but have a grasp of the major functional concepts. Something I'm really struggling with is state.
I'm writing a simple card game app, it has come to the point where I'm writing the game engine. So the concept of state has slapped me in the face very quickly.
I need keep track of lots of things pertinent to the game:
The state of the deck
The state of the points
Who was dealer
... ect
I've done reading into how state is used in clojure, Refs, Agents, Atoms, and thread local vars. But none of them seem like the right option for what i'm doing.
So my actual question: What clojure construct do I use to maintain state of a single-threaded game engine in clojure?
A general principle of functional programming is that you can make your code more general by replacing global state with an added input arg and output arg for each function accessing state.
In this case, that would mean providing a game arg to each round of play, and having each round of play return a new game to be used going forward. There are a few advantages to this. There is no mutation, so there is no need to manage and coordinate mutation. Your tests can consist of running one turn of the round of play function. If you need AI, it can trivially run many branching turns of the game on a breadth-first basis to test likely outcomes without interfering with the state of the actual game.
A rough sketch of what this could look like:
(def make-game
[players]
(let [[draw & deck] (shuffle cards)]
{:draw draw
:deck deck
:points (zipmap players (repeat 0))
:dealer (first players)})
(defn run-round
[game]
(let [points (update-points (:draw game) (:points game))
[draw & deck] (:deck game)]
(assoc game :deck deck :draw draw :points points)))
(defn winner?
[game]
(some #(> (val %) 42) (:points game)))
(defn -main
(let [gameplay (take-while #(not (winner? %))
(iterate run-round (make-game)))]
(:points (run-round (last gameplay)))))
This is of course a very trivial game where the points of each player are derived from the card drawn. The next card will be drawn from the shuffled deck on each turn until we have a total score indicating a winner.
It sounds like the state of this game has several components, the deck, points, dealer, etc. so you can choose to put all of this into a single map and store that in one of the uncoordinated mutable data types (atom, agent, var) or store them separately and use the coordinated mutable data type, the ref. Since you say the game is single threaded then it may be slightly easier to go the uncoordinated route to save typing the word dosync a few times, though it won't be a big difference in effort either way.
(def state-of-game (atom {:deck ...
:points
:dealer}))
When I add a watch to a variable in clojure and rebind it, the watch is updated dynamically.
(def x "jlkfds")
x
In the above example x will always reflect its value.
However, when I try and do this using an atom, I have no luck. I have to execute the whole thing again to get the changes to reflect in either the instarepl or the watch.
(defonce y (atom 10))
#y *38*
(swap! y inc) *80*
In the above example I have executed the swap without executing the deref, and they have thus become out of sync.
What confuses me is that I saw a Javascript demo where someone (Chris) was able to watch the coordinates of a mouse pointer dynamically change. I really like the idea of having this functionality. Is there a way to do the same thing in Clojure?
Like this?
http://youtube.com/watch?v=d8-b6QEN-rk
Thank you
Watches are only updated when the thing they are watching is eval'd. Just make sure that you are watching somewhere the watch macro can be eval'd. Try this.
(defonce y (atom 10))
(do //Eval this sexp
(swap! y inc)
#y) //watch this j
I think you are also running into issues with the insta-repl (live mode), periodically it will evaluate the entire page and that is where you are seeing the watches get out of sync. For example, line 1 is evaluated and the atom is created. You add a watch to line 2, evaluating it. You increment the watch with line 3 28 times, then do something that forces line 2 to eval again. This updates the watch to the new value of y. Re-evaluating line 3 doesn't change the watch on line two but it changes the value of y.
I am working on a Clojure / Jetty web service. I have a special url that I want to only be serviced one request at a time. If the url was requested, and before it returns, the url is requested again, I want to immediately return. So in more core.clj, where I defined my routes, I have something like this:
(def work-in-progress (ref false))
Then sometime later
(compojure.core/GET "/myapp/internal/do-work" []
(if #work-in-progress
"Work in Progress please try again later"
(do
(dosync
(ref-set work-in-progress true))
(do-the-work)
(dosync
(ref-set rebuild-in-progress false))
"Job completed Successfully")))
I have tried this on local Jetty server but I seem to be able to hit the url twice and double the work. What is a good pattern / way to implement this in Clojure in a threaded web server environment?
Imagine a following race condition for the solution proposed in the question.
Thread A starts to execute handler's body. #work-in-progress is false, so it enters the do expression. However, before it managed to set the value of work-in-progress to true...
Thread B starts to execute handler's body. #work-in-progress is false, so it enters the do expression.
Now two threads are executing (do-the-work) concurrently. That's not what we want.
To prevent this problem check and set the value of the ref in a dosync transaction.
(compojure.core/GET "/myapp/internal/do-work" []
(if (dosync
(when-not #work-in-progress
(ref-set work-in-progress true)))
(try
(do-the-work)
"Job completed Successfully"
(finally
(dosync
(ref-set work-in-progress false))))
"Work in Progress please try again later"))
Another abstraction which you might find useful in this scenario is an atom and compare-and-set!.
(def work-in-progress (atom false))
(compojure.core/GET "/myapp/internal/do-work" []
(if (compare-and-set! work-in-progress false true)
(try
(do-the-work)
"Job completed Successfully"
(finally
(reset! work-in-progress false)))
"Work in Progress please try again later"))
Actually this is the natural use case for a lock; in particular, a java.util.concurrent.locks.ReentrantLock.
The same pattern came up in my answer to an earlier SO question, Canonical Way to Ensure Only One Instance of a Service Is Running / Starting / Stopping in Clojure?; I'll repeat the relevant piece of code here:
(import java.util.concurrent.locks.ReentrantLock)
(def lock (ReentrantLock.))
(defn start []
(if (.tryLock lock)
(try
(do-stuff)
(finally (.unlock lock)))
(do-other-stuff)))
The tryLock method attempts to acquire the lock, returning true if it succeeds in doing so and false otherwise, not blocking in either case.
Consider queueing the access to the resource as well - in addition to getting an equivalent functionality to that of locks/flags, queues let you observe the resource contention, among other advantages.
I am learning clojure and try out its concurrency and effectiveness via a producer consumer example.
Did that and it felt pretty akward with having to use ref and deref and also watch and unwatch.
I tried to check other code snippet; but is there a better way of re factoring this other than using Java Condition await() and signal() methods along with Java Lock. I did not want to use anything in Java.
here is the code; i guess I would have made many mistakes here with my usage...
;a simple producer class
(ns my.clojure.producer
(:use my.clojure.consumer)
(:gen-class)
)
(def tasklist( ref (list) )) ;this is declared as a global variable; to make this
;mutable we need to use the fn ref
(defn gettasklist[]
(deref tasklist) ;we need to use deref fn to return the task list
)
(def testagent (agent 0)); create an agent
(defn emptytasklist[akey aref old-val new-val]
(doseq [item (gettasklist)]
(println(str "item is") item)
(send testagent consume item)
(send testagent increment item)
)
(. java.lang.Thread sleep 1000)
(dosync ; adding a transaction for this is needed to reset
(remove-watch tasklist "key123"); removing the watch on the tasklist so that it does not
; go to a recursive call
(ref-set tasklist (list ) ) ; we need to make it as a ref to reassign
(println (str "The number of tasks now remaining is=") (count (gettasklist)))
)
(add-watch tasklist "key123" emptytasklist)
)
(add-watch tasklist "key123" emptytasklist)
(defn addtask [task]
(dosync ; adding a transaction for this is needed to refset
;(println (str "The number of tasks before") (count (gettasklist)))
(println (str "Adding a task") task)
(ref-set tasklist (conj (gettasklist) task )) ; we need to make it as a ref to reassign
;(println (str "The number of tasks after") (count (gettasklist)))
)
)
Here is the consumer code
(ns my.clojure.consumer
)
(defn consume[c item]
(println "In the consume method:Item is " c item )
item
)
(defn increment [c n]
(println "parmeters are" c n)
(+ c n)
)
And here is the test code ( I have used maven to run clojure code and used NetBeans to edit as this is more familiar to me coming from Java - folder structure and pom at - https://github.com/alexcpn/clojure-evolve
(ns my.clojure.Testproducer
(:use my.clojure.producer)
(:use clojure.test)
(:gen-class)
)
(deftest test-addandcheck
(addtask 1)
(addtask 2)
(is(= 0 (count (gettasklist))))
(println (str "The number of tasks are") (count (gettasklist)))
)
If anybody can refactor this lightly so that I can read and understand the code then it will be great; Else I guess I will have to learn more
Edit -1
I guess using a global task list and making it available to other functions by de-referencing it (deref) and again making it mutable by ref is not the way in clojure;
So changing the addTask method to directly send the incoming tasks to an agent
(defn addtask [task]
(dosync ; adding a transaction for this is needed to refset
(println (str "Adding a task") task)
;(ref-set tasklist (conj (gettasklist) task )) ; we need to make it as a ref to reassign
(def testagent (agent 0)); create an agent
(send testagent consume task)
(send testagent increment task)
)
However when I tested it
(deftest test-addandcheck
(loop [task 0]
(when ( < task 100)
(addtask task)
(recur (inc task))))
(is(= 0 (count (gettasklist))))
(println (str "The number of tasks are") (count (gettasklist)))
)
after sometime the I am getting Java rejected execution exception -- This is fine if you do Java threads, because you take full control. But from clojure this looks odd, especially since you are not selecting the ThreadPool stratergy yourself
Adding a task 85
Exception in thread "pool-1-thread-4" java.util.concurrent.RejectedExecutionExce
ption
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution
(ThreadPoolExecutor.java:1759)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.jav
a:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.ja
va:658)
at clojure.lang.Agent$Action.execute(Agent.java:56)
at clojure.lang.Agent$Action.doRun(Agent.java:95)
at clojure.lang.Agent$Action.run(Agent.java:106)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:885)Adding a task 86
Adding a task 87
I think modeling producer & consumer in clojure would be done the easiest (and most efficiently) using lamina channels.
I have made similar clojure program with producer/consumer pattern in Computing Folder Sizes Asynchronously.
I don't think that you really need to use Refs.
You have single tasklist that is mutable state that you want to alter synchronously. Changes are relatively quick and do not depend on any other external state, only the variable that comes in to consumer.
As far with atoms there is swap! function which can help you do the changes the way I understood you need.
You can look at my snippet Computing folder size i think it can at least show you proper use of atoms & agents. I played with it a lot, so it should be correct.
Hope it helps!
Regards,
Jan
I was looking at the Clojure examples for Twitter storm. He just used LinkedBlockingQueue. It's easy to use, concurrent and performs well. Sure, it lacks the sex-appeal of an immutable Clojure solution, but it will work well.
I've come across several use cases where I need the ability to:
strictly control the number of worker threads on both the producer and consumer side
control the maximum size of the "work queue" in order to limit memory consumption
detect when all work has been completed so that I can shut down the workers
I've found that the clojure built-in concurrency features (while amazingly simple and useful in their own right) make the first two bullet points difficult. lamina looks great, but I didn't see a way that it would address my particular use cases w/o the same sort of extra plumbing that I'd need to do around an implementation based on BlockingQueue.
So, I ended up hacking together a simple clojure library to try to solve my problems. It is basically just a wrapper around BlockingQueue that attempts to conceal some of the Java constructs and provide a higher-level producer-consumer API. I'm not entirely satisfied with the API yet; it'll likely evolve a bit further... but it's operational:
https://github.com/cprice-puppet/freemarket
Example usage:
(def myproducer (producer producer-work-fn num-workers max-work))
(def myconsumer (consumer myproducer consumer-work-fn num-workers max-results))
(doseq [result (work-queue->seq (:result-queue myconsumer))]
(println result))
Feedback / suggestions / contributions would be welcomed!
How can I create a constantly running background process in Clojure? Is using "future" with a loop that never ends the right way?
You could just start a Thread with a function that runs forever.
(defn forever []
;; do stuff in a loop forever
)
(.start (Thread. forever))
If you don't want the background thread to block process exit, make sure to make it a daemon thread:
(doto
(Thread. forever)
(.setDaemon true)
(.start))
If you want some more finesse you can use the java.util.concurrent.Executors factory to create an ExecutorService. This makes it easy to create pools of threads, use custom thread factories, custom incoming queues, etc.
The claypoole lib wraps some of the work execution stuff up into a more clojure-friendly api if that's what you're angling towards.
My simple higher-order infinite loop function (using futures):
(def counter (atom 1))
(defn infinite-loop [function]
(function)
(future (infinite-loop function))
nil)
;; note the nil above is necessary to avoid overflowing the stack with futures...
(infinite-loop
#(do
(Thread/sleep 1000)
(swap! counter inc)))
;; wait half a minute....
#counter
=> 31
I strongly recommend using an atom or one of Clojures other reference types to store results (as per the counter in the example above).
With a bit of tweaking you could also use this approach to start/stop/pause the process in a thread-safe manner (e.g. test a flag to see if (function) should be executed in each iteration of the loop).
Maybe, or perhaps Lein-daemon? https://github.com/arohner/lein-daemon