This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-08
Channels
- # announcements (6)
- # babashka (78)
- # beginners (84)
- # bristol-clojurians (5)
- # calva (50)
- # chlorine-clover (45)
- # cider (14)
- # clj-kondo (18)
- # cljs-dev (2)
- # clojars (2)
- # clojure (387)
- # clojure-android (3)
- # clojure-europe (6)
- # clojure-gamedev (3)
- # clojure-germany (3)
- # clojure-nl (18)
- # clojure-spec (5)
- # clojure-uk (36)
- # clojurescript (8)
- # clojurex (1)
- # conjure (1)
- # css (1)
- # cursive (32)
- # data-science (1)
- # datomic (11)
- # docker (61)
- # duct (17)
- # emacs (7)
- # figwheel-main (3)
- # fulcro (19)
- # jobs-discuss (3)
- # joker (1)
- # leiningen (23)
- # malli (11)
- # mount (6)
- # off-topic (30)
- # pathom (14)
- # pedestal (2)
- # phzr (1)
- # re-frame (11)
- # reagent (3)
- # reitit (5)
- # ring-swagger (3)
- # rum (1)
- # shadow-cljs (113)
- # slack-help (9)
- # spacemacs (16)
- # specter (4)
- # sql (14)
- # vscode (2)
- # windows (3)
- # xtdb (12)
@borkdude @bherrmann @dominicm success with building and running babashka on aarch64
I can wholeheartedly recommend the Azul Zulu Embedded JVM for (low performance) ARM systems. It is fast enough that developing normal Clojure on a Raspberry Pi Zero was actually feasible.
Does anyone have a pointer for reading the output of a ProcessBuilder thus far without blocking?
@rovanion the Process returned by ProcessBuilder has an outputstream you can read from
Yes, but how do I read the output written by the process so far, and not get blocked waiting for more?
(On my system it's the InputStream that carries the stdout of the process, but I assumed that was what you meant or that I'm confused, either way it was not important to the question at hand.)
@rovanion you can maybe use (pos? (.available input-stream))
to poll for more input.
@rovanion you can also read input in a core async thread and then put the input on a channel, or read input in a future and handle it there
Hi. I am wondering if I’d be feasible to release Babashka as AWS lambda custom runtime ? For simple lambdas that could benefit from the fast start up
@dennisa see https://github.com/dainiusjocas/babashka-lambda (made by @dainius.jocas) for an example
@dennisa No. If you only use babashka scripts, you don't need GraalVM, only the bb binary, which you can download from Github releases
Note that babashka v0.0.80 is the newest and also has babashka.curl which uses curl to do HTTP requests. You might also be able to leverage that instead of clj-http-lite which was used by Dainius. Although he mentioned that shelling out to curl did have some slowness associated with it, which could be related to environment specific settings like memory availability
@dennisa Note that Dainius' lambda environment is ready to use from here: https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:209523798522:applications~babashka-runtime
I've come to a point where I can can read only the available bytes. But I'm allocating a byte array for each read I do which is inefficient and meh: http://paste.ubuntu.com/p/yBPHNYCt75/
What I really want is a BufferedReader which doesn't block when there is no more to read from the stream...
I think this is incorrect: stdout (.getErrorStream process) stdin (.getErrorStream process) stderr (.getErrorStream process)
You can do (pos? (.available is))
to detect is something is available and then either read or not
@lilactown I've added something like this now in the sigint-handler
branch:
(require '[babashka.signal :as signal])
(def proc (let [pb (ProcessBuilder. ["yes"])
p (.start pb)]
p))
(signal/add-sigint-handler! :quit (fn [] (println "bye1")))
(signal/add-sigint-handler! :quit2 (fn [] (println "bye2")))
(signal/add-sigint-handler! :quit3 (fn [] (.destroy proc)))
(.waitFor proc)
Welcome to give some feedback on it. Note that on my machine, even without the sigint-handlers, the proc goes away, i.e. I see no yes
process running after the script is killed.
Binaries are available in #babashka_circleci_builds. Maybe the signal handler functions should at least receive the key with which they were registered. Maybe that's not necessary because you can just close over your own key if you want.@lilactown I also tested the above on linux: the process goes away when I kill the script (without adding a sigint handler)
A working implementation of the read as much data as is available code I've been on about the whole day.
@rovanion Cool! Note that .waitFor
also returns the exit code so you could also do {:exit-code @(:future-exit-code process)}
possibly
@lilactown This script is now in the tests:
(require '[babashka.signal :as signal])
(signal/add-interrupt-handler! :quit (fn [k] (println "bye1" k)))
(signal/add-interrupt-handler! :quit2 (fn [k] (println "bye2" k)))
(System/exit 0)
It prints:
bye1 :quit
bye2 :quit2
API is still up for discussion. I think a better name might actually be add-shutdown-hook or somethingI'm not able to (require '[clojure.data.csv])
when using bb --nrepl-server
. Is there a special trick I am missing?
@mitchell_clojure works over here:
thanks, I have a hunch that it might have something to do with my local maven repo
it is unable to find clojure.data.csv on my classpath
@mitchell_clojure clojure.data.csv is built into babashka, so you don't need a classpath
I'm just running bb --nrepl-server
. Do I need to do anything else?
@mitchell_clojure cider-connect
oh yup, have done that too
I'm on version 0.0.80, not sure if anything has changed since that might affect this
localhost:1667
v0.0.80 is what I'm running here as well. if the buffer in which you are evaluating associated with that cider session?
according to the output from bb
yes it is
yeah, a few
Okay will do, have a meeting right now but will let you know the resolution
thanks again
@lilactown Ah, I found something much simpler without introducing a new namespace:
(import '[java.lang Runtime])
(-> (Runtime/getRuntime) (.addShutdownHook (Thread. #(println "bye"))))
@(promise)
Press ctrl-C and it prints bye, both in Clojure and bb 🙂@lilactown Btw, could you verify the behavior of this one?
(def proc (let [pb (ProcessBuilder. ["yes"])
p (.start pb)]
p))
(.waitFor proc)
When I press ctrl-c, the yes process isn't running anymore afterwards@borkdude what I’m finding is that running socat
and then calling .waitFor
on the process obj does kill socat when I CTRL-C
doing the same with yes
does not exhibit this behavior; the yes
process does not persist whether or not I .waitFor
hmm, ok. a similar issue like @U0510902N reported apparently. I wonder if adding the shutdown hook helps here as well.
yeah it’s strange. creating multiple socat
processes and .waitFor
ing one of them, causes all of them to exit when I CTRL-C the bb
process.
however, not .waitFor
ing causes all of the processes to persist after the bb
script is done evaluating.
so in the case I’m running into, it seems like CTRL-C propagates the terminate signal to subprocesses, but the script exiting does not? I’m a little out of my depth now so not sure if my verbiage is right
following up on my issue earlier, I restarted everything and the nrepl server appears to work well. I just get a few warnings about being unable to determine nrepl/clojure versions. Issue was with helm
One small thing I noticed was that (do (println "test") (System/exit 0))
prints then exits when using the socket repl, but does not appear to print when using nrepl
how it's currently implemented: the entire expression is evaluated within a with-out-str
and then that output gets sent to the client. but as the server is already killed by then, you won't ever see the println
Oh okay, so I do not have to worry that previous expressions weren't evald
Awesome, thanks again. I showed bb at a lunch and learn today and there is definitely some buzz at our place, especially with nrepl up and running
bb v0.0.81: adds java.lang.Runtime
to support shutdown hooks. See https://github.com/borkdude/babashka/#shutdown-hook.
https://github.com/borkdude/babashka/releases/tag/v0.0.81