Clojurians Log v2

I cleaned up the windows logs for the failing and successful run and diffed them

the only real difference is that the failing run didn't have a cache hit I think? It has all these extra lines

then some of the file copy and compilation logs are in different order, but the total number is the same

would maybe help to try get it to fail with :pseudo-names true and/or source maps

to at least get a clue where it fails

then it's interesting enough that both the failed run and successful run actually fail in the same place... but one fails with a TypeError and the other one fails with a ReferenceError

failed run error

WARNING: 0 error(s), 65 warning(s)
Optimizing with Google Closure Compiler, elapsed time: 50287.5409 msecs
Optimizing 373 sources, elapsed time: 50927.9967 msecs
builds/out-adv/core-advanced-test.js:1130:94 TypeError: (intermediate value).Fi is not a function
Stack:
  @builds/out-adv/core-advanced-test.js:1130:94
  @builds/out-adv/core-advanced-test.js:7201:3
TypeError: Object doesn't support property or method 'Fi'
   at Anonymous function (C:\projects\clojurescript\builds\out-adv\core-advanced-test.js:1130:90)
   at Global code (C:\projects\clojurescript\builds\out-adv\core-advanced-test.js:14:3)
type test-out.txt
V8_HOME not set, skipping V8 tests
Testing with SpiderMonkey

(no "Testing ..." messages)

successful run error

WARNING: 0 error(s), 65 warning(s)
Optimizing with Google Closure Compiler, elapsed time: 51853.3191 msecs
Optimizing 373 sources, elapsed time: 52504.6602 msecs
builds/out-adv/core-advanced-test.js:7196:879 ReferenceError: test is not defined
Stack:
  @builds/out-adv/core-advanced-test.js:7196:879
  @builds/out-adv/core-advanced-test.js:7201:3
ReferenceError: 'test' is not defined
   at Anonymous function (C:\projects\clojurescript\builds\out-adv\core-advanced-test.js:7196:847)
   at Global code (C:\projects\clojurescript\builds\out-adv\core-advanced-test.js:14:3)
type test-out.txt
V8_HOME not set, skipping V8 tests
Testing with SpiderMonkey

(lots of "Testing ..." messages)

oh, there's another difference... the downloaded version of <http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/jsshell-win64.zip> seems to have a difference file size

heya, following up on that discussion about core.async.interop last thursday on #clojurescript

I put up a repo with the <p! macro along with a guide in https://github.com/filipesilva/async-interop

cc @dnolen @thheller @lilactown @didibus (as you were the most involved in this discussion)

the guide is in .adoc and structured so that it could go on https://clojurescript.org/, in the guides section

meanwhile it's also published to clojars as async-interop

is this a good way to put forward a proposal?

just skimmed the code, I would recommend looking into promise-chan here: https://github.com/filipesilva/async-interop/blob/master/src/main/async_interop/interop.cljs#L6 see https://clojure.atlassian.net/browse/ASYNC-103

additional discussion here: https://github.com/binaryage/chromex/releases/tag/v0.6.0

I copied that code almost verbatim from David post in https://clojurians.slack.com/archives/C03S1L9DN/p1572541632221300 (but changed the exception to throw the original error)

will have to read up on promise-chan, I don't know anything about it

@filipematossilva I would argue that you don't want to throw the original error

though it is a matter of taste - if you annotate the thing then you know it was in fact a promise error immediately and not some other kind of issue

one problem with promises is that you can call reject with any kind of value you like

it doesn't need to be a instance of error

I think I see what you mean

adding a new test for a value shows the problem

(deftest interop-catch-non-error
  (async done
         (let [err "Rejected"]
           (go
             (is (= err
                    (is (thrown?
                         js/Object
                         (<p! (js/Promise.reject err))))))
             (done)))))

D:\sandbox\async-interop\.shadow-cljs\builds\test\dev\out\cljs-runtime\cljs.core.async.impl.ioc_helpers.js:106
throw e29069;
^
Rejected

so the gotcha here is that the macro should throw the ex-info and the consumer should do ex-cause themselves

@darwin I'm trying to figure if promise-chan would improve anything or fix any broken semantics, but I don't think it does?

as long as <p! itself is called with a promise, the promise semantics stand

e.g. this works

(deftest interop-consumer-semantics
  (async done
         (go
          (let [p (js/Promise.resolve 42)]
            (is (= (<p! p) 42))
            (is (= (<p! p) 42))
            (done)))))

because the p->c function is calling .then on the promise itself

the resulting channel itself doesn't have promise semantics however, but I'm not sure it should either

I'm not sure if it's correct for the p->c function to not close the channel itself after a value though...

I looked again and <p! has correct semantics, it does not expose internal channel and each usage is creating a new channel, but if someone was using async-interop.interop/p->c directly, he could run into the issue that only one consumer wins taking result value

this should not work, I believe

correct, that hangs

with promise-chan it should work

I guess the question then is, should it hang or not? or rather, should p->c offer chan or promise-chan semantics?

that's a good point - promise-chan is better

depends if you want to make p->c public, people might want to do something further with the channel, e.g. alts! or pipelines or something

but in that case they might want to implement their own p->c and not rely on your code, don’t know

this is just about interop

you don't need lots of options in my opinion

tbh I don't have a very good POV on what should be the canonical usage... I just wanted to get the ball rolling on David's proposal of some official interop, and if both of you think promise-chain is better, then better it is

if you want to trivially translate async/await code promise-chan is better

fewer suprises

another argument might be that promise-chan might be also more lightweight, I have this feeling that normal channel must support “queues”, but promise-chan can just remember one value, so it is potentially lighter, but I don’t know exact impl

yes that was the original intention

pushed and released

what should be my next steps to move the proposal along? maybe open a JIRA issue with the patches to core.async and a PR to clojurescript-site?

just make a JIRA issue to core.async

I was playing lately with compiler extension to emit async/await hoping that Closure can take care of compiling it down to whatever needed. But then realized that because of scoping rules and the fact that await can't be used outside of async function, even if JS gets do {} expressions it's still has to be compiled into IIFE, when targeting older browsers.

do expressions proposal also discusses 'async do {}' blocks, but that's just too much :D

I've also been looking over core.async

updating ClojureScript core.async to match Clojure looks a like a pretty boring exercise - it could have been done long ago by anyone

after that's done I don't think it would be very hard for someone to limit the scope of the transformation to compete w/ existing state machine compilation support for async/await

@dnolen here's the JIRA issue: https://clojure.atlassian.net/browse/ASYNC-230