This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-12
Channels
- # announcements (1)
- # aws (1)
- # beginners (182)
- # boot (33)
- # calva (87)
- # cider (3)
- # clj-kondo (2)
- # clojure (108)
- # clojure-dev (73)
- # clojure-europe (2)
- # clojure-italy (27)
- # clojure-nl (22)
- # clojure-norway (1)
- # clojure-spec (1)
- # clojure-uk (122)
- # clojurescript (78)
- # cursive (5)
- # datomic (17)
- # duct (2)
- # emacs (25)
- # events (3)
- # figwheel (1)
- # figwheel-main (1)
- # fulcro (88)
- # kaocha (6)
- # leiningen (2)
- # luminus (1)
- # lumo (4)
- # nrepl (4)
- # off-topic (37)
- # onyx (1)
- # re-frame (35)
- # reagent (1)
- # reitit (4)
- # shadow-cljs (8)
- # spacemacs (22)
- # specter (2)
- # sql (19)
- # tools-deps (12)
- # vim (11)
@flyboarder Some scripting in JVM Clojure 🙂 https://github.com/jeroenvandijk/clojure-scripting
Maybe boot.pod could later be used for classpath isolation
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
@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
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
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
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
nice 🙂
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