boot 2019-04-12

Maybe boot.pod could later be used for classpath isolation

^this looks really cool! a promising idea

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 Thanks for sharing. You have put a lot more thinking into this than I did 🙂

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

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

and it makes installing boot slightly harder

there are ways that we could mitigate those problems, though

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

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

at least for scripting

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

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

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

yeah, the classpath makes things difficult

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

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

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

@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

great work here!

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

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

prepl is pretty straight forward though

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

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

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

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

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?

profile.boot will always come from the Home

boot.properties can be local to the project location