This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-30
Channels
- # adventofcode (4)
- # aleph (1)
- # announcements (6)
- # babashka (11)
- # beginners (63)
- # calva (73)
- # clj-kondo (9)
- # clj-on-windows (20)
- # cljdoc (8)
- # cljsrn (4)
- # clojure (48)
- # clojure-europe (20)
- # clojure-italy (1)
- # clojure-nl (11)
- # clojure-spec (11)
- # clojure-uk (3)
- # clojurescript (32)
- # cloverage (1)
- # conjure (1)
- # cryogen (5)
- # datomic (83)
- # fulcro (28)
- # graphql (23)
- # gratitude (4)
- # helix (15)
- # honeysql (4)
- # improve-getting-started (14)
- # introduce-yourself (3)
- # jackdaw (5)
- # kaocha (11)
- # leiningen (1)
- # malli (1)
- # meander (5)
- # off-topic (18)
- # pathom (17)
- # pedestal (6)
- # polylith (15)
- # practicalli (1)
- # quil (2)
- # reitit (4)
- # releases (6)
- # shadow-cljs (38)
- # sql (20)
- # testing (6)
- # timbre (5)
- # tools-deps (11)
- # vim (2)
You probably have a good reason but just out of curiosity, why aren't you using one of the projects that have solved this already for Minecraft like Paper or Fabric?
Fabric still uses mappings to intermediate class names for everything in net.minecraft
unzip -l PaperMC/cache/patched_1.17.1.jar | grep minecraft > /tmp/nms_classes.txt
https://gist.github.com/cf4c7098bf1ed747c48ef6f2163ed417i'm interacting with this "messed up" java API that routinely has 10-15 args to functions, most of which I just have to set to nil
. Is there a nicer way of writing something like this?
wrap this call to a function and use it instead
(defn call-java-api [param]
(.callFn api param nil nil ...))
that would hide things where specific calls are reused, but usually it's a call once situation for each. so parts of the code get littered with these calls with 14 nil
s in them. but I guess you're right; the only sensible way out of it is to write my own wrapper api that accepts the params I need
maybe reading this would help? https://dev.to/hlship/down-the-rabbit-hole-with-clojure-defrecord-and-macros-3aal
@U52RNHDRN Are those 14 nils just default values? if so
(defn call-fn-api [api {:keys [a b c]}]
(.callFn api a b c))
hi,
please help how i can create java *Map*<*String*,*Class*<?>>
in clojure?
I assume just {"boo" SomeClass}
not exactly the same? 🙂
"suffice" - generics only exist inside javac, so the type hint is just noise, there's nothing there for it to help
And for the pedantic&curious, there’s exactly one corner case where this isn’t true - https://fasterxml.github.io/jackson-core/javadoc/2.2.0/com/fasterxml/jackson/core/type/TypeReference.html 🙂
ah, that easy awsome, thanks a lot!
java.awt.FontRenderContext has two constructors of arity 3:
public FontRenderContext(AffineTransform tx, boolean isAntiAliased, boolean usesFractionalMetrics)
public FontRenderContext(AffineTransform tx, Object aaHint, Object fmHint)
I'm not seemingly able to call the first one (with booleans) and always getting the second Object one. I can work around this but is it possible to guide the compiler to choose that one at all?
(let [^Boolean aliased true
^Boolean fractional true]
(FontRenderContext. (AffineTransform.) aliased fractional))
(FontRenderContext. (AffineTransform.) true true)
both yield
> Execution error (IllegalArgumentException) at java.awt.font.FontRenderContext/<init> (FontRenderContext.java:156).
> AA hint:true
whereas this does not throw an error:
(FontRenderContext. (AffineTransform.)
RenderingHints/VALUE_TEXT_ANTIALIAS_DEFAULT
RenderingHints/VALUE_FRACTIONALMETRICS_DEFAULT)
This should be a simple question for y’all. What’s the industry standard for logging in Clojure? I could make a function like so:
(defn log [msg]
(println msg)
msg)
But I want to hear your opinions.clojure.tools.logging
is basically the standard for libraries. For end-user applications you get the choice between an implementation of tools.logging like logback or something like timbre. You shoultn't use timbre for libraries though because it tries to force the whole application to use it.
Logback is an implementation of SLF4J. In the Java world it's often more SLF4J which is the standard, and logback is just the goto default implementation. tools.logging is a clojure frontend for SLF4J (and a couple others), so it's a good option.
https://lambdaisland.com/blog/2020-06-12-logging-in-clojure-making-sense-of-the-mess Also, look at Sean Corfield's use of log4j2 in the place of logback.
In babashka I went with timbre since it's quite handy for scripts to not require any XML files along with the script. It's available through the clojure.tools.logging facade
I would like more such "interface" libraries where the impl is chosen at runtime, so libraries aren't directly tied to a specific impl. E.g. for JSON, we could have a clojure.tools.json thing instead of directly using clojure.data.json, cheshire or jsonista
Timbre fell out of favor for Juxt https://www.juxt.pro/radar In practice it's pretty great, pleasure to use. Still I do find it has it flaws that can show up with advanced-ish usages. Java rejection turns out to be a mistake in a JVM lang. https://clojars.org/io.pedestal/pedestal.log is a nice rich choice - does not depend on other Pedes parts. https://github.com/stuartsierra/log.dev also deserves a honorable mention
that https://github.com/fzakaria/slf4j-timbre exists separatedly and uncoordinatedly from its parent is just bad tbh.
We started out with tools.logging
, switched to Timbre, then switched back to tools.logging
, backed by log4j2 now (we like the variety of config options and that it can reload its configuration while its running). But logging in Java is just a gigantic can of worms.
countdown to a logging lib called ivermectin
I've just been using tools.logging with logback or log4j2. I'd recommend against any other Java backends, they all have known prod issues (either performance or deadlocks) under high load and stress. I have not tried timbre
timbre definitely does not improve performance
I’ve been using timbre
for the longest time and generally have no issues with it, but my needs are pretty simple atm. Do the other tools like tools.logging
support ClojureScript as well? (as far as I can tell - no, but please correct me if I’m wrong)
Maaaaybe for node? But even that’s fairly questionable. The reason you need a logging framework for the JVM is 1) to order messages from many threads, and 2) because there are multiple places you might want messages to go (e.g. stdout/a file/a socket).
I could imagine wanting more features if you are running node, but no tools.logging contains no cljs or cljc code, and is full of interop
For new project we have used mulog which allows us to created very meaningful log events and easily search through them https://github.com/BrunoBonacci/mulog It's so effective to use and a joy to develop with, we are going to refactor our other projects to use it.