Fork me on GitHub
#graalvm
<
2019-11-21
>
sogaiu00:11:45

one of the examples is:

-H:IncludeResources='.*/Resource.*txt$'

sogaiu00:11:31

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/.*" ^

sogaiu00:11:44

possibly using single quotes may help?

sogaiu00:11:16

(for windows, it does seem like the outer double quotes may be necessary)

sogaiu01:11:10

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...

sogaiu01:11:46

@borkdude tried using .{0,} as an alternative to .*

sogaiu01:11:17

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"

sogaiu01:11:08

@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

borkdude08:11:01

@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?

borkdude08:11:02

I wonder what test runner your are compiling, I guess it matters what it is calling

lread12:11:22

@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.

borkdude12:11:37

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

lread12:11:44

yeah, I think you are right and will experiment with that.

borkdude12:11:13

@lee are you using a test runner of some kind to kick the tests off, or are you running t/run-tests manually?

lread12:11:13

@borkdude, I currently generate my own little test runner which is just a -main that calls t/run-tests .

borkdude12:11:49

@lee and do you provide the namespace names of the tests you are going to run explicitly?

lread12:11:52

I originally did that so that aot compilation (via compile) would compile everything it needed to compile.

borkdude12:11:39

but I'm not sure if GraalVM is clever enough to eliminate everything else if you use that path

borkdude12:11:08

anyway, if compilation is within reasonable limits time and memory wise, it's progress?

borkdude12:11:35

or else we need to write a graalvm testing framework that re-uses bits from clojure.test

lread12:11:41

I'm not sure ns-interns is my problem, but was surprised what -H:+PrintAnalysisCallTree showed when I used it.

borkdude12:11:20

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?

borkdude12:11:40

that is, if you're not going to test side effects

borkdude12:11:11

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

borkdude12:11:40

something like:

(defn -main [& [test-fn-name & test-fn-args]] (prn (apply (get tests test-fn-name) test-fn-args))

borkdude12:11:55

(I'm sure I forgot a paren or two, but that's the rough idea)

borkdude12:11:39

and the tests map could be autogenerated using ns-publics which works well with graalvm

lread12:11:07

Interesting idea. I'm going to learn dig around a bit more before I choose a path.

borkdude12:11:17

sure! just ideas 🙂

lread12:11:33

and very much appreciated! simple_smile

mattsfrey20:11:06

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?

borkdude20:11:47

@mattsfrey I have seen people do this in the Java community.

borkdude20:11:22

take a look at the @graalvm twitter account, they retweet these things every so often

mattsfrey20:11:00

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

mattsfrey20:11:55

the results for java were definitely very promising, 10mb memory footprint for a server etc

mattsfrey21:11:31

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

borkdude22:11:22

GraalVM is mentioned in the Thoughtworks Technology Radar: https://assets.thoughtworks.com/assets/technology-radar-vol-21-en.pdf