Re: A Failure To Understand lazy-seq
I'll try and explain. This explanation isn't perfectly rigorous, but may be close enough. (def fibs (lazy-seq (cons 0 (cons 1 (map +' fibs (rest fibs)) This creates a thunk, deferring execution of the body of `lazy-seq`. (first fibs) This forces the thunk, let's call it THUNK1. In order to force the thunk, we must evaluate the expression (cons 0 (cons 1 (map +' fibs (rest fibs In order to evaluate the expression (cons 0 E1), we must evaluate E1 (cons 1 (map +' fibs (rest fibs))) In order to evaluate the expression (cons 1 E2), we must evaluate E2 (map +' fibs (rest fibs)) Although map creates a lazy seq, it does not lazily evaluate its argument expressions. fibs is fine (rest fibs) must be evaluated To evaluate (rest fibs), we have to go through basically the same process as when we started evaluating (first fibs) If we could just say "(rest fibs) is a thunk", then we'd be done. But that's not how rest works. It evaluates its argument. Evaluating fibs starts forcing THUNK1 again. Loop ad infinitum. So I think the answer is that "map" and "rest" are just a tiny bit less lazy than you might have thought. More laziness could be accomplished by making map a macro that doesn't eval its argument expressions, and by making rest always return a lazy seq. Either of these things would have prevented the infinite loop here. I won't bother getting into the discussion on why they are the way they are. Contrast with (def fibs (cons 0 (cons 1 (lazy-seq (map +' fibs (rest fibs)) This creates a seq, where the first two elements are already evaluated to be 0 and 1, but the rest after that is a thunk which is evaluated lazily. (first fibs) This is able to retrieve 0 immediately. It doesn't even force the lazy-seq thunk. How about something more interesting? (third fibs) We skip over 0 and 1, and now we have to start evaluating that lazy-seq. (map +' fibs (rest fibs)) Let's call this THUNK0 map of course produces a lazy seq, but we are forcing it to tell us its first result In order to do so, map only needs to access the first element of each of its args. (first fibs) immediately retrieve 0 (first (rest fibs)) We must evaluate (rest fibs) We immediately know this is (cons 1 THUNK0) (first (cons 1 THUNK0)) We immediately know this is 1, no need to recurse into forcing THUNK0 (+ 0 1) = 1 And there's our answer. When you go asking for the fourth element, it will now be able to access the third and second immediately with no recursive thunk forcing. Exercise: You put the lazy seq at the beginning and it hit an infinite loop. You put the lazy seq after the first two hard-coded values, and it worked. What happens when you put it after just the first hard-coded value? Can you explain why? (def fibs (cons 0 (lazy-seq (cons 1 (map +' fibs (rest fibs)) -- Dan Burton On Mon, Sep 4, 2017 at 5:33 PM, mrwizard82d1 <mrwizard8...@gmail.com> wrote: > I'm trying to understand infinite sequences. > > Wikipedia defines an implementation of the Fibonacci sequence as: > > (def fibs (cons 0 (cons 1 (lazy-seq (map +' fibs (rest fibs)) > > However, when I wrote fibs in the repl as: > > (def fibs (lazy-seq (cons 0 (cons 1 (map +' fibs (rest fibs)) > > executing (first fibs) produces a StackOverflow exception. > > What is the reason that the second, incorrect definition throws a > StackOverflow exception, but the first generates an infinite sequence? > > Thanks. > > -- > 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. > -- 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.
Re: Clojure spec keys is considering all key within namespace although it is not defined
This design is surprising to me. If this is the case, then I don't
understand the point of `:opt` for s/keys.
-- Dan Burton
On Wed, Jun 28, 2017 at 2:17 AM, Max Penet <m...@qbits.cc> wrote:
> Hi,
>
> It's by design, as the doc of s/keys states:
>
> In addition, the values of *all* namespace-qualified keys will be validated
> (and possibly destructured) by any registered specs. Note: there is
> no support for inline value specification, by design.
>
>
>
> So if the ns'ed key in your map is registered as a spec it will be validated.
> In theory you could just validate with (s/keys) in your case, specifying keys
> in req is useful to check presence and gen and in the case of opt just for
> gen. The docstring is terse but dense in meaning/information.
>
>
> On Wednesday, June 28, 2017 at 11:04:34 AM UTC+2, Mamun wrote:
>>
>> Hi All,
>>
>> Clojure spec keys is considering all key within namespace although it is
>> not defined.
>>
>> Here is an example
>>
>> (s/def :person/fname string?)
>> (s/def :person/lname string?)
>> (s/def :person/id int?)
>>
>> ;;With only fname and lname
>> (s/def :app/person (s/keys :req [:person/fname :person/lname]))
>>
>> ;;Success
>> (s/explain-str :app/person
>>{:person/lname "Abdullah"
>> :person/fname "Mamun"} )
>>
>> ;;Success
>> (s/explain-str :app/person
>>{:person/lname "Abdullah"
>> :person/fname "Mamun"
>> :id "123"} )
>>
>> ;;fail with namespace id
>> (s/explain-str :app/person
>>{:person/lname "Abdullah"
>> :person/fname "Mamun"
>> :person/id "1234"})
>>
>>
>> Is it bug or am I doing something wrong here?
>>
>> Br,
>> Mamun
>>
> --
> 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.
>
--
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.
Re: Release date for 1.9
Obligatory: "our team uses clojure-future-spec with clojure-1.8" -- no problems so far. -- Dan Burton On Tue, Feb 28, 2017 at 11:59 AM, Sean Corfield <s...@corfield.org> wrote: > On 2/28/17, 10:26 AM, "Erik Assum" <clojure@googlegroups.com on behalf of > e...@assum.net> wrote: > > And, yes, I'm aware of the fact that the 1.9-alphas are very stable wrt > putting it in production. > > Obligatory: “we’ve been running the 1.9 Alphas in production for months so > that we can leverage clojure.spec” – no problems so far. > > Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN > World Singles -- http://worldsingles.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 > --- > 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. > -- 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.
Re: It's time for Google Summer of Code 2017!
Note that when Haskell.org didn't make it into gsoc last year, they successfully organized a similar program through private donations. While one hopes that Clojure will be accepted into gsoc, consider having a similar course of action as Plan B. -- Dan Burton On Thu, Feb 2, 2017 at 10:31 PM, Daniel Solano Gómez <cloj...@sattvik.com> wrote: > Hello, all, > > We now have less than a week to prepare our application for Google Summer > of Code 2017 <https://summerofcode.withgoogle.com/>, a program where > Google pays students from around the world to work on open source > projects. Clojure has successfully participated 2012–2015, and we would > love to return for a fifth time. As a community, we have benefitted > significantly over the years with amazing work on projects like Clojure in > Clojure, ClojureScript, Clojure on Android, Incanter, and more. And it's > not just the projects that have benefitted, many of Clojure/GSoC alumns > continue to contribute to the community and are often speakers at > conferences. > > In order to participate again this year, we need your help; we need project > ideas <http://clojure-gsoc.org/project-ideas.html>. A great project > ideas page is a key part in having a successful application, and having > many members from within the community participate as potential mentors > would really boost our application. At this point, you are not committing > to anything, we just need some great ideas. > > This year, we are trying something new: We are hosting our project ideas > on GitHub > <https://github.com/clojars/clojure-gsoc-2017/blob/master/project-ideas.md> > and you can submit your idea just using a few lines of Markdown in a pull > request. If you'd rather not do that, you can post to the mailing list > with [GSoC Idea] in the subject and we'll add it for you. Also, you can > submit ideas in the #gsoc channel in the Clojurians slack. > > > You can also help review our application > <http://clojure-gsoc.org/application.html> and profile > <http://clojure-gsoc.org/profile.html> pages, and we would appreciate any > input > > Finally, a big thanks to all of the administrators and volunteers who have > helped Clojure's GSoC in years past. > > Thank you very much for your time and idea. > > Sincerely, > > 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 > --- > 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. > -- 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.
Re: Meta-data should be added to deprecated functions?
>
> The second is adding functionality to Clojure core to give you more
> feedback about deprecated functions and that's something I've been trying
> to push through to completion for Clojure 1.9. See:
> http://dev.clojure.org/jira/browse/CLJ-706
Excited to see this being pushed for Clojure 1.9! Nice work.
-- Dan Burton
On Tue, Aug 9, 2016 at 1:49 PM, Alex Miller <a...@puredanger.com> wrote:
> There are really two aspects to this - one is actually including the
> metadata in core.async, which can definitely be done.
>
> The second is adding functionality to Clojure core to give you more
> feedback about deprecated functions and that's something I've been trying
> to push through to completion for Clojure 1.9. See:
> http://dev.clojure.org/jira/browse/CLJ-706
>
>
> On Tuesday, August 9, 2016 at 3:05:24 PM UTC-5, Ertuğrul Çetin wrote:
>>
>> I found the *map>* function from *core.async* and it was deprecated(doc
>> says), but there is no meta-data.
>>
>> If we have meta-data for *deprecated* functions our tools(IDEs) would
>> work better, like scratch out the function(Most IDEs do that).
>>
>> Ex:
>>
>> This
>>
>> (defn map>
>> "."
>>
>> {:added "1.0"
>>
>>:deprecated true}
>>
>> [f ch]
>> //...)
>>
>>
>> instead of this
>>
>>
>> (defn map>
>> "Deprecated - this function will be removed. Use transducer instead"
>> [f ch]
>> //...)
>>
>>
>>
>> --
> 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.
>
--
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.
Re: Is this behavior of clojure.core/pr a bug?
Why not just have #keyword and #symbol reader syntax tags that pr could
produce for situations like this? It's really preferable that pr not throw
exceptions, but it's also quite an abomination that it silently produces
bad edn.
On Wednesday, August 3, 2016, Blake Miller <blak3mil...@gmail.com> wrote:
> Thanks for that concise explanation, Sean. It makes sense to me that not
> all valid Clojure data is serializable.
>
> There's still something about this that doesn't quite make sense to me,
> though:
>
> clojure.core/pr, rather than throwing an exception when asked to serialize
> an instance of clojure.core.Keyword that cannot be serialized, it simply
> produces bad output. Bad = will cause the reader to throw.
>
> Wouldn't it be preferable for pr to throw in this case?
>
> The way I found out about this was the not-very-informative exception "Map
> literal must contain an even number of forms", because pr was fine with
> making a string that the reader wouldn't accept.
>
> Can anyone think of a good reason why pr should *not* throw an exception on
>
> (pr (keyword "foo bar"))
>
> since there's no way of expressing that keyword as valid EDN?
>
>
>
> On Thursday, August 4, 2016 at 12:16:47 AM UTC, Sean Corfield wrote:
>>
>> You can programmatically create keywords that are illegal as literals,
>> i.e., will not be accepted by the reader.
>>
>>
>>
>> This is not a fault of clojure.core/pr – if it is given a value that uses
>> legal (readable) keywords, its result will indeed be readable by
>> clojure.core/read-string.
>>
>>
>>
>> You can also programmatically create symbols that are illegal as far as
>> the reader is concerned.
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>>
>> On 8/3/16, 4:37 PM, "Blake Miller" <clo...@googlegroups.com on behalf of
>> blak3...@gmail.com> wrote:
>>
>>
>>
>> I have tried this with Clojure 1.7.0, 1.8.0 and 1.9.0-alpha10
>>
>> (clojure.core/read-string (clojure.core/with-out-str (clojure.core/pr
>> (clojure.core/keyword "A valid keyword" ;; => :A
>>
>>
>> This just seems wrong. It's valid to have an instance of
>> clojure.lang.Keyword with a space in its name.
>>
>> (clojure.core/with-out-str (clojure.core/pr (clojure.core/keyword "A
>> valid keyword"))) => ":A valid keyword"
>>
>>
>>
>> So, it seems like clojure.core/pr and clojure.core/read-string disagree
>> about EDN.
>>
>>
>>
>> Is EDN formally specified? https://github.com/edn-format/edn/issues/56
>> seems to suggest it is not.
>>
>> I ran into this problem using ptaoussanis/sente to pass EDN over a
>> websocket. The EDN contained a keyword with a space in it, and the
>> clojure(jvm) part of sente had no problem serializing it, but the
>> ClojureScript part of sente barfed on it. I thought it was a bug in sente,
>> however sente simply calls clojure.core/pr to do the serialization... so I
>> played with pr vs read-string and found that they disagree.
>>
>>
>>
>> The serialization that clojure.core/pr does on a keyword with a space in
>> it seems broken to me:
>>
>>
>>
>> user> (clojure.core/with-out-str (clojure.core/pr {:onekey 1
>>
>>(clojure.core/keyword
>> "two key") 2}))
>>
>> "{:onekey 1, :two key 2}"
>>
>> There doesn't seem to be any way to parse that unambiguously.
>>
>> I think this is a bug. What do you think?
>>
>>
>> https://github.com/ptaoussanis/sente/issues/251
>>
>>
>>
>>
>>
>> --
> 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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','clojure%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.
> T
Re: reader conditional not handling defmacro?
What about something like ;; obj.cljc (ns obj) (def obj #?(:clj Object :cljs js/Object)) (defmacro get-obj [] `obj) ;; obj-test.cljc (ns obj-test (:require [obj :refer-macros [get-obj]])) (def gotten-obj (obj/get-obj)) Load obj-test in clj, and obj-test/gotten-obj is Object. Load it in cljs, and gotten-obj is js/Object. Thus, you can write cljc macros that symbolically refer to obj/obj and turn out as the correct thing. This is because the macro doesn't refer to the *value* of obj, just to the symbol, which isn't evaluated until runtime. -- Dan Burton On Fri, May 20, 2016 at 11:22 AM, hiskennyness <kentil...@gmail.com> wrote: > Thanks, Sean. (My follow-up fix request went out just as your fix came in.) > > -kt > > > On Friday, May 20, 2016 at 2:16:47 PM UTC-4, hiskennyness wrote: >> >> >> >> On Friday, May 20, 2016 at 1:34:43 PM UTC-4, hiskennyness wrote: >>> >>> My next problem with .cljc (which is going very very well overall!) has >>> to do with macros. >>> snip >>> >>> ps. I will try the old trick of having a helper defn with-defobserver >>> and with-whatever to see if this is purely a macro interaction. >>> >> >> Not surprisingly, that worked on the second (unposted) example which >> could be divided/conquered into a helper defn (tho my CL is getting rusty, >> the old trick is call-with-whatever). >> >> Unfortunately the other case (the one shown) really is a conditional >> code-rewriting that has to happen at macroexpansion time, so a fix is still >> needed. >> >> >> -- > 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. > -- 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.
Re: Using a try catch inside a future
Ah, the weirdness was because I forgot to make future-try wait for the future it creates. (defmacro future-try [& body] `(let [thread-atom# (atom nil)] (try (reset! thread-atom# (future (try ~@body))) *@@thread-atom#* (catch Exception e# (if-let [thread# @thread-atom#] (future-cancel thread#)) (throw e#) Using this does cancel the inner thread as soon as you cancel the outer one, it does run the "catch" branch of code, and it does stop the loop. You can even replace (while (not (Thread/interrupted)) ...) with (while true ...) and it still behaves this way. It might seem unexpected or undesirable that it runs the "catch" branch, but it does seem like a good idea to let a future-try/catch block clean up after itself. /shrug -- Dan Burton On Fri, Apr 29, 2016 at 6:26 PM, Dan Burton <danburton.em...@gmail.com> wrote: > Here's something to explore. > > (defmacro future-try [& body] > `@(future (try ~@body))) > > (defn test-f2 [initial-v] > (let [n (atom initial-v)] > [n > (future (while (not (Thread/interrupted)) >(future-try > (Thread/sleep 5000) > (swap! n inc) > (println @n) > (catch Exception e (println "whoops")])) > > (def t2 (test-f2 11)) > > test-f2 is the same as in your original email, except it uses future-try > instead of try. > It seems to allow you to correctly cancel the thread. It doesn't hit the > "whoops" branch. > > But something is off. It doesn't stop the inner block, and the final > number is printed *after* the outer future is cancelled. I would expect > canceling a future to cancel all of its children, but apparently this is > not the case. > > -- > > Want to see some really weird stuff? Here's how I tried to make future-try > attempt to cancel its children: > > (defmacro future-try [& body] > `(let [thread-atom# (atom nil)] > (try >(reset! thread-atom# (future (try ~@body))) >(catch Exception e# > (if-let [thread# @thread-atom#] >(future-cancel thread#)) > (throw e#) > > Try running (def f2 (test-f2 11)) with that future-try, and it goes crazy. > After waiting 5 seconds, it spews out numbers up to around 2031, then stops > because (second f2) wasn't able to allocate any more threads. I have no > explanation for this. > > -- Dan Burton > > On Fri, Apr 29, 2016 at 5:25 PM, Tom Bodenheimer < > tom.bodenhei...@gmail.com> wrote: > >> Hi Ashish, >> >> It actually appears that there is no exception thrown by default when >> future-cancel is called on the thread *unless* you manage to overlook java >> functions that include some type of interrupt status handling. As I >> managed to do. >> >> Take a look at my below test-interrupt-status-2 that includes a try/catch >> loop to see what I mean. >> >> Thanks. >> >> >> On Friday, April 29, 2016 at 9:35:39 AM UTC-4, Ashish Negi wrote: >>> >>> To stop any thread.. interrupts are send to it. >>> And threads handle this by throwing exception so that programmer can >>> decide what to do >>> depending upon the kind of exception it gets. (you may get different >>> exceptions) >>> >>> Since you are catching the exception, your thread is never stopped.. and >>> hence future-cancel returns false. >>> >>> If you throw again.. exception would unwind your while loop and stop the >>> thread. >>> hence.. future-cancel is able to stop the thread and returns true. >>> >>> -- >> 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. >> > > -- 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.
Re: Using a try catch inside a future
Here's something to explore. (defmacro future-try [& body] `@(future (try ~@body))) (defn test-f2 [initial-v] (let [n (atom initial-v)] [n (future (while (not (Thread/interrupted)) (future-try (Thread/sleep 5000) (swap! n inc) (println @n) (catch Exception e (println "whoops")])) (def t2 (test-f2 11)) test-f2 is the same as in your original email, except it uses future-try instead of try. It seems to allow you to correctly cancel the thread. It doesn't hit the "whoops" branch. But something is off. It doesn't stop the inner block, and the final number is printed *after* the outer future is cancelled. I would expect canceling a future to cancel all of its children, but apparently this is not the case. -- Want to see some really weird stuff? Here's how I tried to make future-try attempt to cancel its children: (defmacro future-try [& body] `(let [thread-atom# (atom nil)] (try (reset! thread-atom# (future (try ~@body))) (catch Exception e# (if-let [thread# @thread-atom#] (future-cancel thread#)) (throw e#) Try running (def f2 (test-f2 11)) with that future-try, and it goes crazy. After waiting 5 seconds, it spews out numbers up to around 2031, then stops because (second f2) wasn't able to allocate any more threads. I have no explanation for this. -- Dan Burton On Fri, Apr 29, 2016 at 5:25 PM, Tom Bodenheimer <tom.bodenhei...@gmail.com> wrote: > Hi Ashish, > > It actually appears that there is no exception thrown by default when > future-cancel is called on the thread *unless* you manage to overlook java > functions that include some type of interrupt status handling. As I > managed to do. > > Take a look at my below test-interrupt-status-2 that includes a try/catch > loop to see what I mean. > > Thanks. > > > On Friday, April 29, 2016 at 9:35:39 AM UTC-4, Ashish Negi wrote: >> >> To stop any thread.. interrupts are send to it. >> And threads handle this by throwing exception so that programmer can >> decide what to do >> depending upon the kind of exception it gets. (you may get different >> exceptions) >> >> Since you are catching the exception, your thread is never stopped.. and >> hence future-cancel returns false. >> >> If you throw again.. exception would unwind your while loop and stop the >> thread. >> hence.. future-cancel is able to stop the thread and returns true. >> >> -- > 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. > -- 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.
Re: Using a try catch inside a future
One technique for addressing this sort of issue has been described in Haskell-land: https://www.schoolofhaskell.com/user/snoyberg/general-haskell/exceptions/catching-all-exceptions http://hackage.haskell.org/package/enclosed-exceptions I'm unaware of any comparable clojure library, but the same technique probably works. A simpler technique in this case would be to only catch the kinds of exceptions that you expect the inner block to throw, rather than "catching all exceptions" with (catch Exception e ...). -- Dan Burton On Fri, Apr 29, 2016 at 6:35 AM, Ashish Negi <thisismyidash...@gmail.com> wrote: > To stop any thread.. interrupts are send to it. > And threads handle this by throwing exception so that programmer can > decide what to do > depending upon the kind of exception it gets. (you may get different > exceptions) > > Since you are catching the exception, your thread is never stopped.. and > hence future-cancel returns false. > > If you throw again.. exception would unwind your while loop and stop the > thread. > hence.. future-cancel is able to stop the thread and returns true. > > -- > 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. > -- 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.
Re: macro question
> I know that this macro will add 2 to its argument:
This isn't what that macro does. That macro takes a piece of syntax, and
sticks that syntax in the hole in the expression (+ 2 HOLE). The
macro doesn't evaluate the expression, it just generates it. It is the
evaluation of *that* expression that yields the plus-two result.
The arguments to a macro are not values, they are syntax. The result of a
macro isn't a value, it's syntax. When you call (foo u), you are not
passing the value of u into the macro. You are passing in the syntactic
symbol u. That's why it says you can't add a Symbol to a Number. Your macro
is trying to compute (at "compile time") (+ 2 'u).
On Tuesday, January 26, 2016, <echigoyamont...@gmail.com> wrote:
> I'm new to clojure and macros and am having trouble wrapping my head
> around some simple things.
>
> I know that this macro will add 2 to its argument:
>
> user=> (defmacro plus-two [x] `(+ 2 ~x))
> #'user/plus-two
> user=> (plus-two 5)
> 7
> user=> (def u 10)
> #'user/u
> user=> (plus-two u)
> 12
>
> I tried the following just to see what will happen and don't understand
> what's going on:
>
> user=> (defmacro foo [x] (+ 2 x))
> #'user/foo
> user=> (foo 5)
> 7
> user=> (foo u)
>
> ClassCastException clojure.lang.Symbol cannot be cast to java.lang.Number
> clojure.lang.Numbers.add (Numbers.java:128)
>
> I tried quoting the plus:
>
> user=> (defmacro bar [x] ('+ 2 x))
> #'user/bar
> user=> (bar 5)
> 5
> user=> (bar u)
> 10
>
> This makes sense, since (bar u) is the same as + 2 u (without
> parentheses), which returns u. But I don't understand what's happening with
> foo, and I can't check it with macroexpand since that gives the same error.
> Is there a way to recreate this error without defining a macro?
>
> Thanks in advance for any and all responses.
>
>
> --
> 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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','clojure%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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/d/optout.
>
--
-- Dan Burton
--
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.
