This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-21
Channels
- # aleph (2)
- # announcements (2)
- # babashka (10)
- # beginners (117)
- # calva (11)
- # cider (19)
- # clj-kondo (27)
- # cljs-dev (24)
- # cljsjs (1)
- # clojure (73)
- # clojure-europe (3)
- # clojure-italy (2)
- # clojure-nl (47)
- # clojure-spec (23)
- # clojure-uk (28)
- # clojurescript (71)
- # cursive (7)
- # data-science (17)
- # datascript (1)
- # datomic (7)
- # duct (23)
- # emacs (23)
- # fulcro (6)
- # graalvm (41)
- # jobs (2)
- # luminus (1)
- # malli (1)
- # off-topic (151)
- # pathom (1)
- # portkey (10)
- # re-frame (12)
- # reitit (17)
- # shadow-cljs (158)
- # spacemacs (14)
- # sql (8)
- # tools-deps (17)
- # xtdb (9)
may be already seen, but fwiw: https://github.com/oracle/graal/blob/master/substratevm/RESOURCES.md#example-usage
the current clj-kondo .bat file (https://github.com/borkdude/clj-kondo/blob/master/script/compile.bat#L26) has:
"-H:IncludeResources=clj_kondo/impl/cache/built_in/.*" ^
tried a variety of things, but it appears that using the asterisk character is tricky -- when i leave it out, IncludeResources shows up, but in all cases i've tried so far, having an asterisk in the expression portion causes IncludeResources to not show up. i wonder if there's some way to get feedback about discarded options and reasons for discarding...
call %GRAALVM_HOME%\bin\native-image.cmd ^
-jar target/clj-kondo-%CLJ_KONDO_VERSION%-standalone.jar ^
"-H:Name=clj-kondo" ^
-H:+ReportExceptionStackTraces ^
"-J-Dclojure.spec.skip-macros=true" ^
"-J-Dclojure.compiler.direct-linking=true" ^
"-H:IncludeResources=clj_kondo/impl/cache/built_in/.{0,}transit.json$" ^
"-H:ReflectionConfigurationFiles=reflection.json" ^
--initialize-at-build-time ^
"-H:Log=registerResource:" ^
--verbose ^
--no-fallback ^
"-J-Xmx3g"
@borkdude at last on windows?
echo (inc) | clj-kondo --lint -
<stdin>:1:1: error: clojure.core/inc is called with 0 args but expects 1
linting took 63ms, errors: 1, warnings: 0
@lee
> What I see is that `clojure.test` discovers what tests it will run at runtime using functions such as `ns-interns`.
Ns-interns only returns stuff for a single namespace so that doesn't seem too bad maybe?
However, all-ns
is much worse, it returns all the namespace objects of the current runtime. You can prevent running run-all-tests
in your test-suite, by running (run-tests 'the-namespace)
yourself?
@borkdude, I am currently testing with run-tests
, but in a minimal main.clj just calling (ns-interns 'my-ns)
brought in mucho stuffo. Generated executable grew from 6mb to 22mb. I’ll keep poking and learning and report back.
ok, maybe ns-interns must be avoided then too .. probably doing more stuff manually instead of relying on autodetecting tests is the way to go. but 22mb for a binary isn't too bad. babashka is 27mb currently and compiles fine on CircleCI
@lee are you using a test runner of some kind to kick the tests off, or are you running t/run-tests
manually?
@borkdude, I currently generate my own little test runner which is just a -main
that calls t/run-tests
.
@lee and do you provide the namespace names of the tests you are going to run explicitly?
I originally did that so that aot compilation (via compile
) would compile everything it needed to compile.
maybe using test-ns-hook helps: https://github.com/clojure/clojure/blob/28efe345d5e995dc152a0286fb0be81443a0d9ac/src/clj/clojure/test.clj#L757
but I'm not sure if GraalVM is clever enough to eliminate everything else if you use that path
anyway, if compilation is within reasonable limits time and memory wise, it's progress?
or else we need to write a graalvm testing framework that re-uses bits from clojure.test
I'm not sure ns-interns
is my problem, but was surprised what -H:+PrintAnalysisCallTree
showed when I used it.
I think the graalvm test framework could also be combined with approach 1: generate a command line stub to trigger the tests via clojure.shell/sh and read back the EDN result and verify that in the JVM?
but side effects like changing files on the file system can still be done that way. the only side effects you can't test are in-memory ones
something like:
(defn -main [& [test-fn-name & test-fn-args]] (prn (apply (get tests test-fn-name) test-fn-args))
and the tests
map could be autogenerated using ns-publics
which works well with graalvm
hey, curious if anyone has been using native-image builds to run the server of a fullstack app, fulcro or om/om.next or another framework is of particular interest, and if so how large is the memory footprint for the container?
@mattsfrey I have seen people do this in the Java community.
take a look at the @graalvm twitter account, they retweet these things every so often
thanks, yeah I’m on their slack as well just hoping somebody might have done this for a clojure server and have some insights about it
the results for java were definitely very promising, 10mb memory footprint for a server etc
I have a need to run a large collection of microservices and was looking into using golang due to the tiny runtimes, not trying to pay for server space for 256mb+ clojure containers but using native-image seems to be like the compromise that could let me stay 100% clj and not break the server budget
GraalVM is mentioned in the Thoughtworks Technology Radar: https://assets.thoughtworks.com/assets/technology-radar-vol-21-en.pdf