Re: core.async timeout channels are values - is this intended
The reason = considers you timeout channels to be equal is that they are, in fact, the same object. In fact, they may end up being the same object even with different timeout values: (identical? (timeout 1) (timeout 2)) ;= true Except I got a false just now with a fresh REPL and same timeout value... All subsequent invocations return true though, and I'm sure with a little digging the reason for the false would become clear. The reason for them being the same object is that timeout goes out of its way to avoid creating to many timeout channels and will reuse existing ones if their timeouts are due within a small amount of time (clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10 ms) of the requested timeout. Cheers, Michał On 20 November 2013 10:08, Thomas G. Kristensen thomas.g.kristen...@gmail.com wrote: Hi all, I ran into a core.async behaviour that confused me a bit the other day. In some of our systems, we need to fire different timeouts, perform actions and schedule a new timeout. The problem is, that if the timeouts are of the same number of ms, we can't distinguish them, and therefore not keep track of and remove them from a set (at least not easily). That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm trying to say: (require '[clojure.core.async :refer [chan timeout alts!! alts!]]) (= (chan) (chan)) ;; false (= (timeout 1) (timeout 2)) ;; false (= (timeout 1) (timeout 1)) ;; true (do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))] (when-let [chs (keys ch-v)] (let [[_ ch] (alts!! chs)] (println (ch-v ch)) (recur (dissoc ch-v ch) (println done)) ;; only fires 3, the last channel in the map The intended behaviour of the last loop is to print 1, 2 and 3 (not necessarily in that order). However, the ch-v map will only contain one key, as timeouts with the same duration are considered the same value. In the real example, a new timeout with the same value should be scheduled again, by being put in the map. So, my questions are: - Is this intended behaviour? - Is there a different pattern for achieving the scheduling behaviour I'm looking for? Thanks for your help, Thomas -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: core.async timeout channels are values - is this intended
Isn't that not only violating least astonishment, but potentially introducing a terrible bug into the library? One could use two different timeout channels in two different alts, and if the timeout channels are aliased, then perhaps only one of the alts would actually get notified. On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.comwrote: The reason = considers you timeout channels to be equal is that they are, in fact, the same object. In fact, they may end up being the same object even with different timeout values: (identical? (timeout 1) (timeout 2)) ;= true Except I got a false just now with a fresh REPL and same timeout value... All subsequent invocations return true though, and I'm sure with a little digging the reason for the false would become clear. The reason for them being the same object is that timeout goes out of its way to avoid creating to many timeout channels and will reuse existing ones if their timeouts are due within a small amount of time (clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10 ms) of the requested timeout. Cheers, Michał On 20 November 2013 10:08, Thomas G. Kristensen thomas.g.kristen...@gmail.com wrote: Hi all, I ran into a core.async behaviour that confused me a bit the other day. In some of our systems, we need to fire different timeouts, perform actions and schedule a new timeout. The problem is, that if the timeouts are of the same number of ms, we can't distinguish them, and therefore not keep track of and remove them from a set (at least not easily). That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm trying to say: (require '[clojure.core.async :refer [chan timeout alts!! alts!]]) (= (chan) (chan)) ;; false (= (timeout 1) (timeout 2)) ;; false (= (timeout 1) (timeout 1)) ;; true (do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))] (when-let [chs (keys ch-v)] (let [[_ ch] (alts!! chs)] (println (ch-v ch)) (recur (dissoc ch-v ch) (println done)) ;; only fires 3, the last channel in the map The intended behaviour of the last loop is to print 1, 2 and 3 (not necessarily in that order). However, the ch-v map will only contain one key, as timeouts with the same duration are considered the same value. In the real example, a new timeout with the same value should be scheduled again, by being put in the map. So, my questions are: - Is this intended behaviour? - Is there a different pattern for achieving the scheduling behaviour I'm looking for? Thanks for your help, Thomas -- -- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: core.async timeout channels are values - is this intended
The behaviour of timeout channels is to close after the timeout elapses. This will be visible everywhere the channel is used. Cheers, Michał On 20 November 2013 11:22, Cedric Greevey cgree...@gmail.com wrote: Isn't that not only violating least astonishment, but potentially introducing a terrible bug into the library? One could use two different timeout channels in two different alts, and if the timeout channels are aliased, then perhaps only one of the alts would actually get notified. On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.com wrote: The reason = considers you timeout channels to be equal is that they are, in fact, the same object. In fact, they may end up being the same object even with different timeout values: (identical? (timeout 1) (timeout 2)) ;= true Except I got a false just now with a fresh REPL and same timeout value... All subsequent invocations return true though, and I'm sure with a little digging the reason for the false would become clear. The reason for them being the same object is that timeout goes out of its way to avoid creating to many timeout channels and will reuse existing ones if their timeouts are due within a small amount of time (clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10 ms) of the requested timeout. Cheers, Michał On 20 November 2013 10:08, Thomas G. Kristensen thomas.g.kristen...@gmail.com wrote: Hi all, I ran into a core.async behaviour that confused me a bit the other day. In some of our systems, we need to fire different timeouts, perform actions and schedule a new timeout. The problem is, that if the timeouts are of the same number of ms, we can't distinguish them, and therefore not keep track of and remove them from a set (at least not easily). That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm trying to say: (require '[clojure.core.async :refer [chan timeout alts!! alts!]]) (= (chan) (chan)) ;; false (= (timeout 1) (timeout 2)) ;; false (= (timeout 1) (timeout 1)) ;; true (do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))] (when-let [chs (keys ch-v)] (let [[_ ch] (alts!! chs)] (println (ch-v ch)) (recur (dissoc ch-v ch) (println done)) ;; only fires 3, the last channel in the map The intended behaviour of the last loop is to print 1, 2 and 3 (not necessarily in that order). However, the ch-v map will only contain one key, as timeouts with the same duration are considered the same value. In the real example, a new timeout with the same value should be scheduled again, by being put in the map. So, my questions are: - Is this intended behaviour? - Is there a different pattern for achieving the scheduling behaviour I'm looking for? Thanks for your help, Thomas -- -- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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
Re: core.async timeout channels are values - is this intended
As for scheduling the printlns, this prints out 1, 2, 3 (in some order): (let [c (chan)] (doseq [v [1 2 3]] (take! (async/timeout 1000) (fn [_] (put! c v (go-loop [v (! c)] (println v) (recur (! c Cheers, Michał On 20 November 2013 11:34, Michał Marczyk michal.marc...@gmail.com wrote: The behaviour of timeout channels is to close after the timeout elapses. This will be visible everywhere the channel is used. Cheers, Michał On 20 November 2013 11:22, Cedric Greevey cgree...@gmail.com wrote: Isn't that not only violating least astonishment, but potentially introducing a terrible bug into the library? One could use two different timeout channels in two different alts, and if the timeout channels are aliased, then perhaps only one of the alts would actually get notified. On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.com wrote: The reason = considers you timeout channels to be equal is that they are, in fact, the same object. In fact, they may end up being the same object even with different timeout values: (identical? (timeout 1) (timeout 2)) ;= true Except I got a false just now with a fresh REPL and same timeout value... All subsequent invocations return true though, and I'm sure with a little digging the reason for the false would become clear. The reason for them being the same object is that timeout goes out of its way to avoid creating to many timeout channels and will reuse existing ones if their timeouts are due within a small amount of time (clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10 ms) of the requested timeout. Cheers, Michał On 20 November 2013 10:08, Thomas G. Kristensen thomas.g.kristen...@gmail.com wrote: Hi all, I ran into a core.async behaviour that confused me a bit the other day. In some of our systems, we need to fire different timeouts, perform actions and schedule a new timeout. The problem is, that if the timeouts are of the same number of ms, we can't distinguish them, and therefore not keep track of and remove them from a set (at least not easily). That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm trying to say: (require '[clojure.core.async :refer [chan timeout alts!! alts!]]) (= (chan) (chan)) ;; false (= (timeout 1) (timeout 2)) ;; false (= (timeout 1) (timeout 1)) ;; true (do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))] (when-let [chs (keys ch-v)] (let [[_ ch] (alts!! chs)] (println (ch-v ch)) (recur (dissoc ch-v ch) (println done)) ;; only fires 3, the last channel in the map The intended behaviour of the last loop is to print 1, 2 and 3 (not necessarily in that order). However, the ch-v map will only contain one key, as timeouts with the same duration are considered the same value. In the real example, a new timeout with the same value should be scheduled again, by being put in the map. So, my questions are: - Is this intended behaviour? - Is there a different pattern for achieving the scheduling behaviour I'm looking for? Thanks for your help, Thomas -- -- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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
Re: core.async timeout channels are values - is this intended
Thanks for the response and discussion. Your proposal solves the problem, but not the general observation: that timeout channels are not usable keys. A small tweak on your proposal can make a key-safe channel: (defn unique-timeout [ms] (let [c (chan)] (take! (timeout ms) (fn [_] (close! c))) c)) (do (loop [ch-v (into {} (for [v [1 2 3]] [(unique-timeout 1000) v]))] (when-let [chs (keys ch-v)] (let [[_ ch] (alts!! chs)] (println (ch-v ch)) (recur (dissoc ch-v ch) (println done)) I think the lesson learned is, that the implementation of timeout-channels favours efficiency over the possibility of storing them in maps or sets, and removing them from these datastructures in a loop. Once again, thanks for all the feedback! Thomas On Wednesday, November 20, 2013 10:53:45 AM UTC, Michał Marczyk wrote: As for scheduling the printlns, this prints out 1, 2, 3 (in some order): (let [c (chan)] (doseq [v [1 2 3]] (take! (async/timeout 1000) (fn [_] (put! c v (go-loop [v (! c)] (println v) (recur (! c Cheers, Michał On 20 November 2013 11:34, Michał Marczyk michal@gmail.comjavascript: wrote: The behaviour of timeout channels is to close after the timeout elapses. This will be visible everywhere the channel is used. Cheers, Michał On 20 November 2013 11:22, Cedric Greevey cgre...@gmail.comjavascript: wrote: Isn't that not only violating least astonishment, but potentially introducing a terrible bug into the library? One could use two different timeout channels in two different alts, and if the timeout channels are aliased, then perhaps only one of the alts would actually get notified. On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal@gmail.comjavascript: wrote: The reason = considers you timeout channels to be equal is that they are, in fact, the same object. In fact, they may end up being the same object even with different timeout values: (identical? (timeout 1) (timeout 2)) ;= true Except I got a false just now with a fresh REPL and same timeout value... All subsequent invocations return true though, and I'm sure with a little digging the reason for the false would become clear. The reason for them being the same object is that timeout goes out of its way to avoid creating to many timeout channels and will reuse existing ones if their timeouts are due within a small amount of time (clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10 ms) of the requested timeout. Cheers, Michał On 20 November 2013 10:08, Thomas G. Kristensen thomas.g@gmail.com javascript: wrote: Hi all, I ran into a core.async behaviour that confused me a bit the other day. In some of our systems, we need to fire different timeouts, perform actions and schedule a new timeout. The problem is, that if the timeouts are of the same number of ms, we can't distinguish them, and therefore not keep track of and remove them from a set (at least not easily). That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm trying to say: (require '[clojure.core.async :refer [chan timeout alts!! alts!]]) (= (chan) (chan)) ;; false (= (timeout 1) (timeout 2)) ;; false (= (timeout 1) (timeout 1)) ;; true (do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))] (when-let [chs (keys ch-v)] (let [[_ ch] (alts!! chs)] (println (ch-v ch)) (recur (dissoc ch-v ch) (println done)) ;; only fires 3, the last channel in the map The intended behaviour of the last loop is to print 1, 2 and 3 (not necessarily in that order). However, the ch-v map will only contain one key, as timeouts with the same duration are considered the same value. In the real example, a new timeout with the same value should be scheduled again, by being put in the map. So, my questions are: - Is this intended behaviour? - Is there a different pattern for achieving the scheduling behaviour I'm looking for? Thanks for your help, Thomas -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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
Re: :peer/timeout Transaction timed out, and excessive logging
Damn, wrong group. Sorry On Thursday, March 14, 2013 10:37:30 AM UTC-7, Brian Craft wrote: I just tried loading a real data file (30M tsv) for the first time (I mean, instead of just unit tests on my loading program with tiny files), which resulted in this output: Exception in thread main clojure.lang.ExceptionInfo: :peer/timeout Transaction timed out. {:db/error :peer/timeout} at clojure.core$ex_info.invoke(core.clj:4227) at datomic.error$raise.invoke(error.clj:24) (blah blah blah) Mar 14, 2013 10:11:39 AM org.hornetq.core.logging.impl.JULLogDelegate warn WARNING: Connection failure has been detected: Did not receive data from server for org.hornetq.core.remoting.impl.netty.NettyConnection@76e222eb[local= / 127.0.0.1:59944, remote=localhost/127.0.0.1:4334] [code=3] More remarkable, the transactor output nearly a million lines of traceback. Tail shown here, with line numbers 928765 at datomic.common$interruptible$fn__289.doInvoke(common.clj:383) [datomic-free-transactor-0.8.3767.jar:na] 928766 at clojure.lang.RestFn.applyTo(RestFn.java:137) [clojure-1.4.0.jar:na] 928767 at clojure.core$apply.invoke(core.clj:603) [clojure-1.4.0.jar:na] 928768 at datomic.common$background$proc__294$fn__295.invoke(common.clj:402) [datomic-free-transactor-0.8.3767.jar:na] 928769 at datomic.common$background$proc__294.invoke(common.clj:401) [datomic-free-transactor-0.8.3767.jar:na] 928770 at clojure.lang.AFn.run(AFn.java:24) [clojure-1.4.0.jar:na] 928771 at java.lang.Thread.run(Thread.java:619) [na:1.6.0_11] It also exited with this Critical failure, cannot continue: Agent failed java.lang.OutOfMemoryError: Java heap space So, my first thought is perhaps I'm going about this the wrong way. I'm doing a bulk load by calling d/transact on a lazy sequence of data structures representing all the facts in the 30M file. Should I be doing this differently? My second thought is perhaps datomic should throttle its logging, since a million lines of traceback is a bit excessive. It's the same traceback (about 16 lines) repeated, only the timestamp changes. -- -- 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/groups/opt_out.
Re: nrepl timeout advice needed
Providing a timeout of Long/MAX_VALUE is functionally equivalent to having no timeout. This is what most nREPL clients use by default (including reply [and therefore Leiningen], and the Java Connection class, which Counterclockwise uses). - Chas -- http://cemerick.com [Clojure Programming from O'Reilly](http://www.clojurebook.com) On Jun 11, 2012, at 8:33 AM, MikeM wrote: I'm using nrepl with a client created as described in the github readme (https://github.com/clojure/tools.nrepl). The nrepl server and client are on the same machine. Everything's working well, except when I try to eval a long-running bit of code. It seems that the timeout defined for the client is causing the output to be truncated. Is there a way to set-up a client with no timeout? Or should I just use an large timeout value? -- 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
Re: with-timeout... ?
In Overtone we have the same situation, where we return a promise representing a server response and sometimes we want to timeout if the response never arrives. This is what we use: (defn await-promise! ([prom] (await-promise prom REPLY-TIMEOUT)) ([prom timeout] (.get (future @prom) timeout TimeUnit/MILLISECONDS))) (We have another version without the exclamation mark that returns :timeout rather than throwing an exception when timed out.) I agree with you though, that something along these lines should be built-in. I was surprised to find that there was no way to block on a promise with a timeout, as it seems like such a typical requirement for almost anything you might be promised. -Jeff On Mar 9, 1:12 pm, Sean Allen s...@monkeysnatchbanana.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. Thanks, Sean -- 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
Re: with-timeout... ?
Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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
Re: with-timeout... ?
On Wed, Mar 9, 2011 at 7:25 AM, Baishampayan Ghose b.gh...@gmail.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Variation on that macro are what I've seen across the variety of sources I've mentioned in my original message. It just strikes me as odd that something so general hasn't made it into a library. If it really hasn't made a library, ok.. I just wanted to make sure it wasn't in a library somewhere and that keeping the hand rolled macro wasn't something I should still be doing. -- 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
Re: with-timeout... ?
See https://github.com/Raynes/clojail It's a sandboxing library for Clojure, which among other things means it needs to try running an operation and give up after N seconds. You can skip the sandboxing part entirely if you want; it exposes a pretty general thunk-timeout function. On Mar 9, 4:43 am, Sean Allen s...@monkeysnatchbanana.com wrote: On Wed, Mar 9, 2011 at 7:25 AM, Baishampayan Ghose b.gh...@gmail.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Variation on that macro are what I've seen across the variety of sources I've mentioned in my original message. It just strikes me as odd that something so general hasn't made it into a library. If it really hasn't made a library, ok.. I just wanted to make sure it wasn't in a library somewhere and that keeping the hand rolled macro wasn't something I should still be doing. -- 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
Re: with-timeout... ?
Or you could just modify the source of promise ... i dont know why promises dont support timeouts (defprotocol PWait (wait-for [this timeout units] [this timeout])) ;;copied from clojure source, but adding timeout wait-for (defn promise Alpha - subject to change. Returns a promise object that can be read with deref/@, and set, once only, with deliver. Calls to deref/@ prior to delivery will block. All subsequent derefs will return the same delivered value without blocking. {:added 1.1} [] (let [d (java.util.concurrent.CountDownLatch. 1) v (atom nil)] (reify clojure.lang.IDeref (deref [_] (.await d) @v) PWait (wait-for [this timeout] (wait-for this timeout java.util.concurrent.TimeUnit/MILLISECONDS)) (wait-for [this timeout units] (if timeout (.await d timeout units) (do (.await d) true))) clojure.lang.IFn (invoke [this x] (locking d (if (pos? (.getCount d)) (do (reset! v x) (.countDown d) x) (throw (IllegalStateException. Multiple deliver calls to a promise -- 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
Re: with-timeout... ?
I've been working in this direction with Cljque, for example http://bit.ly/gCtmAl Cljque is still an experiment and has no stable API or documentation. -Stuart Sierra clojure.com -- 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
Re: with-timeout... ?
oooh ... I can definitely find a use for this in my project! Thanks for pointing it out. -- 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