Fork me on GitHub

Yes, moving the ^bytes to the arg vector works. Thanks!


Anyone had problem with Java 16 about "Implementation of JAXB-API has not been found on module path or classpath". I know that is a problem with xml binding, I tried many ways about including javax.xml.bind/jaxb-api but not that solve it. Anyone has solved it?

Alex Miller (Clojure team)01:03:04

That is how I've solved this in the past


When I evaluate:

(if (resolve 'foo)
  (foo :a)
I get an error about being unable to resolve foo in this context, even if I checked that (resolve 'foo) is nil. What's the correct way of executing something if a function exists?

Noah Bogart12:03:22

Seems like a design issue. Remind of the classic stack overflow question “how do I programmatically create a variable?”, you should reconsider the design of your code to use a different data structure or change the definitions such that foo will always be defined, even if it’s an alias for identity

Ben Sless12:03:32

At the call site you also need to resolve foo. The compiler can't do it, so it won't compile it for you. You can either add a call to resolve there, or write a macro


Yes, good point on a different design, this snippet should work for a bit of editor integration: a clojure snippet that's called from cider so that I can use an enhanced function (`foo` ) if it's defined, or carry on if it's not. What would work here?


yes maybe defining foo as identity originally would work, but if you have more suggestions I'm glad to hear them

Ben Sless12:03:01

Why not use requiring resolve and if-let?

🙌 1
🎉 1

Thank you, if-let works!

(if-let [f (resolve 'foo1)]
  (f :a)


ah, TIL about requiring-resolve, nice!

Noah Bogart13:03:18

Good call Ben, forgot about that one

Ben Sless14:03:07

:) If you find you use that pattern a lot, a macro might be in order


I'm a bit confused by a difference of behavior between two snippets:

(do (require '[portal.api :as p])
    (add-tap #'p/submit))
(require '[portal.api :as p])
(do (p/open)
    (add-tap #'p/submit))
the first doesn't work (`p` is unknown), the second does. My naive model was that lines, even inside the do block, would have been compiled on the fly. So, does the first snippet not work because the unit of on-the-fly-compilation is a form?


you've come across the Gilardi Scenario™

🙌 3

tldr: the require form executes at runtime, not compile time


so in the first example p isn't a valid alias in p/open or p/submit


the do block is compiled all at once


Thank you, very instructive! So I suppose this bit from the article:

In Clojure 1.1, the compiler introduced special handling to work around this. If the top-level form being evaled is a do, then it will be broken up and each subform will be evaled separately. Unfortunately this only goes so far; it only applies to top-level dos, so even though our when above macro-expands to a form that contains do, the compiler can't apply its special-case.
applies only when I explicitly use eval and doesn't trigger in my case?


are you using a REPL? what type of REPL?


nrepl via cider-interactive-eval


Clojure 1.11.0-rc1
user=> (do (require '[clojure.datafy :as d]) (d/datafy 42))
this is in a plain old clojure.main repl, no nREPL


speculation: nREPL might be wrapping forms, so your top-level do isn't top-level

😍 1

amazing, I see what the problem could be, thanks!


(when (bound? #'*seed-state*)


Is there a function that does this ^^^ ? Returns nil if var is unbound?


You pretty much wrote it yourself - it's just 2 lines. :) There's no such function in clojure.core.


I found this:


(defn get-possibly-unbound-var
  "Like var-get but returns nil if the var is unbound."
  {:added "1.1"}
  (try (var-get v)
       (catch IllegalStateException e


It is in clojure.test


but it returns clojure.lang.Var$Unbound

Joshua Suskalo14:03:50

right, the purpose of this is that it fetches the value of a var that may or may not be bound.

Joshua Suskalo14:03:59

It's not designed to do what your code snippet does.


like var-get ( it doesnt throw IllegalStateException )


Is there a good way to get the information from clojure.repl/dir as data, instead of printed?


dev=> (clojure.repl/dir-fn 'clojure.set)
dev=> (type *1)

🙏 1

(source dir) shows it should be relatively simple to amend to your needs


hey guys quick question - if i include deps.edn in jar files published to clojars, will clj read it to download dependencies which are missing from pom.xml?


For dependencies brought in via :mvn/version, the pom.xml file in the JAR is the "system of record" for dependencies and (only) those will be treated as transitive dependencies that need to be figured out (version-wise) for things that need to be downloaded.


Thanks Sean. Sorry for asking twice. 🥴


I thought it sounded familiar 🙂


Sorry for obsessing about this but it sounds like this makes dependency management more difficult because you can't guarantee that a maven coordinate will pull in all the dependencies...and you can't pull non-maven coordinates with leiningen.


maven coordinates need to specify their dependencies in pom.xml. If you do this, you will have all of your dependencies


that's a suitable answer if i control everything in the stack


i don’t follow. a well formed jar lists its dependencies in a pom.xml. If you are publishing the jar, which i’m getting from “if i include deps.edn in jar files published to clojars” then you need to make your jars correctly.


but perhaps you could back up and explain your problem rather than trying to solve it with deps.edn in a jar file. Explain the actual issue you are trying to accomplish


I see an issue with the ecosystem and I'm trying to find someone to tell me that I'm nuts or overlooking something. pom.xml doesn't include If a library specifies a gitlib in deps.edn, then any dependants on that library won't receive that gitlib dependency if they rely on my library from clojars. If that gitlib dependency is not on maven at all, then leinengen users can't use the library. If I maintain a dependant on the library, then I can work around this problem like you said - I can fork both dependencies and consume them however I want. But, uh... that's not a good solution.


If you're publishing a library to Clojars/Maven, it's on you to do it correctly -- and that means no git dependencies.


If a project has git deps, it can't be packaged as a JAR for Clojars/Maven -- it can only be consumed from source via git deps, i.e., deps.edn projects and the CLI.


That’s correct. I think there has been some writing on this. The clojure cli allows you to build a classpath using projects hosted on github by cloning them and adding them to the classpath. This is considered a dev time helper largely. And this is a functionality that is offered by the Clojure cli and not the java ecosystem as a whole.


CLI-specific tooling can (and often is) provided as git deps only. Some people occasionally request such tooling be packaged as a JAR that can be consumed from Clojars (or Maven) but it is up to the author to decide whether or not that is appropriate.


@doubleagent Do you have a specific library in mind for this question or is this an abstract consideration?


It's an abstract consideration. Personally, I think this approach is dragon-territory because it relies on good actors. If clj merged dependencies from pom.xml and deps.edn then it would be tenable even if it left Leiningen users in the cold for a while. I've followed Clojure for over ten years and have been using it professionally for seven, but I'll have to consider things before crossing this bridge.


I’m not following the confusion. If you are relying on maven coordinates for your stuff, you know you are not using the gitlibs functionality. If you elect to use coordinates based on gitlibs, you have elected into it and you know that its not going in a jar. It seems straightforward to me.


☝️:skin-tone-2: Exactly this. I don't see how it's an issue @doubleagent


I have a bunch of OSS projects. Most are published as JARs to Clojars (and do not use git deps internally). Some are deliberately git deps (and are not published as JARs because of that).