you are going to need to handle errors in some way. if you are only using core.async for promise handling I strongly suggest to drop that entirely and just use promises directly

core.async go code is really annoying to debug

from js world (specifically jest) I remember that a test that throws an error (`async-await`) will print the error message

Is there some equivalent?

no, as the test handler has no knowledge of your channels or promises in any way

So I need to wrap each call with try/catch or .catch? Maybe a wrapper around the deftest?

every call no, where you are interfacing with the promise. one place should be enough.

I have just went over the project again, there are plenty of promises. Do you mean that each call to a promise should add a .catch? I don't understand how will it be a single place

well I cannot see your code, so I don't know how you are interfacing with promises in the first place

When having a go block, a rejected promise should throw it up to the caller, right?

core.async puts this Promise error onto the channel, it then throws it when reading from the channel. so if you don't have a try/catch anywhere then it just makes it into your go code

and ends up as an uncaught exception

a go block doesn't have a caller, so no

I think we have deviated a bit into core.async, there's something I probably don't undertand.

(defn c []
  (go (<p! rejected-promise)))

(defn b []
  (go (<! (c))))

(defn a []
  (go (<! (b))))

(defn a []
  (try (go (<! (b)))
     (catch :default e (println e)))

no

It's just a nightmare to use only promises, we have dependent calls, and it's a callback (`.then`) hell...

https://clojureverse.org/t/promise-handling-in-cljs-using-js-await/8998

makes it look more like async/await in JS

(defn c []
  (go (<p! rejected-promise)))

(defn b []
  (go (let [res (<! (c))]
        (js/console.log "result from c" res)
        res)))

(defn a []
  (go (<! (b))))

try that to check what you result you get from c. I'm fairly sure thats just nil, so the exception is lost in c already, it doesn't travel further

promises chain together to sort of carry the exception through, core.async does not

OK I see. Regarding js-await, it does create nested calls (pyramid like). I guess we cannot achieve something like js async await:

const f = async () => {
  const a = await promise()
  const b = await promise(a)
  const c = await promise (b)
}

try{ await f() } catch { ... }

as I said .. promises chain. so yes you can

something like that:

(defn my-async-fn [foo]
  (let [the-result (js-await (promise-producing-call foo))
        the-result-2 (js-await (doing-something-with-the-result the-result))]
    (calc the-result-2))
  
(try (js-await (my-async-fn))
     (catch ...))

thats not how you use that

Yes I understand, I'm saying, using js-await does create nested code

(defn my-async-fn [foo]
  (js-await [the-result (promise-producing-call foo)]
    (js-await [the-result-2 (doing-something-with-the-result the-result)]
      (calc the-result-2)
      )))

(js-await [the-result (my-async-fn)]
  
  (catch err
    ...))

await also creates nested code, its just visually not nested. semantically it still is

correct. so using js-await require a single catch block?

I cannot answer that without seeing what you are doing in the code 😛

in the example above yes

ok ill give it a shot. Thanks!

IMO this code that you posted

const f = async () => {
  const a = await promise()
  const b = await promise(a)
  const c = await promise (b)
}

(defn f []
  (-> (promise)
      (.then promise)
      (.then promise))
  ;; To make it behave the same as the JS fn above.
  (js/Promise.resolve))

> Because the JS fn above doesn't return anything

that is incorrect, it is a async fn, therefore it ALWAYS returns a Promise

Ah yeah, my bad, updated.

but I agree, .then is totally fine there

that adjustments makes no sense, just return the original promise chain 😛

I just wanted to make it behave in the exactly same way. :) So it's the JS function's fault it doesn't return the original.

I'm fairly certain that the async fn above only resolves once all the awaits are done, even if with no own return values. yours resolves immediately

(defn f []
  (-> (promise)
      (.then promise)
      (.then promise)
      (.then (fn [dismissed-result] js/undefined))))

maybe

Dang it. Yeah.

The problems I'm trying to overcome are: • A single catch block in the top scope • Using multiple promises results like:

const a = await foo()
const b = await bar(a)
const c = await baz(a, b)

If you chain promises (returning a new promise from a .then handler would also be chained), you only have to use .catch once. When you break a chain, you have to add another .catch. To catch any errors thrown while a promise is being handled when there's no corresponding .catch, you can listen to the unhandledrejection event globally.

The JS code above can be written as:

(let [ap (foo)
      bp (.then ap bar)
      cp (.then (js/Promise.all [ap bp])
                (fn [[a b]]
                  (baz a b)))]
  (.then cp
         (fn [c]
           ...)))

(-> (foo)
    (.then (fn [a]
             (.then (bar a) (fn [b] [a b])))
    (.then (fn [[a b]]
             (baz a b)))
    (.then (fn [c]
             ...)))

in my mind js async/await works exactly like the js-await macro looks. as in execute something, then execute the body or catch. there is no magic chaining going on in JS either, so technically the above translation is wrong

(.then (foo)
  (fn [a]
    (.then (bar a)
      (fn [b]
        (.then (baz a b)
          (fn [c]
            ...
            ))))))

but nobody likes that nesting 😛

Not sure I follow this time. In which scenario my code above wouldn't behave in the same way? > but nobody likes that nesting Yeah, that's why I immediately shied away from that. :D

yes, but then you have to do extra work to shuttle the results around. if you just have functions that capture those its fine.

Right. I was translating only the behavior, without any attempts to make the translation mechanically perfect.

ok guys I think ill opt out to .then , thanks

note that you can use .then and js-await interchangeably since its just raw promises without any kind of wrapper. both work seamlessly together

(-> (js-await [thing (foo)]
      (do-something thing))
    (.then something-else))

not that you'd do something like this, but it is fine to do

@U057T406Y15 in my opinion you could achieve your goal and get much nicer looking code by using the promesa library.

const a = await foo()
const b = await bar(a)
const c = await baz(a, b)

(:require [promesa.core :as p])

(p/catch
  (p/let [a (foo)
          b (bar a)
          c (baz a b)]
     ... resolve test condition here ...
    )
    (fn [err] ... do something with error ...))

If you literally just want to catch the top level error so you can print it then there is a feature in Node to do that:

process.on('unhandledRejection', error => {
  console.log('unhandledRejection', error.message);
});

thanks @UUSQUGUF3, I have just made the project to work so I won't try it right now, but I have written it aside (the promesa)

Definitely not an expert, but I'm pretty sure you have to either write a shader that does that or use a texture.

Any idea where to start on shaders? I only had a brief look as i've never written any before (all previous openGL work was with vertex and index buffers), and couldn't quite figure out how to structure them or access variables

Hold on, I'm actually probably wrong, checking.

The docs for aren't great. :(

And I'm pretty sure it has a bug. I can replace :fixed-color with :colors, according to the sources. But seems that I have to make it a vector of vectors, and it fails later when tries to fill a buffer with all those values.

@U0552GV2X32 Is this the expected image?

Just created an issue for that also shows how to implement the above: https://github.com/thi-ng/geom/issues/99

@U2FRKM4TW Yes, cool! Technically i'm drawing polygons each of their own color, but your example is the more general case

I'll see if i can get it to work now, thanks a lot for the help!

Glad to know i'm not crazy for struggling a bit with it