Fork me on GitHub
Ben Sless09:07:38

Announcing first releases for: io.github.bsless/tools.jvm {:mvn/version "0.0.15"} - small utilities for inspecting the current JVM process; Which args did I launch with? What's my PID? What are the current JVM's properties? Additionally, has a function for launching VisualVM and attaching it to the current process repository: API: io.github.bsless/tools.jcmd.jfr {:mvn/version "0.0.3"} - Capture JFR recordings for the current JVM process or invoke as a tool repository: API:

πŸ™ 3
πŸŽ‰ 9
bmo 1

Heh, a funny coincidence in naming with

Ben Sless11:07:54

I knew it existed, but the naming is too correct to pass. We use qualified naming anyway, so I hope Henry will forgive me

Ben Sless11:07:29

bsless/tools.jvm previously existed as introspector but I am terrible at naming things so opted for the least creative name I could πŸ™ƒ


An interesting utility, thanks! I often have a need to get current pid in the REPL. I tend to use (-> (java.lang.ProcessHandle/current) .pid) but that's only for Java 9+. Does your lib require anything above Java 8?

Ben Sless09:07:06

Not sure about visualvm, but everything else was tested on java 8 - 17 on windows, macos and linux


Perfect. Btw. I noticed that pid returns a string while the method I shared above returns long, which is more accurate and convenient I think. Possible to change that?

Ben Sless09:07:38

Possible? Yes Should? Not sure. I get it as a string to begin with:

(defn pid
  "Get current JVM's PID as a string."
  (-> (runtime-bean)
      (str/split #"@")

Ben Sless09:07:42

I'd rather add another function that gets it as a Long

Ben Sless09:07:59

And uses processhandle when possible


Yeah, I know what your current implementation does right now. Just saying that you could coerce it because PIDs are numbers and also the canonical implementation (ProcessHandle) returns a number in later JDKs. But of course I have no problem if it stays the way it is πŸ™‚

Ben Sless10:07:01

I'll add another function, why not


Released a library for dependency graph computations, where computed values can be feeded into the next graph computation

πŸ’― 6
πŸŽ‰ 1

clojure-lsp Released 2022.07.24-18.25.43 with focus on performance improvements! πŸš€ There is a new experimental feature, which completely changes the way clojure-lsp analyze the project's code, not scanning the whole project after startup but only the current namespace and its dependencies, building and maintaining a dependency-graph, this feature should improve performance drastically, especially for huge projects with lots of files like metabase. For people interested, please help with tests and feedbacks enabling it via {:experimental {:dep-graph-queries true}} in your .lsp/config.edn. (Details about the performance improvement Besides that, we had many minor performance improvements and even new refactorings! Kudos to @jacob.maine for the huge help during this release! πŸ‘ Thank you for all sponsors and contributors! πŸ’œ For more information, check #lsp

nice 9
πŸŽ‰ 16
πŸ”₯ 8
clojure-lsp 4
Luke Johnson23:07:21

Thanks for all your continued updates! Your hard work makes my life so much easier! πŸ™‚ That said, I think there’s a problem between the latest version of clojure-lsp and Calva on VS Code. I started a

gratitude 1
Luke Johnson23:07:44

Okay. This was already fixed by @UKFSJSM38! Thanks so much! Amazing work!

πŸ‘ 1