This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-04
Channels
- # announcements (1)
- # asami (61)
- # babashka (71)
- # beginners (170)
- # biff (1)
- # calva (14)
- # clj-kondo (23)
- # cljsrn (28)
- # clojars (1)
- # clojure (152)
- # clojure-australia (2)
- # clojure-europe (65)
- # clojure-nl (2)
- # clojure-spec (8)
- # clojure-sweden (3)
- # clojure-uk (45)
- # clojurescript (1)
- # css (12)
- # cursive (16)
- # datomic (9)
- # devcards (2)
- # emacs (1)
- # events (1)
- # graalvm (31)
- # honeysql (10)
- # jackdaw (2)
- # jobs (5)
- # lambdaisland (9)
- # lsp (4)
- # malli (11)
- # meander (43)
- # off-topic (6)
- # pathom (7)
- # polylith (1)
- # portal (14)
- # re-frame (7)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (6)
- # shadow-cljs (101)
- # specter (1)
- # tools-deps (26)
- # vim (9)
- # xtdb (2)
Does anyone know of a worked example of integrating Java sources into a tools.deps project like https://github.com/puredanger/clojure-from-java, ideally with support for iterative development/reloading of the Java files?
I understand there's no equivalent of :java-source-paths
in deps.edn and we have to do some sort of jar compilation step manually
https://github.com/xapix-io/axel-f/tree/master/src/axel_f/buddy/util
small example
to compile - javac $(find . -name '*.java' -type f)
Not sure whether this is the best channel for this question, but: I've inherited a codebase that makes heavy use of :pre
and :post
. The project currently uses Leiningen, where it's possible to disable assertions when building an uberjar by adding :global-vars {*assert* false}
into project.clj
. Is there a way to disable assertions with tools.deps?
No idea. Could look into it. Might be it just does alter-var-root
on *assert*
at the start.
I still don't see how leiningen sets the dynamic var for each namespace, or does it establish thread bindings for the entire project, I guess so
Looks like my best bet is to bite the bullet and migrate to spec/assert
(most of the pre/post conditions are spec assertions).
Why do you want to disable the assertions? That would mean that if your code tripped over those conditions in production, it would continue on with bad data and potentially cause all sorts of corruption, instead of failing fast.
I’ve never understood why folks want to disable assertions in production…
It depends if you use those assertions for dev purposes or domain purposes. We use asserts for dev purposes e.g. to verify if our system has the right components in certain function calls
@U04V70XH6 This codebase is absolutely chock full of pre/post-conditions. Most every function has one. If we enabled them in production, the application would be slow as molasses. It would be a different matter if there were assertions only at the boundaries of the system.
Ugh! That’s a poor use of asserts IMO. Doesn’t surprise me though, really. Sorry.
$ bb -e '(run! println (babashka.classpath/split-classpath (with-out-str (babashka.deps/clojure ["-Spath"]))))'
src
/Users/borkdude/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar
/Users/borkdude/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar
/Users/borkdude/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar
Thanks for the -Stree. Didn’t find that in man clojure
on mac. But that option exists in clj -h.