boot

:boot-clj: https://boot-clj.github.io/ — build tooling for Clojure. Dev chat in #boot-dev
2019-04-12T17:14:02.000300Z

@flyboarder Some scripting in JVM Clojure 🙂 https://github.com/jeroenvandijk/clojure-scripting

2019-04-12T17:14:37.001Z

Maybe boot.pod could later be used for classpath isolation

dave 2019-04-12T17:43:11.001500Z

^this looks really cool! a promising idea

dave 2019-04-12T17:45:17.002400Z

i was interested in the idea of a client/server architecture for boot, many moons ago. i discussed some thoughts on that here: https://github.com/boot-clj/boot/issues/106

1
dave 2019-04-12T17:45:56.003300Z

at the time, i was thinking that we could use something like ZeroMQ for IPC, but prepl seems like a much better fit

dave 2019-04-12T17:46:01.003500Z

at least for scripting

2019-04-12T17:46:55.003800Z

Yeah i've just started playing with it, but so far it just works 🙂

2019-04-12T17:47:25.004500Z

The only problem is that you are not protected from classpath conflicts between individual processes

2019-04-12T17:47:46.005100Z

But we'll have to see if that's a real life problem

dave 2019-04-12T17:47:52.005300Z

yeah, the classpath makes things difficult

dave 2019-04-12T17:47:59.005600Z

boot.pod seems like the right tool for the job there

2019-04-12T17:48:35.006300Z

the only thing is that boot.pod seems to be slow (boot time is around 1-2 seconds). But you could use a pool

2019-04-12T17:49:10.007100Z

right now i'm creating and deleting a namespace for every script. So you won't run into issues with simple scripts

flyboarder 2019-04-12T17:54:54.008Z

@dave @jeroenvandijk yeah client/server is where we would like to take boot, plus classpath isolation we should be able to have a really fast and robust architecture

2019-04-12T17:55:08.008200Z

nice 🙂

flyboarder 2019-04-12T17:55:14.008400Z

great work here!

flyboarder 2019-04-12T17:55:26.008800Z

I havnt played with prepl at all but how does it compare to nrepl?

2019-04-12T18:00:02.009800Z

actually I'm not too sure I haven't talked against an nrepl

2019-04-12T18:00:16.010300Z

prepl is pretty straight forward though

2019-04-12T18:01:16.011600Z

you give it input via a socket and you listen on the output stream of that socket. You can easily distinquish output, values and exceptions

2019-04-12T18:02:12.012500Z

It was pretty tricky to do as little as possible in the client. GraalVM doesn't like greater clojure very much

2019-04-12T18:17:26.012600Z

@dave Thanks for sharing. You have put a lot more thinking into this than I did 🙂

dave 2019-04-12T18:19:22.012800Z

i guess using GraalVM for the client would imply that boot would need to be distributed as 2 executables, the client and the server

dave 2019-04-12T18:19:54.013Z

which wouldn't be the worst thing in the world, but it is at least somewhat error prone because e.g. it would be possible for a user to accidentally have a client/server version mismatch

dave 2019-04-12T18:20:11.013200Z

and it makes installing boot slightly harder

dave 2019-04-12T18:20:42.013400Z

there are ways that we could mitigate those problems, though

dave 2019-04-12T18:20:57.013600Z

for example, the client could automatically install the correct version of the server for you

flyboarder 2019-04-12T18:23:57.014200Z

@jeroenvandijk yeah you need to provide a lot of hints to get GraalVM to work nicely, and of course no dynamic loading

2019-04-12T21:09:58.016900Z

Hey all - I was having some performance issues around tasks like boot uber and jar (reasonably big project with lots of deps).. I'm trying to reduce the aot size to help - but I also realized that my .boot is on nfs... Is it possible to configure boot to use the profile.boot and boot.properties from the nfs ./boot but put all of its caches and boot generated data on local disk (ie. /tmp/.boot or something) ?

2019-04-12T21:10:32.017700Z

As far as I can see I can set $BOOT_HOME to /tmp/.boot but then boot will look for profile.boot and boot.properties there too, right?

flyboarder 2019-04-12T22:03:56.018Z

profile.boot will always come from the Home

flyboarder 2019-04-12T22:04:16.018400Z

boot.properties can be local to the project location