You can, in fact, exclude seqable? in particular: https://clojuredocs.org/clojure.core/refer-clojure

I do not recommend doing this, but here: https://gist.github.com/RutledgePaulV/2cf1ccf6e561937206ac61f41041112d

If you're the developer of the library then exclude with :refer-clojure. If you're not, then you can either monkey patch it locally or contribute to the library to resolve the warning

@U5RCSJ6BB wouldn’t this disable other errors/warnings as well? The context is we have many many Clojure components in production and we simply don’t have time to resolve each one of these warnings in each component (not in the near future, at least) - meanwhile, it creates a lot of noise in our logging/monitoring systems. I would like remove these warnings from production environments so we can focus on the real issues.

@U5RCSJ6BB Actually it doesn’t work at all.

Yes, it removes all errors and warnings from the compiler. I don't recommend using it. I'm pretty sure it did work but last I tried it was several years ago. I'm not sure how you're bundling your app but if adding to your project.clj file it will have no bearing on jars you create and you'd have to find a way to run the same code before any of your problematic namespaces get loaded

It didn’t work with lein repl either. But I will try to simply plug it in the main ns. Very strange these things are not properly configurable.

I am not a heavy JDK user myself except as a hobbyist, so can't give you good answers there. I would not be surprised if the main things convincing some people to continue using JDK 8 are that they rely upon some Java library that does not work well with JDK 9 or later, deep in its guts.

Perhaps yes.

Most of the issues, moving from 8 to 9 or above, were about reflection and access to parts of what became other modules. We got stuck on Java 8 for a while because some of the libraries we used did not run properly on 9+. We actually switched one library out for an alternative because it was so slow to properly support 9, and that allowed us to move to 11 which is what we're on in production right now.

It's been pretty smooth from 9 onward. I used 14 on my dev systems for a while, and I'm on 15 right now on my Mac (still on 14 on this Windows laptop, well, on Ubuntu). We've talked about upgrading our servers at work but there's nothing really compelling at the moment so we haven't decided which version we would upgrade to yet...

The main actual "breakage" when we upgraded from 8 to 11, was around JVM options which changed/went away. But that was easy to fix, albeit a bit annoying to roll out.

For us I think it's just there's no reason to move up from 8. And even if the friction won't be too hard, you'll still need to be upgrading dependencies and all, so it seems like a all pain no gain deal

Until 8 is no longer supported, then we'll have a reason to upgrade

It looks like 8 will stay supported past the end of 11's support period, at this point. 14 is already past the end of its support. 17 is still nearly a year away from release.

Ya, I recon there might be a chicken and egg problem here. If they keep seeing so many people using 8 they might just keep extending support. But if people like me wait till support ends to upgrade,,,

I'll get around to it at some point I'm sure, but its that thing of like, its working fine so why botter

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
    <Appenders>
        <Console name="ConsoleJSONAppender" target="SYSTEM_OUT">
            <JsonLayout complete="false" compact="false">
                <KeyValuePair key="myCustomField" value="myCustomValue"/>
            </JsonLayout>
        </Console>
    </Appenders>

    <Loggers>
        <Root level="all">
            <AppenderRef ref="ConsoleJSONAppender"/>
        </Root>
    </Loggers>
</Configuration>

How are you setting that property? I'm not asking about XML.

:aliases {:dev {:extra-paths ["dev"]
                 :jvm-opts ["-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2-factory"]

"-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2-factory" looks right. And you're starting things up with the :dev alias?

yes

PS Did you see my “edit” in my message?

https://clojurians.slack.com/archives/C03S1KBA2/p1607896174474900

I can't understand what you're saying here.

Likely the issue is tools.logging has a specific order it chooses logging backends in, and any reasonable sized project ends up including all the logging backends

Yes, but the JVM property tells it to select the specified one. It's what we do at work.

I am saying it didn’t work, but now it works. I don’t know how and when I fixed it 🙂

You shouldn't need that binding if you're setting the JVM property.

yes, now it works without

Ah I found the issue… for some reason when using clojure.tools.logging it doesn’t react for log4j2.xml file changes and reload configuration.

Which gave me false assumptions

Hmm, we use a .properties file for it and it does reload changes (after a period of time) and I think it's something you have to configure in log4j2... let me see if I can remember what we did...

monitorInterval = 30

You should be able to set that in the XML file as well. Then it will monitor the XML file and pick up changes automatically.

Nothing to do with clojure.tools.logging

Is it not default?

(let [logger (LogManager/getLogger)]
    (.info logger "foo bar"))

  (binding [l/*logger-factory* (clojure.tools.logging.impl/log4j2-factory)]
    (l/info "foo"))

ok this is my luck of experience with loggers then 🙂

I don't understand what you're asking, but this has nothing to do with clojure.tools.logging. This is about configuring log4j2.

See https://logging.apache.org/log4j/2.x/manual/configuration.html

I mean the code above always work with fresh configuration file while (l/info ...) use old one. So it looks like https://clojurians.slack.com/archives/C03S1KBA2/p1607899141479800?thread_ts=1607897509.475500&cid=C03S1KBA2 load fresh file always

My mistake, I though reload if by default

Those pieces of code are not equivalent.

But reloading the XML file when you make changes is a configuration option in the XML file.

Thanks, now I know 🙂

Java logging is a giant mess.

BTW Do you have example which work in google cloud (exactly cloud run) as jsonPayload? I can’t make it work as expected 😕

Nope, never used any of the Google Cloud stuff.

ok, thank you for help

do you need some amount of custom graphics, or just an XY scatterplot?

Just need to know the points. Just data, no graphics. I'm going to use cljfx, but that's irrelevant to the function I'm looking for. Any kind of plot. I know there's different strategies and then surely known algorithms. https://en.wikipedia.org/wiki/Graph_drawing. So 'just an XY scatterplot'.

https://github.com/generateme/cljplot

There's not a ton of documentation but I've been using this to good effect. There are a bunch of examples in the "sketches" directory (results in "results" directory)

And it's possible to just use the scaling stuff here: https://github.com/generateme/cljplot/blob/master/src/cljplot/scale.clj

ohh, that kind of graph. For layouting out graphs (not charts), I've only seen wrappers around graphviz so far

Oh, yeah sorry, I misunderstood as well

some libraries that use graphviz under the hood: • https://github.com/clojure/tools.deps.graph • https://github.com/daveray/dorothy (it says it's still subject to change, but it hasn't changed in years)

I would also be interested in a library that does graph layout for you that runs on the jvm (no graphviz). would be great to hear if you find something

hmm, there is also https://github.com/totakke/jungerer which wraps http://jrtom.github.io/jung/ which has several graph layout implementations

Thanks @U7RJTCH6J. Yes I might take at look and see if easy to get something out with one of the JUNG implementations, for instance https://github.com/jrtom/jung/blob/master/jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/SpringLayoutAlgorithm.java. Will definitely share if I can layout a graph from Clojure.