So this was what you helped me with, yesterday, @dpsutton and @seancorfield https://github.com/PEZ/taplet I notice that the tests are not as predictable as I would expect them to be. It sometimes seem like they write over each other’s atoms, but since they are locals that really can’t be happening. Anyway, I don’t understand why the tests get brittle. Not planning to put this in CI, though, so it is OK for now. Anyway, I have a bunch of questions about macros now, so will probably return here. Thanks again for the super duper support!

Hello. #vscode channel looks like forgotten, so sorry for asking here - is there any usable Clojure code formatter for VSCode?

Try #calva

Oh, I see you've already asked there.

Can't help sorry, not a vscode user.

Thanks, I used it several years before it becames unusable due to unswitchible lsp integration. Now I installed Clover, clj-condo linter and only one thing I need is formatter.

Hey folks, got a question for people who know there way around Java interop

I am using openhft Java runtime compiler to compile Java classes dynamically

Im getting to the compiling part just fine

But the class file contains Java interfaces and other class definitions etc

Now I’m wondering how I can load these files and symbols from the Java project into my clojure namespace to make it accessible to the compiler

I guess I need to put them on the classpath somehow?

@dev-hartmann a convention in some clojure projects is to have a directory classes where you emit these classes and then put classes in your :paths in deps.edn. For lein this directory is called target and it is on the classpath by default

Thx @borkdude I guess I can get maven to export the classes from the other project and cp them into a classes folder in my clojure project

or just add the other path to your :paths

:local/root + adding deps.edn in that project might also work, if the path is not within the project

Ah, interesting I’ll try

The other project is a pure Java project

I‘ll try adding it to my paths in deps.edn and maybe it works then 😎

@dev-hartmann if the other project has a pom.xml and the classes are on the classpath of that pom.xml, then you can use :local/root to add that project

Yes it has a pom.xml

Nice, I’ll read up on :local/root, thank you very much

Ah got it

I can import the complete project as a dependency but specifiying it is local 👌:skin-tone-4:

That’s awesome

Wow, seems to work

🤯

Now I just need to add the company private nexus to use everything

That’s just brilliant, thx a lot @borkdude !

Sure. Join #tools-deps if you have any other questions about this

Thx, will do 👍:skin-tone-4:

what would be a good way to block a thread until a channel (or atom) holds a specific value?

invert the problem, only put expected value on the channel and just use <!! ?

put a filter transducer on the channel and just take

you can use a watch on an atom

(defn when-is [a v] (let [k (Object.) p (promise)] (add-watch a (fn [a k ov nv] (when (= nv v) (deliver p true) (remove-watch a k)))) (when (= @a v) (deliver p true) (remove-watch a k)) @p)) ;; the order of args to the watch fn is likely wrong

and I forgot to deref the promise

Java 16 is out and I presume it works with Clojure. I know it brings strong encapsulation by default, so my question is: How does this impact Clojure ? https://jdk.java.net/16/release-notes

It does work with Clojure

Does not really impact Clojure much

no fancy compiler stuff related to record classes?

records are useful for java devs but boooring for Clojure devs

we already have boilerplate-free, immutable, transparent state carriers: maps

I do not care about the language level stuff in JDK 16, but the VM level stuff is absolutely massive

high-level SIMD API (Vector API, incubating) call C functions directly without writing a lick of JNI (Foreign Linker API, incubating)

> call C functions directly without writing a lick of JNI does this bring a Python-like FFI for C libs for Clojure a bit closer?

yeah, stay tuned, I'm cooking up something nice

niiice :) hope it works with GraalVM as well, can add it to bb and have more lib reach :)

it won't 🙂

graalvm is java11 based tops

GraalVM will update to 16 /17 eventually, but are there any technical reasons it shouldn't work?

I'm assuming you're doing something byte-code emitting related right?

yeah right now I’m spinning dynamic IFn -> MethodHandle proxies

ZGC max pause times from 10ms -> 1ms is very exciting too (heap size agnostic!)

TIL re: Java 16 — public constructors for the primitive wrapper classes (`Long`, Double, Integer, etc) have been deprecated since Java 9 (searches all his code, finds no such uses 😅 ).

do you mean they have been removed finally?

Not yet, but in Java 16 you’ll get warnings on their usage. And they will go away eventually. I’d just totally missed they’d been deprecated for so long!

oh i didn't realize 16 started emitting warnings about them. i knew they were deprecated for a while

I think they've been linting that for years if you check deprecation warnings

pretty sure we did a pass through Clojure source 2-3 years ago to fix up a couple

but you won't see it through Clojure interop, right?

(maybe clj-kondo can fix this)

oh, you mean if you used Clojure to invoke the Java constructor?

yes

should be able to lint that, I don't think you'd see it otherwise

\

you mean, should be able to lint that, who?

java, clojure, clj-kondo?

clj-kondo

like https://github.com/dakrone/cheshire/blob/master/test/cheshire/test/core.clj#L437

ok, I'll add an issue for it

https://github.com/technomancy/leiningen/blob/master/leiningen-core/src/leiningen/core/main.clj#L370-L371

just grepping a few quick examples, surely there are more

the clojure reflector already checks for "canAccess", is this something it could do too? or too much perf overhead / info not available in the JVM?

what I've found in the past is that canAccess will only give feedback when it's set to "deny", so it probably won't help until they actually turn it off

I don't think we want to be in the business of checking for specific invocations inside the reflector

linting seems like the right level of check to me

I agree about not adding specifics. Was just wondering if https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Constructor.html had a field "deprecated" or something, but it hasn't.

nah, I don't think there is any way to tell this programmatically

I mean I guess you could check for a Deprecated annotation on the method

I'll probably use that to generate a list of deprecated methods for linting

https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/Boolean.html#%3Cinit%3E(boolean) - you can see that the info is there and I think that's retrievable

the annotation has to be marked to be marked for runtime retention but that one should be

so, I'll change my answer - yes, it's possible to programmatically detect this in the reflector :)

should we is a separate question :)

pushing things to lint-time is better for performance ;)

yeah, that would need assessment. I would not be opposed to an ask.clojure question about this, might generally be a useful thing, at least as an option

surprising that I do not remember anyone asking about this before now

afaik clojure itself doesn't even warn about deprecated vars?

Oh does kondo not warn on this? Cider nrepl has done this for a while and it’s quite nice. I’m doing a month without nrepl and didn’t look into this yet

there definitely is a ticket about Clojure :)

https://clojure.atlassian.net/browse/CLJ-706

feel free to vote at https://ask.clojure.org/index.php/4625/make-use-of-deprecated-namespaces-vars-easier-to-spot

@dpsutton yes, kondo warns, but clojure doesn't

I didn't expect that (binding [*read-eval* false] (load "some/ns")) would still execute a contained #=(println 42) I guess there's no built-in way to forbid read-eval literals in clojure namespaces?

oh what a weird thing: (var + nonsense) -> #'clojure.core/+

and so threading last into a private function call at the repl is quite surprising at first. (->> foo #'ns/private-fn) yields ns/private-fn

Hi all, I am having a strange issue with spec instrumentation that throws where it should not... What is peculiar is that the instrumentation exception show this :via (notice the repetition):

[::report/report-identifiers
 ::report/report-identifiers
 ::report/image-descriptors
 ::report/image-descriptor
 ::report/image-id]

(s/def ::report-identifiers
  (s/keys :req [::id
                ::version-id]))