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.
