Curiouser and curiouser. I turns out the problem was *not* with my next-to-play function but rather with the fact that it takes three arguments but I was only passing it two.
The curious part is that whilst the compiler complained about the wrong arity if I evaluated the call directly, it didn't when it was part of a let! (let [next-player (next-to-play @current-board player)]... should be: (let [next-player (next-to-play @current-board player false)]... But the compiler doesn't complain! On Tuesday, July 15, 2014 7:06:36 AM UTC+1, edw...@kenworthy.info wrote: > > Quick follow up, replacing get-and-make-move with > > (defn get-and-make-move > [board strategy player] > board) > > Still have the same problem: so the issue is not with that function nor > any of the functions it calls (nor the strategies). > > Beginning to think it's my next-to-play function, which would be weird as, > again, it works in the single threaded command line version. > > > > > On Tuesday, July 15, 2014 6:41:05 AM UTC+1, edw...@kenworthy.info wrote: >> >> Pretty sure the strategy isn't a problem (random-strategy picks a random >> move from all legal moves) and it works in the single-threaded command line >> version of the app. >> >> ditto all-directions which is constant: >> >> (def ^:constant all-directions >> "Defines the array of all possible directions from a square." >> [[-1 -1][0 -1][+1 -1] >> [-1 0] [+1 0] >> [-1 +1][0 +1][+1 +1]]) >> >> Reasonable suggestions though. >> >> I think I'll have to create a version of get-and-make-move that just >> returns a random board (i.e. is as simple as possible) and see what happens. >> >> Is there a way to trace into a thread created by (future) ? >> >> On Tuesday, July 15, 2014 12:57:33 AM UTC+1, Gary Johnson wrote: >>> >>> Looking at this code without further knowledge of the strategy function, >>> my first guess is simply that your strategy function may not be returning a >>> result which satisfies the valid-move? and legal-move? predicates thus >>> throwing you into an infinite loop. Possibly the printf is being suppressed >>> within the swap! operation, but some testing would be required to see if >>> this is the case generally. The other obvious potential for a hiccup would >>> be if all-directions is somehow growing with each iteration of make-move, >>> thus preventing idx from ever exceeding its length. Not knowing what is >>> going on inside all these functions makes this a rather tricky bit of guess >>> work at best. Anyway, I'd try running get-move from the repl to see how >>> likely it is to get stuck in an infinite loop. >>> >>> Good luck, >>> ~Gary >>> >> -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
