Fork me on GitHub

@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


(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


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!




i should steal that little bit of code from you 😉


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 😃


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


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