Antonin, It's an interesting theory and possibly not far from the truth, however I just counted my go loop which was experiencing the issue and I only have 3 <! operations. I suspect there is something else going on, but what exactly it is I can't say.
It's good to know that if I ever do run into a situation where I need 18 or more <! calls then a) there is a known issue which I'm now aware of and b) there's a workaround for it. I don't think having this many or even more calls is too complex at all. Cheers, Ali On Wednesday, March 21, 2018 at 2:43:02 PM UTC+5:30, Antonin Hildebrand wrote: > > Hi Ali, > > For usage please look at the commit which introduced that code (or search > current Dirac code base): > > https://github.com/binaryage/dirac/commit/cce56470975a287c0164e6f79cd525d6ed27a543 > > https://github.com/binaryage/dirac/search?q=chunkify&type=Code&utf8=%E2%9C%93 > > Further explanation: > My theory is that the go-macro can handle only limited complexity under > ClojureScript. When you hit that threshold the ClojureScript compiler ends > up entering infinite recursion. In my code the threshold was 18 async > operations (<!) inside a single go block. A workaround was to break complex > go block at hand into multiple smaller go blocks nested in a newly > introduced parent go block. That is what chunkify macro does - it rewrites > existing code to series of nested go blocks. > > I think this bug is triggered by a specific way how go-macro rewrites the > form. At some point it is probably emitting an apply call which triggers > CLJS-365. This bug has been unresolved because almost nobody is writing go > blocks so complex to hit this problem. > > But I might be absolutely wrong with this theory. I didn't really dive > deep and investigate the real cause. > > good luck, > Antonin > > > > > On Wednesday, March 21, 2018 at 5:33:00 AM UTC+1, outr...@gmail.com wrote: >> >> Hi Antonin, >> >> Thank you for the explanation and links. While the workaround that Moe >> suggested does indeed remove all occurrences of the issue, is this >> chunkify macro something that should be used somewhere in code, and if >> so do you know how? >> >> Best, >> Ali >> >> On Tuesday, March 20, 2018 at 8:41:44 PM UTC+5:30, Antonin Hildebrand >> wrote: >>> >>> Hi Ali, >>> >>> I believe I encountered the same issue. And believe it is a bug in cljs >>> compiler related to https://dev.clojure.org/jira/browse/CLJS-365. >>> >>> >>> https://github.com/binaryage/dirac/blob/5a373e11d5d03d7057769d170f2599117dbae4b0/src/automation/dirac/automation.clj#L27-L39 >>> >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fbinaryage%2Fdirac%2Fblob%2F5a373e11d5d03d7057769d170f2599117dbae4b0%2Fsrc%2Fautomation%2Fdirac%2Fautomation.clj%23L27-L39&sa=D&sntz=1&usg=AFQjCNGtEMGxX2Yrm8O-tUccvvNscTtW2Q> >>> >>> regards, >>> Antonin >>> >>> >>> On Tuesday, March 20, 2018 at 11:34:29 AM UTC+1, outr...@gmail.com >>> wrote: >>>> >>>> Moe, >>>> >>>> Great news: replacing cond with case got rid of the issue in all the >>>> cases I mentioned. Like you I can't explain it either but it's good to >>>> know >>>> there is a workaround. Thank you! >>>> >>>> Cheers, >>>> Ali >>>> >>>> >>>> On Tuesday, March 20, 2018 at 3:25:03 PM UTC+5:30, Moe Aboulkheir wrote: >>>>> >>>>> Ali, >>>>> >>>>> I don't have any colour on the underlying cause of the problem, but >>>>> I'd be interested to know whether you see it with 'case' as well as >>>>> 'cond', >>>>> as I vaguely remember running into something like this (in cljs, only). >>>>> >>>>> Take care, >>>>> Moe >>>>> >>>>> On Tue, Mar 20, 2018 at 7:33 AM, <outr...@gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I'm running into a very strange issue which, having searched the web, >>>>>> no one seems to have reported. >>>>>> >>>>>> In short, I have a go block similar to the following (simplified for >>>>>> posting purposes, however I can post the full code if required): >>>>>> >>>>>> (go >>>>>> (while true >>>>>> (let [[cmd event-args] (<! mouse-chan)]] >>>>>> ... >>>>>> (cond >>>>>> (= cmd :down) >>>>>> (let [ ... ] ...) >>>>>> >>>>>> (= cmd :in) >>>>>> (let [ ... ] ...) >>>>>> >>>>>> (= cmd :hover) >>>>>> (let [ ... ] ...) >>>>>> >>>>>> (= cmd :handle-down) >>>>>> (let [ ... ] ...) >>>>>> >>>>>> >>>>>> ) >>>>>> )) >>>>>> >>>>>> >>>>>> Essentially I have a number of mouse handlers (mousedown, mouseup, >>>>>> mouseover, mouseout, ...) which put! a [cmd event-args] vector onto >>>>>> mouse-chan, which is subsequently taken in the above block. >>>>>> >>>>>> Generally speaking, the block compiles successfully, however under >>>>>> certain conditions it just "breaks", specifically by producing a: >>>>>> >>>>>> java.lang.StackOverflowError >>>>>> >>>>>> during compilation. >>>>>> >>>>>> At present I have 4 branches within the cond block. Within one of >>>>>> those branches I have a loop/recur which takes (via <!) from the same >>>>>> channel as in the outermost block. This works absolutely fine until I >>>>>> try >>>>>> one of the following, which results in the above compilation error: >>>>>> >>>>>> * adding a fifth branch >>>>>> >>>>>> * with just the 4 branches in place, if I add even something as >>>>>> simple as the following expression: >>>>>> >>>>>> (when major-in >>>>>> (major-in event-args)) >>>>>> >>>>>> where major-in is either a function or nil >>>>>> >>>>>> * and the strangest thing of all, if I simply use *map >>>>>> deconstruction* at one point in one of the cond branches, I also get >>>>>> the same compilation error: >>>>>> >>>>>> (let [{:keys [x y w h]} (rect-ent-layout ghost-rect) >>>>>> ;; Even this doesn't work if I uncomment it and comment out >>>>>> the previous >>>>>> ;; {} () >>>>>> >>>>>> ] ...) >>>>>> >>>>>> but doing the following, which doesn't involve deconstruction, is >>>>>> fine: >>>>>> >>>>>> (let [stuff (rect-ent-layout ghost-rect) >>>>>> x (:x stuff) >>>>>> y (:y stuff) >>>>>> w (:w stuff) >>>>>> h (:h stuff)] ...) >>>>>> >>>>>> In terms of limitations on core.async go blocks, I am only aware of >>>>>> the functional boundary limitation, namely that you cannot create >>>>>> anonymous >>>>>> functions within a go block which perform any puts/takes, asynchronous >>>>>> or >>>>>> otherwise. Beyond that I can't find anything in the documentation which >>>>>> would indicate that there are any other limitations. >>>>>> >>>>>> I am also aware that some macros do create functions, e.g. for, but >>>>>> I am not using anything like that. >>>>>> >>>>>> I'm running a CLJS project with the following dependencies: >>>>>> >>>>>> [org.clojure/clojure "1.9.0-beta4"] >>>>>> [org.clojure/clojurescript "1.9.946"] >>>>>> [org.clojure/core.async "0.3.443"] >>>>>> >>>>>> I'm also using Reagent and developing using Figwheel. The Compilation >>>>>> Error in fact is show in a Figwheel overlay. >>>>>> >>>>>> I have tried to isolate the issue but I can't seem to pinpoint what >>>>>> exactly is causing it. >>>>>> >>>>>> Has anyone every come across something like this before when working >>>>>> with core.async, specifically the java.lang.StackOverflowError >>>>>> compilation error? If not, without posting the full code, can anyone >>>>>> see anything with the above code which might cause such an issue? >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Ali >>>>>> >>>>>> -- >>>>>> Note that posts from new members are moderated - please be patient >>>>>> with your first post. >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "ClojureScript" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to clojurescrip...@googlegroups.com. >>>>>> To post to this group, send email to clojur...@googlegroups.com. >>>>>> Visit this group at https://groups.google.com/group/clojurescript. >>>>>> >>>>> >>>>> -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
