Re: Clojure Futures Docs and Functionality
Sounds good to me. The first version of that function I wrote without
returning nil, but just bubbling up the exception. I changed it because I
couldn't think of another area of the Clojure core that threw an exception
like that. Looking through some of the agents code, I think there are some
similar scenarios that do throw an exception.
As far as the seconds/minutes etc stuff. I just added that to not lose
anything from the Java API. Getting rid of that, the much simpler function
looks like:
(defn future-await
Returns the value of the future just like a deref. If the future has not
completed by timeout, nil is returned
[^java.util.concurrent.Future f timeout-in-millis]
(.get f timeout-in-millis java.util.concurrent.TimeUnit/MILLISECONDS))
Usage is same as before:
(def fut
(future
(Thread/sleep 1)
done))
(future-await fut 1) ; throws java.util.concurrent.TimeoutException
(def fut
(future
(Thread/sleep 1)
done))
(future-await fut 10) ; done
-Ryan
On Sat, Jun 26, 2010 at 12:56 AM, Meikel Brandmeyer m...@kotka.de wrote:
Hi,
Am 25.06.2010 um 20:48 schrieb Daniel Werner:
On 25 June 2010 05:27, Ryan Senior senior.r...@gmail.com wrote:
(future-await fut2 2 :minutes) ; = done
What do others think?
I agree – in particular for point 2.
For point 1: I think 2 :minutes is not very clojure-like. It sound more
like Ruby: 2.minutes. A more clojure-like approach would be to an use
optional keyword argument.
(defn future-await
[fut {:keys [timeout]}]
)
(future-await zukunft)
(future-await zukunft :timeout time-out-in-ms)
Or of course the simple two-arg-version.
Sincerely
Meikel
--
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.comclojure%2bunsubscr...@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 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: Clojure Futures Docs and Functionality
Hi Daniel, On Wed, Jun 23, 2010 at 1:15 PM, Daniel Werner daniel.d.wer...@googlemail.com wrote: Judging from previous discussions on this list, I get the feeling that relying too much on the Java implementation details underlying the public Clojure APIs is discouraged. This certainly makes sense considering that apparently one of the future plans (no pun intended) is to give the CLR and JavaScript ports of the language more focus. I don't know much about the CLR version of Clojure but can understand that. My goal was just trying eliminate the need look at the source code to know about the timeout feature of the Futures. Having the below function solves that problem. IMHO this seems like a useful improvement. Maybe your proposal would draw more attention if you backed it up with a patch -- even a preliminary one? :-) What I was thinking for a future-await function was: (defn- convert-time-unit [unit] (case unit :nanoseconds (java.util.concurrent.TimeUnit/NANOSECONDS) :microseconds (java.util.concurrent.TimeUnit/MICROSECONDS) :milliseconds (java.util.concurrent.TimeUnit/MILLISECONDS) :seconds (java.util.concurrent.TimeUnit/SECONDS) :minutes (java.util.concurrent.TimeUnit/MINUTES) :hours (java.util.concurrent.TimeUnit/HOURS) :days (java.util.concurrent.TimeUnit/DAYS) (throw (IllegalArgumentException. (str unit is not a valid unit of time) (defn future-await Returns the value of the future just like a deref. If the future has not completed by timeout, nil is returned ([^java.util.concurrent.Future f timeout-in-millis] (future-await f timeout-in-millis :milliseconds)) ([^java.util.concurrent.Future f timeout unit] (try (- unit convert-time-unit (.get f timeout)) (catch java.util.concurrent.TimeoutException e nil It's usage is below (def fut (future (Thread/sleep 100) done)) (future-await fut 1000) ;throws exception (future-await fut 2 :seconds) ;throws exception (def fut2 (future (Thread/sleep 1) done)) (future-await fut2 2 :minutes) ; = done -Ryan -- 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: Clojure Futures Docs and Functionality
On 25 June 2010 05:27, Ryan Senior senior.r...@gmail.com wrote: (future-await fut2 2 :minutes) ; = done Your implementation points into the right direction (again, IMHO). I'd like to offer two suggestions: 1. Leave out the three-arg version of future-await. The time unit conversion seems somewhat superfluous, with little gain for the lines of code added. Rich argued against writing thin wrappers around Java stuff as well. And personally, I'd probably only ever use the two-arg version with an integer in milliseconds, since that's what most methods/functions are using anyway. (If you know of use cases for and trust the system clock to act on milliseconds correctly, you could also make the integer represent nanoseconds instead.) 2. Returning nil to represent timeout is dangerous here -- the future may have completed correctly and returned nil! It should be perfectly okay and idiomatic here to let the TimeoutException escape, as long as you document this behaviour. What do others think? -- Daniel -- 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: Clojure Futures Docs and Functionality
Hi,
Am 25.06.2010 um 20:48 schrieb Daniel Werner:
On 25 June 2010 05:27, Ryan Senior senior.r...@gmail.com wrote:
(future-await fut2 2 :minutes) ; = done
What do others think?
I agree – in particular for point 2.
For point 1: I think 2 :minutes is not very clojure-like. It sound more like
Ruby: 2.minutes. A more clojure-like approach would be to an use optional
keyword argument.
(defn future-await
[fut {:keys [timeout]}]
)
(future-await zukunft)
(future-await zukunft :timeout time-out-in-ms)
Or of course the simple two-arg-version.
Sincerely
Meikel
--
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: Clojure Futures Docs and Functionality
Hello Ryan, On Jun 21, 7:34 am, Ryan Senior senior.r...@gmail.com wrote: 1 - I think a good improvement would be updating the docs for the future related functions to indicate what kind of objects are passed in and returned. Users would then not have to go through the source to see what's being returned. This could also be useful to know if users were getting java.util.concurrent.Future instances from other places and wanted to use them with the Clojure API. Judging from previous discussions on this list, I get the feeling that relying too much on the Java implementation details underlying the public Clojure APIs is discouraged. This certainly makes sense considering that apparently one of the future plans (no pun intended) is to give the CLR and JavaScript ports of the language more focus. 2 - Is there a reason that get with a timeout from java.util.concurrent.Future is not included in the Clojure future functions? It seems to be the only one missing and having that function would make the details around what kind of object is returned/passed in by these functions less important. Maybe future-await or something? What sort of time parameter would this new function would accept? The java.util.concurrent.Future.get method uses an int and the java.util.concurrent.TimeUnit enum. IMHO this seems like a useful improvement. Maybe your proposal would draw more attention if you backed it up with a patch -- even a preliminary one? :-) Have a nice day, -- Daniel -- 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
