This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-27
Channels
- # announcements (1)
- # babashka (2)
- # beginners (64)
- # cider (1)
- # cljs-dev (49)
- # cljsrn (2)
- # clojure (49)
- # clojure-europe (3)
- # clojure-norway (1)
- # clojure-spec (7)
- # clojurescript (116)
- # conjure (3)
- # cursive (4)
- # datomic (1)
- # emacs (2)
- # fulcro (15)
- # graalvm (10)
- # kaocha (1)
- # leiningen (4)
- # meander (1)
- # music (1)
- # off-topic (7)
- # re-frame (37)
- # reagent (3)
- # releases (1)
- # rewrite-clj (6)
- # sci (4)
- # shadow-cljs (16)
- # sql (8)
- # tools-deps (16)
- # xtdb (5)
would love eyes on the comments for the following ticket. I think i'm on the right track just wondering if there would be some useful insight from the cljs dev side: https://clojure.atlassian.net/projects/ASYNC/issues/ASYNC-91?filter=allopenissues&orderby=priority%20DESC
@dpsutton I think you're suggesting changing ClojureScript but that's not really desirable
Core async works on the macro expanded form. “and” has an optimization that if it could be suppressed, everything works fine. The hope was there’s an easy way to prevent the optimization
that is optimizations that ClojureScript would do, since the go block is going to rewrite everything in case you might park
so probably you could do something such that or
and and
have a core.async specific macroexpand
another alternative that I would accept that's less hacky that does involve changes to ClojureScript
Ohh. I hadn’t considered that. And that’s what I guess I was fundamentally trying to do
but definitely not interested in meta flag here for ignoring stuff - yes it's an expedient pattern you'll find in ClojureScript implementation - but I think not well suited for this problem
also, as a temporary measure before the ast-based passes can be implemented, what would "or and and have a core.async specific macroexpand" look like? Do i update in the environment passed to macroexpand?
i agree. and i suppose with the workarounds listed in the ticket it can wait a bit for that
and also sets a better precedent, there a couple other hard coded optimization cases that could either reuse the above or be based on it
made some headway w/ GH action based testing - basics should be done by tomorrow - this definitely simplifies some things I've long wanted to do
it would be nice to run tests against the most critical tooling, Figwheel, Shadow, Reagent, etc. so pondering that
but we can also do some browser based testing (REPL testing) to get some sense of coming breakage from Closure and Closure Library
other thing is we could now easily collect performance metrics for runtime and compile time and collect that somewhere