Unlike you (involved in all three), I'm involved in 0 of the tools. >From a very short-sighted view, it seems the problem is that "lein configuration" is "not clojure code."
It seems what I want is to setup core.async channels: * a channel that gets an item whenever my foo/cljx directory changes * a channel for cljx to notify cljsbuild that foo/out-cljs has new data and should be recompiled On Sat, Mar 22, 2014 at 8:19 AM, Chas Emerick <c...@cemerick.com> wrote: > Despite numerous requests, I have so far resisted integrating cljsbuild, > cljx, and clojurescript.test. I noted my sentiments on this topic in a > comment here some time ago: > > https://github.com/lynaghk/cljx/issues/25 > > I haven't thought about it much since then, but I suspect I will relent at > some point. That said, any "integration" amongst these various tools will > need to be open enough that alternatives can be used as desired (e.g. surely > clojurescript.test is not the last word in ClojureScript testing??). > > - Chas > > > On 03/22/2014 05:26 AM, t x wrote: >> >> I stopped using cljx, and "lein cljsbuild auto" is amazingly fast. >> >> It does look like timing issues / how cljx/cljsbuild auto triggers >> work is the issue. >> >> Someone (that happens to be suffering more from this issue) please fix it. >> :-) >> >> On Fri, Mar 21, 2014 at 4:31 PM, Moritz Ulrich <mor...@tarn-vedra.de> >> wrote: >>> >>> I really hope that a small plugin to coordinate cljx/cljsbuild will show >>> up in the near future. I found cljsbuild's crossovers much better >>> integrated and easier to use (but still far inferior to cljx). >>> >>> I agree that a REPL based workflow is much superior, especially with >>> tools like Om which remove the need to coordinate DOM updates. >>> >>> Chas Emerick writes: >>> >>>> This particular trick is a clever one (that I'm afraid I've had some >>>> hand in propagating, for the benefit of those that like an "auto" + >>>> browser refresh workflow), but it's never going to be particularly >>>> efficient. By its very nature, pdo sets up cljx and cljsbuild off and >>>> running without any coordination; it's equivalent to running the two >>>> tasks in separate processes. >>>> >>>> It's possible that some hooks may become available in cljsbuild so that >>>> things like cljx can do what they like prior to each compile, but that's >>>> speculative. >>>> >>>> IMO, a REPL-based workflow is far superior to anything involving >>>> reloading your app's page, insofar as you can (nearly always) apply the >>>> changes you're working on without blowing away the state of the app. In >>>> this context, cljx's nREPL middleware excels (but unfortunately cannot >>>> be used with the stock ClojureScript browser-REPL; check out Austin). >>>> >>>> Note that cljx has not been optimized _at all_. It's "fast enough" for >>>> my purposes (i.e. reasonable when doing a clean rebuild, and snappy when >>>> doing the small changes typical in a REPL). I'd be happy to merge >>>> reasonable patches that make the actual cljx transformation faster. >>>> >>>> - Chas >>>> >>>> On 03/21/2014 01:23 PM, t x wrote: >>>>> >>>>> I'm using: >>>>> >>>>> "lein pdo cljx auto,cljsbuild auto dev' >>>>> >>>>> However, maybe perhaps it's weird timing interaction between cljx and >>>>> cljsbuild that's making the lag appear more than it actually is. >>>>> >>>>> On Fri, Mar 21, 2014 at 8:27 AM, David Nolen <dnolen.li...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Unless you're compiling a very large file - with auto :optimizations >>>>>> :none >>>>>> you should always get sub-second compile times under auto. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge >>>>>> <tbaldri...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> are you using "lein cljsbuild auto" ? That's what I use, and I get >>>>>>> about >>>>>>> 1-3 sec recompile times for stuff that uses core.async. >>>>>>> >>>>>>> Timothy >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 21, 2014 at 12:48 AM, t x <txrev...@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> * I'm already using: >>>>>>>> >>>>>>>> :incremental true >>>>>>>> :compiler { :optimizations :none } >>>>>>>> >>>>>>>> * I'm also aware of cljs brepl >>>>>>>> >>>>>>>> >>>>>>>> However: >>>>>>>> >>>>>>>> 1) the cljs compiler is still too slow for my liking (even though >>>>>>>> it's >>>>>>>> not calling closure) >>>>>>>> >>>>>>>> 2) I don't like the cljs repl nearly as much as I like the clj repl >>>>>>>> >>>>>>>> >>>>>>>> Now, my dumb/stupid question: >>>>>>>> >>>>>>>> Is there any cljs in cljs _slow_ interpreter? I'm perfectly >>>>>>>> happy >>>>>>>> with an interpreter that runs 10x slower, if, in exchange, I get to >>>>>>>> hit "refresh" and my new code starts running. >>>>>>>> >>>>>>>> Furthermore, I'm _okay_ with their being a big delay every time >>>>>>>> I >>>>>>>> introduce a new macro from clj land. >>>>>>>> >>>>>>>> >>>>>>>> I realize this sounds spoiled -- but -- the cljs compiler delays >>>>>>>> are >>>>>>>> really really breaking my flow. >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> "One of the main causes of the fall of the Roman Empire was >>>>>>> that-lacking >>>>>>> zero-they had no way to indicate successful termination of their C >>>>>>> programs." >>>>>>> (Robert Firth) >>>>>>> >>>>>>> -- >>>>>>> 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. >>> >>> >>> -- >>> Moritz Ulrich > > > -- > 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.
