it looks like you can access it both ways in node.js

Hum, ok that explains it. If I couldn't access it through js/performance, how would I go about accessing it through perf_hooks? I couldn't figure it out

(.. js/perf_hooks -performance now)

performance is a standard global, so maybe the node docs are just outdated or forget to mention that part. its also available in the browser

Oh, maybe docs were wrong, cause when I tried js/perf_hooks it said can't find JS for that name

@U0K064KQV What are you using this for? I recently made an async version of time - wondered if you also needed that maybe :)

user=> (nbb.core/time (p/delay 1000 :hello))
"Elapsed time: 1000.643083 msecs"
:hello

That was my use case ya. Wanted to time how long two go blocks took to run to completion. I'm surprised promesa doesn't have its own async time, might be a good addition to it

Indeed, that only occurred to me now

hm cljs dep doesn’t seem to bring in closure compiler as a dep

it should, both deps.edn and project.clj has it defined as a dependency: https://github.com/clojure/clojurescript/blob/0d5b1baddacc590b60979c77c2353f8ae32ed351/deps.edn#L3 & https://github.com/clojure/clojurescript/blob/0d5b1baddacc590b60979c77c2353f8ae32ed351/project.clj#L19

looks like you are calling (clojure.string/trim not-a-string) when it expects a string

might just be nil, or a keyword or something like that

oh that is one confusing type error then

thanks, I had a regression in my code

Usually when you come across Uncaught TypeError: X is not a function in JS (not just CLJS) and you're sure you're calling the right function, it's because you're calling the function on a unexpected object (`nil/null` instead of String for example), first thing to check would be that the type in runtime is what you expect it to be

It doesn't matter what the key is. Let alone what the contents of a string key are.

=> (def m {"もの" 1})
#'cljs.user/m
=> (m "もの")
1

Okay thanks for confirming that @U2FRKM4TW

😅

Also, I didn't know we could do (m k) that's a mind explode for me

Yep, described here: https://clojure.org/guides/learn/hashed_colls#_looking_up_by_key

And, in a bit more wordy way, here: https://clojure.org/reference/data_structures#Maps

-_- there was an invisible character at the end of the key

😅 brain melt 🫕

was just looking over http://ask.clojure.org and ended up here

the explanation given in that blog post is nonsense

primes is not closed over anywhere

global names are not closed over

the reason it terminates is because some is short circuiting

Ok well that blog post is just one of the two provided implementations with this problem and even if his reasoning is off (which I'm not saying it is since I didn't look into it), the problem that this works on Clojure and doesn't work on cljs still remains

Although yes I agree that if he says that primes is closed over, then he's wrong on that

And it's not “corecursive” either lol

It's just plain recursive

It did happen to be the shortest implementation I found and I like brevity (despite whatever misunderstandings its author apparently seems to be under)

for example, in clj you can do

(def primes (remove (fn [x] (some #(zero? (mod x %)) @(resolve 'primes))) (iterate inc 2)))

Yes I agree there's no closure. There's also no corecursion. He's confused

It doesn't even get to calling those function - it falls into the first iteration of some time and time again.

It's from the linked article. But remove uses lazy-seq which clears its inner function's locals on the first call - so the second call unconditionally returns nil. In CLJS, it doesn't.

This code

=> (def primes (remove
             (fn [x]
               (some #(zero? (mod x %)) primes))
             (iterate inc 2)))
=> (take 1 primes)

The docstring of lazy-seq in both implementations says: > yields a Seqable object that will invoke the body only the first time seq is called The difference is, in CLJ entering a function counts as an invocation in this case, and in CLJS exiting a function does. So in CLJ, a lazy seq can refer to itself as above, but in CLJS it cannot.

how can it not be intentional with the special metadata handled by the compiler?

but I'm not sure you've described this properly. the once is a hint that allows reference clearing (because it will only be invoked once), not sure if that's the difference you're actually describing

since the head of primes is held in a var here regardless, I don't think that actually matters

the outer primes var and the inner primes reference to the var refer to the same sequence instance, guarded by the same locks, this is all inherent in how seqs are implemented. I don't know how CLJS differs from this.

If you mean the other way of implementing primes you mentioned above, then it also seems to rely on :once because it also uses lazy-seq.

yes they both use lazy-seq

but also they should both work regardless of any implementation detail

from an abstract perspective

like just by reading their code and reasoning what should happen

and then you have the fact that that is actually what happens in clojure itself

how else would you expect lazy-seqs to work?

the reason this stack overflows has nothing to do with the problem being discussed, it is because you swapped remove with filter a not around some

some can short circuit

not some cannot

some is there exists

not some is for all not

obviously too late in the day for thinking about this stuff

it is :once that makes the difference, but primes is not closed over, so :once doesn't matter for it, :once only applies to the sequence produced by iterate

The inner primes becomes a local, right? It's not the var, it's a local binding. On the second call of the :once function (which happens only when we go beyond the realized part of the lazy-seq), it becomes nil - there's nothing to iterate over. That's why this pseudo-recursive iteration over a lazy-seq never unrolls itself from inside out. In any case, I'll create a question on http://ask.clojure.org then.

i just read the ask and your explanation regarding :once but I think that's kind of missing the point. Laziness is broken if this doesn't work as written. Try it in a language like Haskell where laziness is also default and it will work fine.

So, sure, if you wanna say that the fix is to add :once to CLJS, that's fine. It's an implementation detail that really doesn't matter from the perspective of the user however. All the user wants is for laziness to work.

I'm describing the cause in the post, I'm not offering any solutions let alone implementation details.

Looks like you're wrong about anything being closed over though. See the reply.

As @U0NCTKEV8 stated, the reason this works is the same reason the user expects it to work, namely the short-circuiting nature of some. So I think I was correct in objecting to your explanation & trying to persuade you away from the pontificating (which did not sit well with my gut).

The stackoverflow is the result of once, but the only thing once actually effects is the sequence created by iterate

And what sequence would that be?

I still consider that an implementation detail though. I'll bet this works in Haskell without the :once keyword appearing anywhere (Haskell doesn't have keywords so this is a sure bet) 😂

The sequence created by iterate that is the argument passed to remove

Yes but how is that sequence different between an impl containing :once and one that doesn't ?

That I am not sure about

It isn't that that sequence is different, what is different is remove or filter

Hmm interesting

They behave differently with or without once, and the difference is in regard to the sequence passed in as argument, the one created with iterate in this case

There is a closure in that code though: the lambda inside the anon fn closes over ‘x’

Sure, it closes over the argument to filter

The seq created by iterate

Right

It does not close over primes

Then this actually is co-recursive with one of the fns just being anonymous

It refers to primes via the var, and there is no locals clearing of it

Unnamed co-recursive

My entire reason for wading in on this is just people kept repeating the thing about closing over primes

If you pulled the fn closure out into a defn, this would be obvious

Which at least in the clj case is nonsense

But if that fn doesn't close over primes, then it isn't a closure as there's nothing else for it to close over

Or the example I gave, replacing primes with deref and resolve

Right