Also, with larger projects, where user.clj might grow over time to require a bunch of namespaces, it might be a good idea to move most of the content to another auxiliary namespace (e.g. dev.clj) and thus postpone loading it until you explicitly ask for it. An example from the duct template: https://github.com/duct-framework/duct/blob/master/lein-template/resources/leiningen/new/duct/base/user.clj. I've seen some cases where opening a repl takes ages, because user.clj pulls in everything when you only wanted to just quickly run some unit tests. (disclaimer: not sure if this applies to deps.edn as much as leiningen)

It would apply only if user.clj is in your src folder. Which you can avoid if you move it elsewhere. Then you can decide in what profile to include it being loaded automatically or not. That was my use case, I did not want it loaded when running tests.

But thanks, ya that's another way to do it. But I like the auto-load feature when at REPL, because I use it to setup things I want at the REPL

I’d recomment installing SDKMAN: https://itnext.io/how-to-install-x86-and-arm-jdks-on-the-mac-m1-apple-silicon-using-sdkman-872a5adc050d

If you switch the config as described in the post, you can make sure that you have an ARM compatible JDK installed on your machine.

@U0N9SJHCH Thanks, that's an option I've not heard of.

Also provides some selection of JDK vendors for you and lets you switch between them:

As far as I'm aware, it's only from JDK17 onwards is Arm fully supported.

Azul should have ported it back?

But you are right, it‘s not in the list

@U11EL3P9U Thanks, I've missed that 17 has arm support

np 🙂

I originally ran with Azul since they were the first to release with Arm support, then when Adoptium came out with their cut of openjdk, I switched to them.

brew install temurin will give you mac/arm64

Just in case - if you think there's a chance you might need to know whether a request was successful or not, do not abstract the transport layer. That's exactly why CORBA has failed. You can't completely abstract away HTTP given its distributed nature and the fact that networks fail.

good thought. the goal here is for faster development between components, abstracting some of the elements of the network so we can later focus on them specifically.

This is a hard problem. Many attempts have been made to solve it over many years, in different languages/frameworks but none are ideal or truly simple. There's sente (I have not used it myself, only looked at it) for Clojure(Script), but it does involve a server, it does not try to paper over the problem or pretend there's no server https://github.com/ptaoussanis/sente

Maybe some more context would help. I have a locally running browser app and a locally running cljs node app. I need them to talk. I don't think it's too complex in essence, ill need to write to some persistent storage and have both watch for messages on it. Recreating the network is hard. But i want to abstract it, that means flawless happy instant communication.

i think i can just catch the re-frame events and push them into a file then have the server app read them. The work will likely be abstracting the server entry point to look for this file in the context when im running locally.

this does not seem relevant to #clojure. Do you mind deleting this from here? We have an #off-topic channel that is suitable for this if this is not some kind of self-promotion bit

Hey, well I only had good intentions

I thought the most people are in that channel

I bought the books and there was the manning free christmas giveaway buy one, get one free for a friend

No worries! It's a nice gesture. But it's not on topic for clojure so repost in off topic and thanks for your generosity!

Interesting. What you expect is exactly what I'm getting:

(clojure.data.xml/parse-str "<svg width=\"100\" xmlns=\"\"><circle cx=\"3\" cy=\"3\"/></svg>" :namespace-aware false)
=>
#xml/element{:tag :svg,
             :attrs {:width "100", :xmlns ""},
             :content [#xml/element{:tag :circle, :attrs {:cx "3", :cy "3"}}]}

strange. clojure -X:deps list indicates that I'm on that version as well. I'm on JDK11, Clojure 1.10.3. Thanks for helping out with a repro attempt!

Sure thing. FWIW, same Clojure version but JDK 17. Although I doubt that JDK would affect things here.

Before you file a bug report - have you actually tried running your code in a clean environment, with no dependencies but the XML library? Given that it works for me perfectly, it makes it seem like there's something wrong with your environment. Perhaps you're using a different alias when running that REPL session?

I have same results as @U2FRKM4TW

% clj -Sdeps '{:deps {org.clojure/data.xml {:mvn/version "0.2.0-alpha6"}}}'
Clojure 1.10.3
user=> (require '[clojure.data.xml])
nil
user=> (clojure.data.xml/parse-str "<svg width=\"100\" xmlns=\"\"><circle cx=\"3\" cy=\"3\"/></svg>" :namespace-aware false)
#xml/element{:tag :svg, :attrs {:width "100", :xmlns ""}, :content [#xml/element{:tag :circle, :attrs {:cx "3", :cy "3"}}]}

tested with Java 11

those are records we're seeing in the output whereas you're just seeing plain maps. not sure if that's due to an older data.xml version or if your repl/editor is affecting your printing

Is there a version of loaded-libs that outputs the version of the loaded libraries?

Try (System/getProperty "java.class.path"). If there's only one org/clojure/data.xml and it points to the right version, there is one other possibility - one of your dependencies bundles data.xml classes or sources within its own JAR. Or it might be on the classpath of the project you're working on - maybe just in a place you didn't know about, like some extra src or maybe somehow outdated but not updated classes.

there's an easy way to look for a compiled version of a namespace

Clojure 1.10.1
(ins)user=> (require '[ :as io])
nil
(ins)user=> (io/resource "clojure/core__init.class")
#object[java.net.URL 0x420bc288 "jar:file:/home/justin/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar!/clojure/core__init.class"]

that checks for the compiled version of clojure.core, it would return nil if it couldn't be found on classpath

you can also check for "clojure/core.clj" etc. to see if the source file comes from the artifact you expect - but in my experience bad bundling of compiled namespaces are much more common than bad bundlings of source