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.
