@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]))

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

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

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

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

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

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

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

what do you mean?

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

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

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

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

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

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

it always works on my machine™ 😛

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

(software jiggle.boot: https://gist.github.com/alandipert/ebf65762a3f62076ac7b35569567bb37)

truly an outstanding feat of software engineering

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.

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]

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