Clojurians Log v2

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

the bug is most certainly in core.async

(but maybe I'm misunderstanding)

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

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

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

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

we may do other optimizations

anyways no changes to ClojureScript

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

optimizations are kind of meaningless in a go block

Yeah agreed

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

is a optimization pass instead of doing it via macros

this is probably the most "correct" option

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

versus the hard coding at and or

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

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

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

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

and collapse the AST if possible

at which point you can restore the old and or macros

and this core.async problem goes away

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

can i make a jira ticket about this?

please do!

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 can't tell if that's hacky or using the exposed API as intended

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

the changes to cljs?

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

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

where one has to know about the other

thanks for your insights on a saturday

whereas a optmizing pass just gets rid of the problem

but also optimizes more stuff

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

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

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

Very cool