Fork me on GitHub

This is kind of a weird use case, but I'm sharing in case. From a babashka REPL in Emacs, I evaluated:

(babashka.process/shell {:out :string} "pandoc" "-f" "markdown" "-t" "json")
This is hanging because pandoc is waiting for something on STDIN. When no input file is provided, pandoc should be used like this:
echo '_tihi_' | pandoc --from markdown --to json
But! M-x cider-interrupt wasn't able to stop the evaluation of the expression, and I had to restart Emacs to continue. If I M-x cider-interrupt from a JVM REPL, I trigger an 1. Unhandled java.lang.InterruptedException, and I gain control back.


CIDER interrupt doesn't work in babashka as it relies on Thread#stop which is deprecated and not implemented by GraalVM

👍 4

You could however process/destroy the process, but this requires you to not block on it

👍 2

with a timeout

👍 2

Nice, thank you. I'll fix my code. Interestingly, this is not a problem when I just run my script and rely on lsp+clj-kondo -- which I usually do when I write babashka scripts. Then C-c just works.


because it kills the entire bb process

👍 2

you can always do cider-quit to kill the cider nrepl

👀 2

M-x cider-quit waited for a while and gave me a "Sync nREPL request timed out (op close)" (when the repl was waiting for (babashka.process/shell {:out :string} "pandoc" "-f" "markdown" "-t" "json"))


maybe because the processing of messages is single-threaded in the bb nREPL


which can be fixed


but maybe CIDER should also support killing the nREPL server no matter what


Are you seeing the same behavior on your end?


haven't tested

👍 2

I'm not going to speculate on how this should be solved, but I would prefer to be able to get back into a working state without restarting Emacs.


@U3X7174KS is this a jacked-in cider repl? if yes, another work around is to start the repl in a terminal and connect cider to it. when it blocks like this next time ctrl+d in the terminal should get the control back to you in emacs.

👍 4

Right, that's a good idea. Then I can also kill the separate process normally.


Do you guys normally start your REPL from outside the editor?


i for one do it always. jack-in is too complected

👍 2

I used to do this a lot, since I wasn't a fan of jack-in but for the reverse reason: if your editor dies, your REPL dies with you. But nowadays I've sometimes been won over by the convenience

👍 2

me being in neovim, my editor almost always ends really often and wanna keep the REPL running 😄

😁 2

The ClojureStream #babashka workshop hosted by contributor / maintainer and power user @rahul080327 will take place at: 4 Mar 2023 08:00 AM EST / 14:00 CET/ 13:00 GMT


With some hack I was able to make (require '[ :refer [refresh]]) work in bb:

$ rlwrap bb -Sdeps '{:deps {org.clojure/tools.namespace {:mvn/version "1.3.0"}}}'

user=> (require '[ :refer [refresh]])
After that, evaluate:
(intern 'clojure.core (with-meta '*loaded-libs* {:dynamic true}) (ref #{}))
since SCI doesn't have *loaded-libs* yet. And also evaluate:
(alter-var-root #' (constantly (fn [] (map  (babashka.classpath/split-classpath (babashka.classpath/get-classpath))))))
since assumes class loader stuff that bb doesn't currently have But after that it's smooth sailing :) It's been asked here a few times, I think last time by @eveningsky

👀 2

Not me. But I'm pretty sure I have commented on related threads, so I guess having my name can't hurt anything if trying to search the archives. 😎


Oh. I see. Yeah. It was a dependency issue, not actually me personally way wanting refresh.


... err .... Looks like refresh was my intent. Why did I forget about that? I cannot even remember what I was trying to accomplish. 😵


ok :) Well, the *loaded-libs* hack shouldn't be necessary anymore on bb master. I'll see if I can also address the clojure.lang.RT/baseLoader issue...


Greetings ! First, thanks for this amazing tool it's been a pleasure using it so far. 🙂 I was trying the uberjar functionality and I think I may have found a bug using it. Am I correct to assume that the folders indicated in bb.edn's :paths should be included by default in the classpath ? So that I can open my issue and maybe try myself at fixing it. 🙂


Yes, this assumption is correct, unless you override the classpath with --classpath or BABASHKA_CLASSPATH


And thanks :)


borkdude@m1 /tmp/ub $ cat bb.edn
{:paths ["src"]}
borkdude@m1 /tmp/ub $ ls src
borkdude@m1 /tmp/ub $ bb uberjar foo.jar
borkdude@m1 /tmp/ub $ zipinfo foo.jar
Archive:  foo.jar
Zip file size: 490 bytes, number of entries: 3
-rw----     2.0 fat        0 bX defN 23-Jan-31 22:34 foo.clj
-rw----     1.0 fat        0 bx stor 23-Jan-31 22:35 META-INF/
-rw----     2.0 fat       59 bX defN 23-Jan-31 22:35 META-INF/MANIFEST.MF


/tmp/nix-shell.azCa5p/tmp.zgqS5zqMye ❯ bb --version
babashka v1.1.172
/tmp/nix-shell.azCa5p/tmp.zgqS5zqMye ❯ ls
bb  bb.edn  foo.jar
/tmp/nix-shell.azCa5p/tmp.zgqS5zqMye ❯ cat bb.edn
{:path "bb"}
/tmp/nix-shell.azCa5p/tmp.zgqS5zqMye ❯ cat bb/foo.clj
(ns foo)
(defn -main [& args] (prn :hello))
/tmp/nix-shell.azCa5p/tmp.zgqS5zqMye ❯ bb uberjar foo.jar -m foo
Exception in thread "main" java.lang.Exception: The uberjar task needs a classpath.
	at babashka.main$exec.invokeStatic(main.clj:1045)
	at babashka.main$main.invokeStatic(main.clj:1104)
	at babashka.main$main.doInvoke(main.clj:1074)
	at clojure.lang.RestFn.applyTo(
	at clojure.core$apply.invokeStatic(core.clj:667)
	at babashka.main$_main.invokeStatic(main.clj:1137)
	at babashka.main$_main.doInvoke(main.clj:1129)
	at clojure.lang.RestFn.applyTo(
	at babashka.main.main(Unknown Source)


:paths should be a vector of strings


I looked quickly at the code and I think the problem is that the cp/get-classpath doesn't take bb.edn paths into account


also it's :paths, not :path


Arf, I'm sure I tried it before but now it works


Sorry for wasting your time, thanks 🙂


No worries, glad it's solved