Fork me on GitHub
#cljs-dev
<
2020-06-27
>
dpsutton19:06:25

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&amp;orderby=priority%20DESC

dnolen19:06:32

@dpsutton I think you're suggesting changing ClojureScript but that's not really desirable

dnolen19:06:40

the bug is most certainly in core.async

dnolen19:06:55

(but maybe I'm misunderstanding)

dpsutton19:06:29

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

dpsutton19:06:05

And I was hoping someone here might know of an easy way to prevent it

dnolen19:06:32

there are probably easy ways but I would say not really interested in that

dnolen19:06:54

would rather fix core.async fundamental issues than to continue to play whack-a-mole

dnolen19:06:09

we may do other optimizations

dnolen19:06:17

anyways no changes to ClojureScript

dnolen19:06:33

that said - there's nothing wrong with intercepting at core.async

dnolen19:06:14

optimizations are kind of meaningless in a go block

dpsutton19:06:53

Yeah agreed

dnolen19:06:55

that is optimizations that ClojureScript would do, since the go block is going to rewrite everything in case you might park

dnolen19:06:47

so probably you could do something such that or and and have a core.async specific macroexpand

dnolen19:06:13

another alternative that I would accept that's less hacky that does involve changes to ClojureScript

dpsutton19:06:17

Ohh. I hadn’t considered that. And that’s what I guess I was fundamentally trying to do

dnolen19:06:25

is a optimization pass instead of doing it via macros

dnolen19:06:45

this is probably the most "correct" option

dnolen19:06:37

an interesting side benefit would be that nested if could always be optimized

dnolen19:06:46

versus the hard coding at and or

dnolen19:06:04

then core.async and ClojureScript wouldn't interact at all really

dnolen19:06:20

because the go block obviously won't optimize, but normal code would

dnolen19:06:12

it's probably easier than it may sounds since this is Clojure

dnolen19:06:45

if you have a '`if` case you can check the test, check the branches

dnolen19:06:51

and collapse the AST if possible

dnolen19:06:29

at which point you can restore the old and or macros

dnolen19:06:36

and this core.async problem goes away

dnolen19:06:02

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

dpsutton19:06:31

can i make a jira ticket about this?

dnolen19:06:33

please do!

dpsutton19:06:01

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?

dpsutton19:06:15

i can't tell if that's hacky or using the exposed API as intended

dnolen19:06:23

to be honest I really do think the last option is the right way to go

dpsutton19:06:33

the changes to cljs?

dnolen19:06:38

meta flag and core.async special casing are both complecting options

dpsutton19:06:53

i agree. and i suppose with the workarounds listed in the ticket it can wait a bit for that

dnolen19:06:54

where one has to know about the other

dpsutton20:06:12

thanks for your insights on a saturday

dnolen20:06:14

whereas a optmizing pass just gets rid of the problem

dnolen20:06:51

but also optimizes more stuff

dnolen20:06:41

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

dnolen21:06:47

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

👍 4
thanks3 1
dnolen21:06:42

it would be nice to run tests against the most critical tooling, Figwheel, Shadow, Reagent, etc. so pondering that

dnolen21:06:30

but we can also do some browser based testing (REPL testing) to get some sense of coming breakage from Closure and Closure Library

dnolen21:06:59

other thing is we could now easily collect performance metrics for runtime and compile time and collect that somewhere

dnolen21:06:20

will do some of these, but also very interested in contributions for the above

dnolen21:06:49

re: testing N JS runtimes it does seem we can maintain our JS VM matrix approach w/o worrying about super long build times thanks to GH Action caching