This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-25
Channels
- # announcements (2)
- # babashka (35)
- # beginners (74)
- # calva (26)
- # cider (14)
- # clojure (74)
- # clojure-dev (27)
- # clojure-europe (9)
- # clojure-italy (2)
- # clojure-nl (2)
- # clojure-spec (10)
- # clojure-uk (9)
- # clojuredesign-podcast (6)
- # clojurescript (40)
- # data-science (1)
- # datalog (7)
- # events (1)
- # figwheel-main (13)
- # fulcro (11)
- # graalvm (58)
- # helix (4)
- # jobs (4)
- # jobs-discuss (9)
- # kaocha (23)
- # malli (5)
- # meander (112)
- # membrane (7)
- # off-topic (13)
- # pedestal (2)
- # re-frame (4)
- # reitit (1)
- # rewrite-clj (1)
- # rum (2)
- # sci (3)
- # shadow-cljs (79)
- # sql (12)
- # tools-deps (17)
- # vim (15)
- # vrac (11)
- # xtdb (6)
anyone know of a way to check at runtime if you're running inside a native image vs on a regular JVM?
took a lot of trial and error but I managed to get funnel to daemonize/background itself
some gnarly JNI shenanigans... still need to clean this up but might do a write-up later
actually the thing that took the most time was trying to somehow statically include my native code in the final executable, because it's just one tiny function, it seemed so silly to have to distribute a separate .so for that... tried all kinds of linker options and read tons of stuff online until finally decided that it can't be done 🙂 then figured out a great hack around it. Include the .so
as a resource, copy it to the filesystem when starting up and then load it from there
sounds pretty nifty!
so for linux you have .so
, macos .dylib
, and windows .dll
and choose among them at runtime?
@plexus If you are going to do a writeup, might want to also put it in clj-graal-docs
@plexus The resource hack has already been done before as part of spire, https://github.com/borkdude/clojure-rust-graalvm and some others
Here's some Clojure code which illustrates it: https://github.com/borkdude/clojure-rust-graalvm/blob/044ef3c921e7b2c9058e431a62574d85b1079011/clojure/src/clj_rust/core.clj#L10
Here are already some docs about interacting with native libraries: https://github.com/lread/clj-graal-docs#interfacing-with-native-libraries
@plexus CircleCI and Github Actions have so that should not be too hard to get around
Not too long ago I didn't have access to Windows so I debugged everything on appveyor. A bit tedious but it works. Having SSH access makes all the difference for getting fast feedback though.
You might want to poke @marc-omorain for macOS access if it's not enabled for your open source project yet, if you go with CircleCI
this is the one project where we're using GH actions actually, although generally my intention is to migrate towards GH actions for the other LI projects as well
https://github.com/lambdaisland/funnel/commit/be69644044f632b91d41a4f22062f20eb7da5104
some code I cargo culted from this example http://jnicookbook.owsiak.org/recipe-no-029/ as far as I understand it changes the working directory of the process to "/", which I'm guessing is so that it becomes independent of the location where it was started, for instance if the directory it was started from gets deleted
I've been considering some function in babashka to do this, but the JVM itself doesn't support this
you could in theory do the same thing on the JVM, but I believe it's not considered safe. It may also not be safe in this case, time will tell
https://blog-old.headius.com/2009/05/fork-and-exec-on-jvm-jruby-to-rescue.html > Update: The biggest problem with using fork+exec in this way is that you can't guarantee nothing happens between the fork call and the exec call. If, for example, the JVM decides to GC or move memory around, you can have a fatal crash at the JVM process level. Because of that, I don't recommend using fork + exec via FFI in JRuby, even though it's pretty cool.
yes, but then it's not detached from the parent shell process. If you close the shell it will kill the child
the direction I'm going now is that tools like kaocha-cljs2 that need it will try starting it in the background. If there's already one running then it's a no-op.
although at this point I'd like users to install and run it themselves, so they know it exists, since it's a good place to look when troubleshooting
@plexus I guess you can also use java.lang.ProcessBuilder to run one in the background, without daemonizing
but then it would only live as long as the test runner process, that defeats the purpose
If you start a subprocess from a Java process the child isn’t terminated when parent exits - that’s a typical behavior in Linux
> Funnel provides persistence and discoverability. It keeps connections to long lived processes (like a browser), so that short-lived processes (like a test runner) can discover and interact with them . This is why we recommend running Funnel as a separate long-lived process, rather than for instance embedding it into the tool that uses it.