Short answer is: Do not use core.async for promise interop

JS doesn't have the concept of rethrowing exceptions like Java, so doing that is lossy

what about propagations? core async makes the stacktrace disappear?

like I said .. do not use core.async for this. Browsers have special support for Promises and async stacktraces, which is built-in and not extensible. Since Browsers do not know core.async they cannot do this stichting together of traces

not core.asyncs fault, just a limitation of the platform

macros suggested in the linked post make sense

Alternative to what? hash? Or the engine? Why do you need to compare hashes in the first place?

a different way to hash floats to use as keys in a map

comparing hashes is how hash maps work no?

To an extent.

You can store keys in a map that all have the same hash. But since those IDs are small, they will all have the same hash, which will result in O(n) access/insertion times. You can't override the built-in hash, but you can create an alternative map data structure implementation that uses a different hashing. E.g. you can first (* id 1000000) and hash it after or something like that. Alternatively, you can use a tree map. Both approaches introduce an issue where you have to painstakingly make sure that the map type is the one you expect.

Also, maybe the multiplication route is not feasible if the numbers can get quite big. In that case, it would make sense to come up with a proper hashing approach.

yeah, I'm aware of the degenerate behavior 🙂 it's not the behavior in clojure or any other language i've used, so it's surprising. custom map type doesn't sound bad, just have to be careful about using these handles anywhere else I guess

Heh, but the underlying implementation uses u32 for IDs.

There's at least one instance where the bindings split some ID-looking f64 into two u32. Perhaps you can do the same and have a map not like id->something but [u32, u32]->something.

I just converted the ID handle back to the js object it represents to use that as the key instead, I hash it elsewhere already so goog/getUid should already be cached, guessing it's pretty fast anyway

Just in case - getUid mutates the object. If that object cannot be mutated or is recreated, the value will be wrong.

cljs.user=> (def x (js/BigInt 7))
#'cljs.user/x
cljs.user=> (hash x)
1
cljs.user=> (hash x)
2
cljs.user=> (hash x)
3

what a language. 2 number types, neither safe to hash

To be fair, the issue with BigInt comes from CLJS. :)

Or from the fact that JS doesn't care about hashes. Somehow.

the issue is we use JavaScript numerics for performance and interop reasons

the hashing thing doesn't really have anything to do w/ JavaScript - JavaScript doesn't have hashing

https://clojure.atlassian.net/browse/CLJS-3410

I added a bunch of comments on how I think it can be done - happy to see someone try it - will take look soon if no one else does

https://github.com/clojure/clojurescript/pull/220/files

Curious - is that if-not a personal preference? Also, are there any notable performance considerations?

no, it's just a macro for (if (not ...) ...)

Oh sorry, by "performance considerations" I meant the hashing approach, not if-not.

... but it did remind to add a missing ^boolean

when it comes to hashing I just defer to whatever Clojure does - and if it bottoms out in JDK whatever JDK does

> ... but it did remind to add a missing ^boolean Oh... huh. Is there no way to do that automatically for all the known methods that always return a boolean? I feel like there's been a discussion or maybe even an issue about but can't recall exactly.

hrm, you're right that we can figure this out from externs, but I don't know if this case works

I believe fixed, thanks for the report - https://github.com/clojure/clojurescript/commit/54c27fbdf884142ac4e0d9d4ed38ec119905f17e

What user action results in this exception? Seems like printing some object. So I'd inspect that object.

what is the full trace?

my first guess would be printing an atom containing itself, but that would have a deref in the trace

That is the full stack trace that is printed. No user action, just loading my app. Printed by React ErroubBoundary, I know this happens in one particular component. But cannot find out what is trying to print what.

Yes, I too suspect it is some infinite data problem, just need to find out where.

you can usually set a breakpoint in the browser devtools and just step out

that should usually take you to the problem code

The question is where to set it 😅

any of the above lines works

> But cannot find out what is trying to print what.

Thank you, that helped!

this could just be a side effect of something else calling theObject.toString() which invokes the printer

When fulcro inspect installs itself, it tries to print something that blows up it seems.

Though the paticular line is (log/info "Installing Fulcro 3.x Inspect" {}) so it is perhaps soemthing in Timber’s context or something…

Do you have *print-level* bound? https://clojuredocs.org/clojure.core/*print-level*#:~:text=*print%2Dlevel*%20controls%20how,the%20maximum%20level%20to%20print.

my bad, it might not be that pr-write that triggers the exc. but an earlier one 😅

FYI I found it, it was my own pr-str one place in the code

I guess the thing I tried to print was simply too large

Thank you all for your help!

"too large"? In a sense, but a stack overflow makes me think the "size" had to do with depth, and possibly a cyclic structure. That is why I asked about *print-level*. Binding that to some modest integer will let you see much of the data, but only so many levels deep.

You are most likely right that there was a cycle.

If so, (binding [*print-level* 3] (prn <cyclic data>)) (untested) should work.

indeed, it did, thanks!