Clojurians Log v2

made some enhancements to clj-kondo which utilizes type hints. it found this: > cljs/util.cljc:361:19: error: Expected: integer, received: nil. https://github.com/clojure/clojurescript/blob/a760439b5084937a556712d6ee056e95f4f075c7/src/main/clojure/cljs/util.cljc#L359 that begs the question if the type hint is correct when the value can also be nil.

see also: https://ask.clojure.org/index.php/8574/why-doesnt-string-index-of-have-a-long-return-type-hint

That is a boxed Long. References can be nil, primitives cannot?

If you are referring to the ^Long type hint on the parameter n, that is.

If the type hint on n were ^long, I would wonder about the type hint, too, but I can't see a reason for ^Long being incorrect.

Yeah, and there is that whole notion of ^long and ^double being type declarations (they are evidently special).

I think they cause the compiler to emit an impl of one of these interfaces: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L97-L454

I was planning to make some fixes to the core.rrb-vector library, which has both Clojure/Java and ClojureScript implementations in the same repository. I wanted to set up automated running of ClojureScript tests for core.rrb-vector, which I think it does not right now. Alex Miller mentioned data.xml as an example of an existing library that does. I am starting to look into how that is set up, and noticed from the build logs that it is running the nashorn JavaScript runtime, and at least with JDK 11 it is starting to give deprecation warnings about nashorn maybe being removed in a future release.

If I was setting up running ClojureScript tests for core.rrb-vector, would you recommend I do it using nashorn so that it matches what data.xml is doing, and they can both be fixed if/when it is removed in the future? Or would you recommend I figure out how to set up a different runtime to run on the Hudson build box?

(or look at a different example than data.xml, that already uses a different JS runtime, if you know of such an example)

Ahh cool. This is consistent with where I got this from: Clojure Programming p. 439

ah, so ^Long is nilable, gotcha

@andy.fingerhut May be of interest: https://clojure.atlassian.net/browse/CLJS-3088 (removed Nashorn from ClojureScript's CI) https://clojure.atlassian.net/browse/CLJS-2927 (a patch to suppress that deprecation warning) IIRC, core.rrb-vector supports self-hosted, so if feasible, I'd incorporate self-hosted into its test suite.

(As an additional thing, beyond regular JVM ClojureScript.)

Thanks for the links. I don't yet have a good working knowledge of what it means to run self-hosted tests vs. nashorn vs. some other option. My belief is that the http://build.clojure.org automated test results are all run on a machine running Hudson software, not using Travis, true?

Erm, or perhaps Jenkins, not Hudson, there.

Oh, yeah, that's a world that I'm not familiar with.

Sure, and please don't dive into it unless it sounds like your world of fun, which seems unlikely 🙂

Is your guess that this nashorn warning thing might be "they will actually leave the deprecation warning around until JDK 15, when they actually get around to removing it?"

That's a good question. I'm wondering / speculating if Graal.js is supposed to replace it. Dunno.

If it might be a ways off, I may be a bit lazy and just make core.rrb-vector as much like data.xml as I can, so easier to update them in a common way later.

Yeah

I was mainly looking for a reaction like "nashorn? Never, ever test with that any more -- it's too ancient to be of any use" vs. not that reaction 🙂

> I'm wondering / speculating if Graal.js is supposed to replace it. That's my understanding.

https://medium.com/graalvm/oracle-graalvm-announces-support-for-nashorn-migration-c04810d75c1f

m