Fork me on GitHub
#boot
<
2019-04-12
>
jeroenvandijk17:04:37

Maybe boot.pod could later be used for classpath isolation

dave17:04:11

^this looks really cool! a promising idea

dave17:04:17

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

jeroenvandijk18:04:26

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

dave18:04:22

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

dave18:04:54

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

dave18:04:11

and it makes installing boot slightly harder

dave18:04:42

there are ways that we could mitigate those problems, though

dave18:04:57

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

dave17:04:56

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

dave17:04:01

at least for scripting

jeroenvandijk17:04:55

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

jeroenvandijk17:04:25

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

jeroenvandijk17:04:46

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

dave17:04:52

yeah, the classpath makes things difficult

dave17:04:59

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

jeroenvandijk17:04:35

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

jeroenvandijk17:04:10

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

flyboarder17:04:54

@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

flyboarder17:04:14

great work here!

flyboarder17:04:26

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

jeroenvandijk18:04:02

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

jeroenvandijk18:04:16

prepl is pretty straight forward though

jeroenvandijk18:04:16

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

jeroenvandijk18:04:12

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

flyboarder18:04:57

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

mattyulrich21:04:58

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

mattyulrich21:04:32

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?

flyboarder22:04:56

profile.boot will always come from the Home

flyboarder22:04:16

boot.properties can be local to the project location