Fork me on GitHub
#boot
<
2017-11-29
>
dave12:11:21

@seancorfield i can relate to the weirdness around the stdlib -- it took me a while of tinkering with the compiler options to get it working. i ended up with this:

(into-array String (->> ["-cp" (System/getProperty "fake.class.path")
                         "-d" ~out-path
                         "-no-stdlib"
                         "-nowarn"
                         "-Xskip-runtime-version-check"
                         ~kotlin-files-paths]))

dave12:11:45

(those are the args to the main compiler method in the kotlin compiler lib)

dave12:11:23

i ended up going with -no-stdlib, which ends up being OK because the pod it's running in already has the kotlin dependencies on its classpath

dave12:11:49

which we can supply as an argument via boot's fake.class.path

dave12:11:40

it seems to work pretty well -- i haven't had any issues with using the kotlin standard library, anyway

dave12:11:29

i think what i'll do for now is take stock of what your library has that mine doesn't, and track those as github issues that i (or anyone feeling industrious!) can hack on when i have time

dave12:11:33

it would be cool to merge the work we've both been doing into a single, badass boot kotlin task

dominicm13:11:57

@dave there's a fake.class.path in get-env btw. If you're in a pod, it might be better.

dave14:11:09

what do you mean?

dominicm14:11:28

(get-env :fake-class-path) iirc

dominicm14:11:50

It was added because different pods end up having different classpaths.

dominicm14:11:28

Depending on if you deferred that code or not, you could end up with a value you didn't expect.

dave14:11:51

oh, interesting. i saw some code in sean's boot-kotlinc where he has a loop, waiting for the classpath to change after merging the dependencies. my code doesn't have anything like that, so it probably is susceptible to a race condition

seancorfield16:11:30

The fake class path -- both in the environment and as a system property -- are set asynchronously in a thread. So whenever you modify dependencies, there is a potential delay before the fake class path updates. Took me a while to debug why kotlin.test sometimes didn't appear on the fake class path!

dave17:11:49

interesting!

dave17:11:09

i should steal that little bit of code from you 😉

dave14:11:06

maybe getting the fake class path from the env is a more robust solution

dave14:11:15

i don't have a good way to test it, though

dave14:11:25

it always works on my machine™ 😛

alandipert15:11:23

dave thanks! yea the hardware jiggler discovery is what started me on the path 😃

dave15:11:39

truly an outstanding feat of software engineering

dominicm15:11:37

I once knew a guy who found a game site which paid out when you won. One game was a "find words in this jumble", so he wrote a program which took screenshots, did image recognition, and then did a dictionary search on it for that. Then clicked on the tiles to win. This code reminded me of that for some reason.

teawaterwire16:11:32

Bonjour, I’ve got a boot task dev including something like this: (sift :add-jar {'foo/bar #"somefiles"}) My :dependencies key contains [foo/bar "0.0.1-SNAPSHOT"] that represents a local dependency installed from another project bar with the task (install) Issue: boot dev works fine in this setup but if I add a :checkouts for foo/bar (as per https://github.com/boot-clj/boot/wiki/Checkout-Dependencies) then the boot dev fails:

java.lang.IllegalArgumentException: Provided artifact is missing a version: [nil]
        clojure.lang.ExceptionInfo: Provided artifact is missing a version: [nil]
What could be the reason for that?

alandipert17:11:30

dominicm haha, a friend and i did something like that in VB on AOL. we won prizes but they never sent to us :-(