This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-25
Channels
- # announcements (9)
- # asami (69)
- # babashka (151)
- # babashka-sci-dev (34)
- # beginners (90)
- # cider (21)
- # clj-on-windows (17)
- # clj-otel (4)
- # cljsrn (5)
- # clojure (27)
- # clojure-austin (3)
- # clojure-europe (87)
- # clojure-gamedev (1)
- # clojure-nl (3)
- # clojure-norway (8)
- # clojure-poland (2)
- # clojure-uk (3)
- # clojured (10)
- # clojurescript (50)
- # core-async (73)
- # cursive (28)
- # data-science (2)
- # datomic (17)
- # etaoin (1)
- # honeysql (6)
- # introduce-yourself (3)
- # jobs (1)
- # joyride (12)
- # malli (5)
- # nbb (14)
- # off-topic (18)
- # pathom (4)
- # podcasts-discuss (2)
- # polylith (30)
- # project-updates (3)
- # re-frame (33)
- # reitit (1)
- # remote-jobs (13)
- # shadow-cljs (59)
- # sql (12)
- # tools-build (7)
- # xtdb (36)
Can you handle signals in babashka like pipe-signal-received?
does?
ah, the signal branch 😉
So it's theoretically possible to support, but I haven't so far since that API is officially not stable / public
That API never was stable, right? I'm not an expert on this
And last time I asked that user, it turned out he actually just wanted to use shutdown hook instead of signals directly. Perhaps you have a similar X-Y problem?
I want to build a shell-like tool in babasha. This requires to interrupt "Ctrl-C" and to manually handle it.
Also SIGWINCH
etc.
once it's built I could point you to the right binary or you can try to build yourself
@U054UD60U I don't keep track of which OS you are using, which one was that?
I'm on Macos.
Cool I'll try it
This one should work: https://output.circle-artifacts.com/output/job/67824c07-bf80-4f71-b997-32bfc98a5957/artifacts/0/release/babashka-0.8.3-SNAPSHOT-macos-amd64.tar.gz
user=> (reify sun.misc.SignalHandler (handle [_ _] (println "Got signal" )))
java.lang.IllegalArgumentException: No matching clause: sun.misc.SignalHandler [at <repl>:20:1]
Any idea?will try
A very basic shell implemented in babashka https://gist.github.com/ordnungswidrig/6605483ac429a399a644024a6736ecf0 (Needs a current beta, 0.8.3-SNAPHOT)
This requires the signal branch. But given that you have success with this, should I merge it? ;)
I don't see how the signal branch would do harm, except allowing you to shoot yourself into the foot in more arkane ways.
I only tested on MacOS though.
Followup question, does rebel-readline work with babashka?
(I need to resist this rabbit hole)
Perhaps better luck with #nbb which supports everything the npm ecosystem has to offer
I have no idea how bb is actually working but could jline be provided as a pod?
I made a pod for lanterna: https://github.com/babashka/pod-babashka-lanterna It does work
hmmm, that would give term io but not line editing, right?
I see. That would be another friday 😉
A think like this could work too: xterm https://babashka.org/xterm-sci/ This works in the browser and terminal
$ bbm1 ~/Downloads/babash.bb
Welcome to babash...
ℬ ~/dev/babashka > ls
----- Error --------------------------------------------------------------------
Type: java.lang.IllegalArgumentException
Message: Don't know how to create ISeq from: clojure.lang.Symbol
Hmmm having a look. Probably some copy-and-paste error when editing the gist
$ bbm1 ~/Downloads/babash.bb
Welcome to babash...
ℬ ~/dev/babashka > "ls"
----- Error --------------------------------------------------------------------
Type: java.lang.NoSuchFieldException
Message: trim
I think you should not rely on *input*
in scripts, just use /usr/bin/env/bb
and *in*
or read-line
directly
Yes, maybe that horrible quick hack fires back now :thinking_face:
Btw, did you also know about process/$
?
(require '[babashka.process :as process])
(defmacro $ [& args]
`@(process/$ {:inherit true} ~@args))
($ ls -la)
($ echo "hello")
(let [x "hello"]
($ echo ~x))
Didn't see it.
It allows you to type symbols (as in bash) and unquote resolves variables from the environment
hmmmm, lovely.
@U054UD60U Maybe a library which exposes all kinds of shell commands as functions (which can be composed and output edn data, or so) could work, which you could then run with rebel-readline for awesome terminal editing and could use in scripts with bb too
that sounds tempting
One annoying thing about the JVM is that it doesn't support cd
, so you would have to patch that by keeping track of some directory and then feeding that back into whatever file stuff you're doing.
user> cd "/tmp"
user> ls
Applications Documents
I just use an atom to track what the "shell" considers to be the current directory.
For a shell it's just a special variable which is passed to exec
I guess so, but when you then start moving things around with (fs/copy ..)
it behaves unexpectedly
true. that would require a lot of wrapping maybe. :thinking_face:
A global dynamic var which holds the cwd and several libraries like fs and process would take that into consideration
Maybe there should be a library babashka.cwd
which other libraries in the ecosystem could then also look at
I wonder if the cwd is a concept of posix for a process.
> One excerpt from the bug database that highlights the issues with adding such a call: >> EVALUATION >> This feature can be interpreted in two ways: chdir could change the current working directory of the process containing the JVM, causing all threads to change simultaneously, or to provide a more "virtual" per-thread concept of current directory, which could conceptually be a ThreadLocal. This would be merely a convenience for building up complete path names to pass to the underlying operating system API. >> This is how the current directory works in Emacs - it's just a variable, but a magic one that can have buffer-local values. Emacs buffers are kinda sorta like Java threads in this sense. Such an implementation would offer convenience and safety. Having each thread with a ThreadLocal current directory gives a programmer experience familiar to old Unix greybeards, except that Threads replace Processes. > >
Ha! Emacs knew it already.
Yes, implementing that as a dynamic var would have thread-local behavior. https://github.com/babashka/babashka/issues/1277
What happens when the jvm calls chdir
via jni? :thinking_face: :rolling_on_the_floor_laughing:
Worth a shot. I tried it with setenv
too
https://twitter.com/borkdude/status/1395414219114303489
But the problem is that the environment is cached , so (System/getenv. ...)
calls don't really work
who do other processes do that? is the env updated when chdir
is called?
I have no clue how node.js behaves here.
The problem is that the JVM caches things on startup and considers them immutable: env but also working dir
When I chdir(2)
in a unix process and then later all getenv(3)
to get PWD from it is PWD updated in the env?
It leas that's an env var in bash which contains the current working directory. But maybe something that bash manages.
> process.chdir("/tmp")
undefined
> process.env.PWD
'/Users/borkdude/dev/nextjournal'
> process.cwd()
'/private/tmp'
So I get that the JVM caches things, but does it look up the cwd from the environment or does it (properly) call getcwd(3)
That's nodejs, right?
The JVM just uses an immutable map to cache the env and the cwd (both are separate concerns but with the same problem)
when you exec sh -c pwd
from there, what does it print?
This is why chdir and setenv are both not not working like you would expect in a JVM via JNI
I see.
from nodejs
> process.chdir("/tmp") undefined > child_process.execSync("pwd") <Buffer 2f 70 72 69 76 61 74 65 2f 74 6d 70 0a> > child_process.execSync("pwd").toString()
'/private/tmp\n'
The thing is that the changed env would only be relevant for a spawned sub process. And for that you can use /usr/bin/env
to set all the updated values.
so for nodejs, it's just a cwd value maintained in nodejs but not even passed onto a forked process.
Well, you can already set a changed env for a subprocess:
(process [...] {:extra-env {"FOO" "BAR"}})
child_process.execSync("pwd").toString()
printed the old value?!
/tmp
== /private/tmp
?
Maybe they also hooked "update the pwd" into execSync
?
They probably just mutate the cwd via the C API and everything is consistent with that
Only when you want to support changing the "current directory" for all clojure / babashka code.
I see.
For the specific needs of a shell tracking the "shell current directory" in a dynvar and passing to forked processes is sufficient.
I would not call chdir
via JNI an a JVM because nobody knows what happens 😛
unless "copy files" is a "shell operation"
IOW what you described earlier as wrapping all fs commands
hmmm, good point.
So maybe worth a try. JNI to chdir
and then even
should work?!
in java.io.File? 😱
Just a random google https://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/classes/sun/nio/fs/UnixFileSystem.java#L61
But that's in the solaris port 😆
This is a mess.
https://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/classes/java/io/UnixFileSystem.java this one?
Hi babashkians! https://github.com/clj-commons/etaoin on the Github master branch is now bb compatible. This means you can write your browser tests in #babashka! An example:
(ns etaoin
(:require [babashka.deps :as deps]))
(deps/add-deps '{:deps {etaoin/etaoin {:git/url ""
:git/sha "e1b7df647740536cec7b8528fe4c84ae21f94ab7"}}})
(require '[etaoin.api :as api])
;; brew install geckodriver
(def driver (api/firefox))
(api/go driver " ")
(api/quit driver)

How about calling us The Babushkas
? seems quite fitting 😛
Hehe 👵
It’s a nice luxury with Babashka that I don’t have to worry about which JDK version folks might be using.
A very basic shell implemented in babashka https://gist.github.com/ordnungswidrig/6605483ac429a399a644024a6736ecf0 (Needs a current beta, 0.8.3-SNAPHOT)