It will be, if nothing else holds on to the huge seq.

"Don't hold on to your head" ☺️

Nice question! What does "hold on" mean though? Like if the seq is a value of a map and you pass around the map without dissoc'ing the seq even though you no longer need it, will the seq still never be GCed because the map is used? Or does the code have to actually use the seq?

The seq doesn't have to be used in the sense of operations running on it directly. But it has to be used in the sense that GC sees references to it.

To be more precise, I'm having issues with builtins like File/exists and SocketChannelImpl/close.

*warn-on-reflecion* is per namespace. Setting it in just one place will only enable it for that place. If you're using project.clj then it seems that you can add :global-vars {*warn-on-reflection* true} there.

Ah, I'm using deps.edn.

There's also the clojure.compile.warn-on-reflection property that you can set to true but I haven't used it myself.

Should work if you add to user.clj

(alter-var-root #'*warn-on-reflection* (constantly true))

IIRC, that will enable the warning for any loaded namespace, including the libraries.

Ah, using an extra main-arg in the run profile works as well.

Got it running with GraalVM, that's pretty nice.

https://github.com/clj-easy has misc projects that can further help you understanding/preventing issues with graalvm

The clj-easy repo I'd start with is https://github.com/clj-easy/graal-docs. There is also a #graalvm channel.

Seems like it belongs in #CLX41ASCS.

But the problem is that this is JVM REPL

You're saying in the OP: "I use babashka for this". Babashka is not a JVM REPL.

I use clojure tools deps. Sorry. This is what I meant. I'll fix it.

How exactly do you run your REPL? What is the minimal deps.edn that still exhibits this behavior?

This started happening when I updated my system today. It printed a message that ~/.deps.clj doesn't exist (then I thought "ok, I haven't seen this directory before") and then it proceeded to download a couple of JARs. It happens on an older project too that worked before. So I don't think it's a project config. I tested on two tools.deps projects. I'll try to come up with a minimal example.

When I copy deps.edn file into a new project without any changes (with everything intact) then it doesn't happen in a new project. On the old project it still fails if I use the clojure -M command like this (but not on fresh project). So it's surely not a babashka problem:

clojure -M:project/dev:project/debug:nrepl/interactive

Removing of .cpcache didn't help. Moving ~/.clojure and ~/.deps.clj directories didn't do anything. Moving ~/.m2 directory helped.... I nuked my .m2 directory twice during last 30 days... what's going on... Maybe it's my SSD

No idea. I haven't done anything to that directory in at least the last 5 years. Do you ever use mvn directly, specifically mvn install...? Do you depend on any snapshots, perhaps transitively? Next time something like this happens, instead of nuking random stuff I'd suggest trying a stepping debugger in order to understand where that bogus inst reader came from.

> I'd suggest trying a stepping debugger in order to understand where that bogus inst reader came from. I don't really have a real debugger in my nvim. But I still have .m2 directory. I just renamed it.

> I don't really have a real debugger in my nvim. Then it sounds like the first step should be getting such a debugger. :) Venturing outside of your main IDE for specific pieces of functionality is totally fine.

Also, while a stepping debugger is a better tool for some tasks, you can still do a lot in a plain REPL. In this particular case, there are *data-readers*, default-data-readers, and *default-data-reader-fn*. They are checked in this order. When you encounter a problem like this, you can always check where the inst tag reader is specified and inspect the value. The corresponding function, if there is one, will have some info about it (even if it's just its class name, which under normal circumstances includes the namespace).

> clojure -M:project/dev:project/debug:nrepl/interactive Maybe that's adding cider-nrepl? I hadn't heard of it formatting insts oddly, but some things are certainly printed in a custom way

(->> (-> (Thread/currentThread)
         (.getContextClassLoader)
         (.getResources "data_readers.clj"))
     (enumeration-seq)
     (distinct)
     (mapv str))

> Maybe that's adding cider-nrepl? It was. I got rid of all the directories as I want to do other things. But that's a good snippet. But then I didn't have any of the middlewares set up in my tools.deps global configuration files. And it actually downloaded some JARs into a new directory.

data readers are loaded simply by virtue of being in the classpath

happy you got it. TIL too (as I never thought of using this snippet for data_readers)

> data readers are loaded simply by virtue of being in the classpath I was playing with them long time ago and they also have to be in a special location, I think. Or those namespaces have to be imported to execute the top-level code.

Note that data_readers.cljc are also loaded.

> Note that data_readers.cljc are also loaded. Exactly. I think it loads this file if it's in the project first. And then proceeds to load everything else. This way the codebase won't start misbehaving randomly. It's not a very good idea to make your own. If they'll sometimes fail to load you won't be able to read your EDN.

The loading order doesn't matter and isn't forced since conflicting tags are reported as an exception.

clj -X:deps aliases

https://clojure.github.io/tools.deps.cli/clojure.tools.deps.cli.api-api.html#clojure.tools.deps.cli.api/aliases

This was a little surprising to me as well. This part of the documentation helped: https://clojure.org/reference/deps_and_cli#_other_programs I suppose the invocations listed under 'Other programs' are sort of special cases?

Oh man, I can't believe I missed that. It was there all this time, after all... time to walk away from the computer and go look at the grass or sky or something.

Incidentally I noticed the section for "Aliases"[1] trails off at "These Clojure CLI subprocesses use data which can be read from aliases:" I suppose "subprocess" refers to one of tool / resolve-deps / make-classpath-map etc [2]. [1] https://clojure.org/reference/deps_and_cli#_aliases [2] https://github.com/clojure/tools.deps/blob/be30a1ae275eabfd1eba571080e039451c122c69/src/main/clojure/clojure/tools/deps.clj#L807

If yes, I'm happy to submit a patch per the "small change" contrib instruction.

I only recently discovered clojure -X:deps aliases after looking at the api and spotting the aliases function. I was planning to submit an issue or pr to add it to the clojure --help output which would make it easier to discover

http://clojure.org doc issues/prs can go to http://github.com/clojure/clojure-site

if it's in tools.deps, or brew-install, probably easiest to file a question at https://ask.clojure.org

I took the liberty to send a "small changes" patch to update the deps and cli "Aliases" reference at clojure-site https://github.com/clojure/clojure-site/pull/669/files