This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # asami (19)
- # babashka (41)
- # beginners (115)
- # biff (7)
- # calva (78)
- # clj-kondo (29)
- # cljs-dev (9)
- # clojure (39)
- # clojure-europe (17)
- # clojure-gamedev (29)
- # clojure-nl (1)
- # clojure-norway (9)
- # clojure-spec (2)
- # clojure-uk (3)
- # clojurescript (7)
- # core-async (26)
- # cursive (16)
- # datomic (13)
- # emacs (1)
- # events (5)
- # fulcro (2)
- # funcool (4)
- # gratitude (1)
- # helix (1)
- # holy-lambda (1)
- # humbleui (1)
- # introduce-yourself (4)
- # java (1)
- # jobs (2)
- # jobs-discuss (9)
- # lsp (28)
- # matcher-combinators (2)
- # mathematics (1)
- # membrane (1)
- # nbb (12)
- # off-topic (10)
- # pathom (52)
- # polylith (38)
- # portal (32)
- # re-frame (4)
- # reagent (16)
- # reitit (2)
- # remote-jobs (1)
- # reveal (1)
- # rewrite-clj (10)
- # sci (67)
- # shadow-cljs (45)
- # squint (1)
- # tools-build (13)
- # tools-deps (16)
Hi! On NixOS I get
1: (babashka.process/exec ["echo" "foo"]) ^--- exec is not supported in non-GraalVM environments
bb -e '(babashka.process/exec ["echo" "foo"])'. Any ideas why? As far as I understand it, the check and error message is only supposed to show up when using
babaska.processas a JVM dependency from Clojure.
I'm not sure how the nixos binary is compiled. Can you try the binary that babashka distributes via github releases?
nixos binary is compiled using
buildGraalvmNativeImage https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c6b212a18bdf2433e71/pkgs/build-support/build-graalvm-native-image/default.nix you can see the build args in
extraNativeImageBuildArgs passed in here https://github.com/NixOS/nixpkgs/blob/9e7feda53c23bd24a5c40874b242b6a0ef735a2e/pkgs/development/interpreters/clojure/babashka.nix#L14
But it's probably out of scope for you to debug. I'll try to find out what's going on.
the check that is done to enable exec is here: https://github.com/babashka/process/blob/be047624edac65c3c648adace291bba38cd1a933/src/babashka/process.cljc#L510 it checks at compile time if the graalvm class is available
so if the uberjar is built using openjdk / non-graalvm it will still fail probably. it's recommended to build both the uberjar and native-image using the same graalvm
Ah, that probably explains it. It uses the babashka-standalone jar from the github releases.
that is probably the issue...
openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment 18.9 (build 11.0.15+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+10, mixed mode, sharing)
@U0303ET1R2T Yes, this was it. old:
$ $GRAALVM_HOME/bin/java -classpath "$(clojure -Spath):babashka-1.0.165-standalone.jar" clojure.main -e "(require '[babashka.process]) (babashka.process/exec [\"ls\"])" Execution error (ExceptionInfo) at babashka.process/exec (process.cljc:542). exec is not supported in non-GraalVM environments
The new error is what I would expect since I'm not running with native image here, but if you compile it to native with this uberjar, exec should work
$ $GRAALVM_HOME/bin/java -classpath "$(clojure -Spath):babashka-1.0.166-SNAPSHOT-standalone.jar" clojure.main -e "(require '[babashka.process]) (babashka.process/exec [\"ls\"])" Execution error (Error) at org.graalvm.nativeimage.impl.ImageSingletonsSupport/checkInstalled (ImageSingletonsSupport.java:69). The class ImageSingletons can only be used when building native images, i.e., when using the native-image command.
You can grab the new uberjar from here: https://github.com/babashka/babashka-dev-builds/releases/tag/v1.0.166-SNAPSHOT
I've found this useful (it has
clojure.core/swap! semantics but applies to files):
if there's any interest I could raise a PR for babashka/fs...
(defn swap-file! "Swaps the contents of file to be: (apply f current-contents-of-file args). f should be free of side effects. Returns the value that was swapped in." [file f & xs] (let [old-val (slurp file) new-val (apply f old-val xs)] (spit file new-val) new-val))
I'm not so sure about the name (or the trailing
! since no other function in
babashka.fs uses it),
swap-file! kind of resembles swap! but
replace-file might be more intuitive and
update-file more familiar? :thinking_face:
Happy to change any part of it, just let me know on Github/here (it's a bit late here though so I might not see it until tomorrow)...
maybe it shouldn't be called
swap-file! as it's not free of race conditions (another thread/process can write between the slurp and the spit). It could be made thread safe though with some file locking (but I'm unsure how portable such file locking can be made. Im only familiar with fcntl style locking on posix)
> another thread/process can write between the slurp and the spit
That's true @U1QQJJK89! However, a file is a shared resource that is not really owned by the JVM so I'm not sure how easy it is to prevent external processes from accessing it (especially across platforms) 😞
I think it can be made thread-safe (within the JVM process) with
clojure.core/locking on the file but then the test becomes a bit weird (I have to add a Thread/sleep and a couple of futures) and it causes other problems, e.g. potential deadlock
In clj-kondo I have some inter-process locking stuff, but I think that's going too far for this function. The 99.9% scripting case is covered here
we can just add to the docstring that it isn't thread-safe, but I think the docstring already reflects that
Also f doesn't need to be free of side effects here, as it is only ever run once. Could remove that part of the docstring.
f should just be a function that processes a string. That's not to say you can't have side effects in it at all, it's just weird.
The PR was merged (thanks @U04V15CAJ!) but go ahead and suggest a fix if you think the docstring is misleading 🙂.
It's ok, was just noting. In swap! functions need to be free of side effects because they can be rerun multiple times. This being only run once you are free to add a side effect without problems. Maybe you want to increment a counter on how many times the file has been updated. You could do this in your function here if you wanted to without ill effect.