Can you recommend a good clojure lenses library? The two that come up in my google search are pretty old

I cannot

https://github.com/redplanetlabs/specter/ is the Clojure version of lenses

please correct me if I’m wrong. From my understanding reducer is what prevent the creation of intermediate collections. (https://clojure.org/reference/reducers) Quote: A reducer is the combination of a reducible collection (a collection that knows how to reduce itself) with a reducing function (the “recipe” for what needs to be done during the reduction). The standard sequence operations are replaced with new versions that do not perform the operation but merely transform the reducing function. Execution of the operations is deferred until the final reduction is performed. This removes the intermediate results and lazy evaluation seen with sequences. I think of transducers as a generic way to define a process that can work without the context of what the input is

oh i see. honestly, i've never used the reducers. And they predate transducers so i'm not sure there's a real need for them any longer

You may get parallelism if the coll is foldable (persistent vectors or maps)

So in this example, range does not return a foldable (it's actually a highly optimized self reducible object, but not foldable)

arguably a bug. the implementation of with-local-vars creates the vars first, and then assigns the initial values to them

so the second x in (with-local-vars [x x] will refer to the just-created var

https://github.com/clojure/clojure/blob/clojure-1.10.1/src/clj/clojure/core.clj#L4352 source

decode is not a static method.

Indeed, this is how use it...

Hmm. But the Base64$Decoder is a static class. 😮

Wait so how can I use it?

(:import
   [java.nio.charset StandardCharsets]
   [java.util Base64]))

(defn ^:private base64-decode
  [verification-code]
  (-> (.decode (Base64/getUrlDecoder) verification-code)
      (String. StandardCharsets/UTF_8)))

something like that

I normally declare the getUrlDecoder as a def, like this:

(def ^:private url-safe-decoder (Base64/getUrlDecoder))

Yeah. But why I can't call the public method of the static class.

Because relative to that class, that method is not static. And you're calling it as if it is.

Indeed, have a look at the source code for the class, both encode and decode are non-static methods

they need an instance to work with

Here, for example, is where an instance is created

Which is then used here

Hope that helps! 🙂

@UJ1339K2B

(.decode (Base64/getDecoder) "aGVsbG8=")
#object["[B" 0x59c13f3e "[B@59c13f3e"]

It returns a byte array, you have to give it to a string to get out a string

(see above)

oh, that’s what i expected. the javadoc says it returns a byte array: > byte[] decode(String src) > Decodes a Base64 encoded String into a newly-allocated byte array using the Base64 encoding scheme.

Ok thank you so much. After reading the source code I have understood my mistake. Thanks!! @U11EL3P9U @U06TTFDB8 @U2FRKM4TW

just for practice’s sake, i tried using .. :

(.. (Base64/getDecoder ) (decode "aGVsbG8="))

Millions of dollars of Microsoft investment

For instance, letting you almost seamlessly work from a cloud instance

So hypothetically, not that this is a good idea, I can drop a vscode-server on a live-server, run a repl remotely, and then connect to it locally ?

You don't need a vscode server to do that now - that works with all these tools using a remote repl

There's even an example of remote desktop UI development.

Oh right, even now, we can just ssh-tunnel a nrepl.

It's like Emacs Tramp if you ever used it, just polished and better tested.

I don't personally use it though, just what I was told

> There’s even an example of remote desktop UI development Are you referring to this one, @U2FRKM4TW? https://github.com/PEZ/pirate-lang It will open up a machine with Java, clojure, VNC, and VS Code with Calva, in your browser. A quick jack-in and evaluation later and you are developing a Java UI app, all still in your browser.

Here’s a demo.

Yes, that one. :)

Thanks for reminding me. I now thought it might be good to surface it on Calva’s Youtube channel. I added some music that a friend of mine has composed. https://clojurians.slack.com/archives/C8NUSGWG6/p1635494324107000

If you want to try it now (and are a Lein user) simply use our plugin https://github.com/clojure-emacs/enrich-classpath

What kind of Java features are you most excited about?

I have considered something around this in clj-kondo, but I'm still not decided on bytecode parsing or source parsing

> What kind of Java features are you most excited about? Simply having the basics working well for every dep (whether it's from JDK core or from arbitrary deps): jump to source, show docstring of class/method/..., show arglist completions will full names (vs. arg0) Can always grow from there

are you using a Java source parser for this or simply the doclet-based stuff from before?

The reason I'm asking is that I'm considering something like this for clj-kondo / lsp but I still haven't decided on what's the right approach

https://github.com/clojure-emacs/orchard/blob/master/src-newer-jdks/orchard/java/parser.clj is the main parser

> still not decided on bytecode parsing or source parsing I'd imagine that not only types, but also docstrings and arglist names are erased from bytecode? So it seemed a no-brainer to me. Still bytecode could be some sort of fallback...

jep ok, that's the doclet stuff. I've been using that in clj-kondo too but only for built-in stuff

thanks

I feel Java source will almost never be available in transitive Java deps. But both is probably ideal no?

Also, Java doesn't have true docstrings, it's just a convention. Though.you can include the Java doc innthe jar I believe, I don't know if all jars will. I wonder if IntelliJ and eclipse try to just show the comment above the method in the source or...

> I feel Java source will almost never be available in transitive Java deps. certainly, those must be intentionally/separately fetched (which is what the plugin does)

for clj-kondo / lsp one would have to also have these sources available.

How? I guess this only works for open source?

> Also, Java doesn't have true docstrings, it's just a convention. I'd characterize it as sth stronger as a convention, as javadoc is part of JDK and the "culture" in the java ecosystem Much less ad-hoc than say, docstrings in Ruby (as an example that comes to mind of having no docstring OR javadoc-like mechanism). Same for JS I believe?

I guess one could use your plugin in the classpath command of lsp as well

I might take my happy emoji back if this only works in the purest form of open source development. If it can't work within an enterprise context with in house tooling, repositories, and all that it's not as exciting to me personally.

> for clj-kondo / lsp one would have to also have these sources available. yes, you'd have to use enrich-classpath or what have you. could be async if you don't want to affect startup time. But async doesn't play well with classpath Nobody forces you to use the classpath though, you can consider files to be "just files"

enterprise doesn't write docstrings? or do you mean, libs of other enterprises for which you have no source?

This works mostly at Maven level 99% of one's deps (direct or transitive) are public Private ones are also on Maven, so there's no difference

I think 99% or more of the Java libs I've ever used were open source

The latter, but also, even if I do have the source, I'm not sure if they can be pulled down, might be non standard, sometimes some teams source is permission restricted, etc.

They're just a Maven artifact like any other .jar, I doubt there's such a sophisticated firewall that will block source jars

Maven requires artifacts to have source/javadoc counterparts

In fairness, I'm still excited. Just explaining my preference for bytecode, because bytecode just works in all cases. Source might always be a bit more finicky. Both would be ideal off course

Maven is not for source

It is, all .jars have counterpart with a "sources" classifier

> bytecode just works in all cases Only for a subset of functionality, that might as well be fetched via reflection

Hum, are we sure about that? I think that's an optional thing no?

I tried a little bit with ASM but there are the following issues: • No reliable/precise line locations for methods, etc. • How to show the source when you navigate to it? Disassemble? Hmm In all cases: • How to deal with overloaded methods and hierarchies? It can get quite complex to point to the right thing

Well, you both I think know more than I do at this point haha. And as you're doing the work I trust your judgements. It might be source will work better than I think.

I'm not sure about either, it's far less trivial than clojure ;)

I'll report back how it works for me once I use it. Probably a better way to deal with real limitations is working backwards from them instead of me making hypotheticals

> Hum, are we sure about that? I think that's an optional thing no? From a quick googling https://central.sonatype.org/publish/requirements/#supply-javadoc-and-sources I heard that it's mandatory from Alex Miller, from my side I have not much experience pushing to Maven Central which is the one with this requirement

Personally I am not missing the Java features from a real IDE in emacs much. When I need to deal with Java I look up the docs online. And this isn't something I do every day.

Similar for JS

From my side I've been happy throughout 2021 with various bespoke Java integration for my Emacs. It's kind of a feedback loop, once you see its value first-hand one gets to use it more

yes, I can imagine.

When I think about both Eclipse and IntelliJ, I feel like when it's for code that is not my own Java source, it disassemble it, but it gives you the option to "attach source" for it.

Which makes me think that they probably just support both, favouring source if they can find it

Anyway, just wanted to say thank you to both of you for even looking into this problem and investing time and effort to make that aspect better. Those things have major impact I think on the ecosystem for Clojure.

Same for unchecked-math.

✅ verified thanks! I guess that the example I gave is fringe enough to not matter a lot

Interesting, makes sense

Though I'd started doing

(ns my-ns)
(def initial-x *x*
(set! *x* ...)
;; My code
;; At the end
(set! *x* initial-x)

Does that mean that one must know about the namespaces a priori in order to require/load them?

basically, yes

which is where a tool like tools.namespace comes in

there are libraries that can do things like scan the filesystem for clojure files and then you can load them, but that is fairly brittle outside of dev

Won't scanning the classpath be fairly close? (although I still agree with @U0NCTKEV8 about it being brittle outside of dev)

I am wondering about when connecting via a prepl socket... could a user discover all possible namespaces?

no

I mean namespaces can be dynamically created

sure

apart from that 🙂

clj-kondo can also give you a list of namespaces in a directory using its static analysis (this will also miss dynamically creates ones)

and tools namespace can scan the filesystem for clojure source files and parse ns forms

but that is not even close to "all possible namespaces"

no - I was perhaps a bit fast and loose with my comment... of course dynamically created namespaces are not fully possible

even the classpath is a simplifying assumption

the classpath is used to populate one classloader in the jvm, but clojure can load code from any classloader, and the classloader interface is a basic get value for key one, there is no listing of keys to scan a classloader for the resources it provides

For Repl use, you can kind of do it by scanning some of the class loaders and classpath, but it isn't exhaustive of all setups

You can probably do something to intercept that specific logger, but is there an exception or some other condition triggered when a leak is detected?

none, that's the problem 😅

in general logging is not something to be caught or handled, it is something to go in a log

depending on the logging infrastructure being used you can do things like direct the logs to a file or email or whatever

but java logging is well outside the scope of clojure

ok thx

what about this? https://github.com/brettwooldridge/HikariCP/blob/ed2da5f1f4ef19f871fac12effc0b199706905dc/src/main/java/com/zaxxer/hikari/pool/HikariPool.java#L175

MiscTest.testLeakDetection: This one of their tests detects the actual log line by saying "when ProxyLeakTask logs something, log it to this stream", then reading the results later TestElf.setSlf4jTargetStream: For the above, this one puts in a StringAppender - maybe a different "appender" could pick up the event as it happens? HikariPool.leakTaskFactory - maybe this field can be swapped out, to use one with a better/subclass "ProxyLeakTask"? These ideas would all be very brittle from using reflection, though https://github.com/brettwooldridge/HikariCP/blob/789ce3a76ad14521179f159ffa0bd2e904c17ff3/src/test/java/com/zaxxer/hikari/pool/MiscTest.java#L99 https://github.com/brettwooldridge/HikariCP/blob/f9b2c3d372b3f28911a872191ad62953c84bafa4/src/test/java/com/zaxxer/hikari/pool/TestElf.java#L120 https://github.com/brettwooldridge/HikariCP/blob/ed2da5f1f4ef19f871fac12effc0b199706905dc/src/main/java/com/zaxxer/hikari/pool/HikariPool.java#L80

Part of why this is outside the scope of the clojure language is most java logging is done via some abstract facade, which can be directed in some way or another to use some concrete logging library, which in turn is configured to log in some way either programmatically or with a config file

So it is possible to capture logging, but it is highly project dependant, and often kind of brittle

So like, even if the hikari tests show it being done with slf4j , depending on your project, you might be bridging slf4j to log4j2, so what the test does won't work for you

If you've never sat down and explicitly figured out logging for your project, you may have multiple logging libraries, all doing their thing, all doing it slightly differently with whatever their defaults are

You can increase the leak detection threshold in HikariCP, making more unlikely to encounter this warning: https://github.com/brettwooldridge/HikariCP/blob/dev/src/main/java/com/zaxxer/hikari/HikariConfig.java#L221

Or set it to 0 to disable it altogether.

TY guys. We have the threshold already set to a value > 2s Intercepting logs is not an option so I guess we'll have to look for a different approach to our problem.