This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-02
Channels
- # announcements (25)
- # babashka (76)
- # beginners (74)
- # biff (36)
- # calva (11)
- # cider (5)
- # clerk (43)
- # cljs-dev (4)
- # cljsrn (12)
- # clojure (111)
- # clojure-austin (14)
- # clojure-europe (82)
- # clojure-nl (2)
- # clojure-norway (5)
- # clojure-uk (1)
- # clojurescript (36)
- # core-async (13)
- # cursive (30)
- # datomic (12)
- # fulcro (6)
- # honeysql (9)
- # hyperfiddle (73)
- # instaparse (3)
- # introduce-yourself (1)
- # membrane (40)
- # nbb (2)
- # off-topic (6)
- # other-languages (9)
- # polylith (33)
- # reagent (2)
- # reitit (7)
- # rum (7)
- # shadow-cljs (47)
- # tools-deps (10)
- # vim (11)
- # xtdb (16)
with the newest loomed bb, when running bb -e "(set-agent-send-off-executor! (java.util.concurrent.Executors/newVirtualThreadPerTaskExecutor)) @(future (println (.getName (Thread/currentThread))))"
i get a clojure.lang.ExceptionInfo: Method getName on class java.lang.VirtualThread not allowed!
should it be added to the reflection config?
Is that a private class? https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/VirtualThread.html
It seems so: https://github.com/openjdk/loom/blob/3bc882b1b0c93e8f916975ee6a218b7523d23df5/src/java.base/share/classes/java/lang/VirtualThread.java#L68 I think this can be fixed by adding a clause here: https://github.com/babashka/babashka/blob/b8a0520b9381e62b393ac47625e4ceb77a1be00d/src/babashka/impl/classes.clj#L673 Please test locally (with native-image, JVM is not sufficient) and a test
The added clause should not mention the private class, but just: (instance? Thread ..) Thread
Okay will do an issue+PR
@U04V15CAJ any recommended place to put the test?
not sure if any of the existing files quite fit, could go with a new file?
but we could move some of these interop tests to a new file. I've recently added another one in main_test
i can do the tests cleanup in another PR? for this one im creating an interop_test.clj
?
added
decided the empty str check is good enough otherwise i need to use a thread factory to set names
finally needed to add the --enable-preview 😄
neh I guess it's fine. I've made the virtual threads stuff optional so bb can still be compiled with 11-18
yeah its quite necessary for this particular test
I mean, people compiling their own bb (and nix package etc) doesn't care about the tests
im building this little (now much more efficient) DDoS tool in bb, thats how i noticed this issue 😛
hopefully that will be a much more comprehensive loom demo for bb
flaky test failures, the one from me passed
@U7ERLH6JX github actions is failing lein test :only babashka.interop-test/vthreads-test https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:247 https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:248 ERROR in (vthreads-test) (test_utils.clj:100) https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:249 can invoke methods on java.lang.VirtualThread https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:250 expected: (= "" (bb nil "(set-agent-send-off-executor! (java.util.concurrent.Executors/newVirtualThreadPerTaskExecutor)) @(future (.getName (Thread/currentThread)))")) https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:251 actual: clojure.lang.ExceptionInfo: ----- Error -------------------------------------------------------------------- https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:252 Type: java.lang.IllegalArgumentException https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:253 Message: No matching method newVirtualThreadPerTaskExecutor found taking 0 args https://github.com/babashka/babashka/actions/runs/4314843844/jobs/7528417244#step:12:254 Location: <expr>:1:1
i'll take a look in a bit?
Not sure if neil
stuff is applicable on this channel, but I'm getting the following java.util.concurrent.ExecutionException
error. See in 🧵
> neil dep upgrade
----- Error --------------------------------------------------------------------
Type: java.util.concurrent.ExecutionException
Message: java.lang.NullPointerException
Location: /opt/homebrew/bin/neil:1556:3
----- Context ------------------------------------------------------------------
1552:
1553:
1554:
1555: (defn -main [& _args]
1556: (cli/dispatch
^--- java.lang.NullPointerException
1557: [{:cmds ["add" "dep"] :fn dep-add :args->opts [:lib]}
1558: {:cmds ["add" "test"] :fn add-cognitect-test-runner}
1559: {:cmds ["add" "build"] :fn add-build}
1560: {:cmds ["add" "kaocha"] :fn add-kaocha}
1561: {:cmds ["add" "nrepl"] :fn add-nrepl}
----- Stack trace --------------------------------------------------------------
clojure.core/deref-future - <built-in>
clojure.core/future-call/reify--8544 - <built-in>
clojure.core/deref - <built-in>
clojure.core/map/fn--5935 - <built-in>
clojure.core/seq--5467 - <built-in>
... (run with --debug to see elided elements)
clojure.core/seq--5467 - <built-in>
babashka.neil/-main - /opt/homebrew/bin/neil:1556:3
babashka.neil/-main - /opt/homebrew/bin/neil:1555:1
babashka.neil - /opt/homebrew/bin/neil:1616:3
babashka.neil - /opt/homebrew/bin/neil:1615:1
> neil --version
neil 0.1.56
deps.edn
{:paths ["src" "resources"]
:deps {com.cognitect.aws/endpoints {:mvn/version "1.1.12.415"}
com.cognitect.aws/dynamodb {:mvn/version "825.2.1262.0"}
com.cognitect.aws/apigatewayv2 {:mvn/version "821.2.1107.0"}
com.grzm/awyeah-api {:git/url ""
:git/sha "9257dc0159640e46803d69210cae838d411f1789"
:git/tag "v0.8.41"}
org.babashka/spec.alpha {:git/url ""
:git/sha "433b0778e2c32f4bb5d0b48e5a33520bee28b906"}
zprint/zprint {:mvn/version "1.2.3"}
babashka/fs {:mvn/version "0.2.12"}
io.aviso/pretty {:mvn/version "0.1.36"}}
:aliases {:test {:extra-paths ["test"]
:extra-deps {}}}}
It's not blocking me at all, so don't sweat it! 🙂 I was trying to work out a different problem and thought upgrading libs would help... ended up working that out which had nothing to do with the libs (as per usual). Just reporting back here to make the borkstack better :facepunch:
`bb prepare` in Docker
=> ERROR [6/6] RUN bb prepare 0.3s
------
> [6/6] RUN bb prepare:
#0 0.305 Exception in thread "main" java.lang.Exception: Couldn't find 'java'. Please set JAVA_HOME.
#0 0.306 at borkdude.deps$get_java_cmd.invokeStatic(deps.clj:252)
#0 0.306 at borkdude.deps$_main.invokeStatic(deps.clj:608)
#0 0.306 at borkdude.deps$_main.doInvoke(deps.clj:588)
#0 0.306 at clojure.lang.RestFn.applyTo(RestFn.java:137)
#0 0.306 at clojure.core$apply.invokeStatic(core.clj:667)
#0 0.306 at babashka.impl.deps$add_deps$fn__26386$fn__26387.invoke(deps.clj:101)
#0 0.306 at clojure.lang.AFn.applyToHelper(AFn.java:152)
#0 0.306 at clojure.lang.AFn.applyTo(AFn.java:144)
#0 0.306 at clojure.core$apply.invokeStatic(core.clj:667)
#0 0.306 at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1990)
#0 0.306 at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1990)
#0 0.306 at clojure.lang.RestFn.invoke(RestFn.java:425)
#0 0.306 at babashka.impl.deps$add_deps$fn__26386.invoke(deps.clj:101)
#0 0.306 at babashka.impl.deps$add_deps.invokeStatic(deps.clj:101)
#0 0.307 at babashka.main$exec$fn__30987.invoke(main.clj:865)
#0 0.307 at clojure.lang.AFn.applyToHelper(AFn.java:152)
#0 0.307 at clojure.lang.AFn.applyTo(AFn.java:144)
#0 0.307 at clojure.core$apply.invokeStatic(core.clj:667)
#0 0.307 at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1990)
#0 0.307 at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1990)
#0 0.307 at clojure.lang.RestFn.invoke(RestFn.java:425)
#0 0.307 at babashka.main$exec.invokeStatic(main.clj:817)
#0 0.307 at babashka.main$main.invokeStatic(main.clj:1139)
#0 0.307 at babashka.main$main.doInvoke(main.clj:1108)
#0 0.307 at clojure.lang.RestFn.applyTo(RestFn.java:137)
#0 0.307 at clojure.core$apply.invokeStatic(core.clj:667)
#0 0.307 at babashka.main$_main.invokeStatic(main.clj:1172)
#0 0.307 at babashka.main$_main.doInvoke(main.clj:1164)
#0 0.307 at clojure.lang.RestFn.applyTo(RestFn.java:137)
#0 0.307 at babashka.main.main(Unknown Source)
could be the case that bb prepare
is not working with the official Docker
image?
yes. the official docker image does not contain java but only the bb binary and curl
what you can also do is build an uberjar with bb uberjar
and then inside the official image:
bb --classpath uberjar.jar
build the uberjar in an environment where java is available and then copy it into the image
hmm, where can I find a doc about which directories should I sync over for e.g. with a muti stage docker setup?
yes, I guess uberjar could work
I also noticed a small issue with the ubuntu
image, I’ll open a PR in the following days
There are some docs about #nbb (node.js) on google cloud https://github.com/babashka/nbb/blob/main/doc/gcloud_functions.md but I haven't tried running bb on google cloud. Perhaps @U5H74UNSF or @U07SQTAEM?
@U0525KG62 it was easy to get nbb working in that context, as the above sample shows 🙂
blambda implements an event-loop thingie here: https://github.com/jmglov/blambda/blob/main/resources/bootstrap.clj might not be too hard to change for gcloud, but I have no idea if it works similar to that
looks like Pathom might have a thing as well https://pathom3.wsscode.com/docs/tutorials/serverless-pathom-gcf/ (tho obvs that isn't nbb or babashka)
https://book.babashka.org/#libraries
> cheshire.core aliased as json
cheshire.core
works but json
doesn’t. Why? This is my very first bb.edn
.
{:paths []
:deps {org.babashka/cli {:mvn/version "0.4.39"}}
:tasks
{sde-zzeve-com {:doc "Download all JSONs"
:task (let [tables ""]
(-> (org.httpkit.client/get foo)
(deref)
:body
(cheshire.core/parse-string true)
(println))
)}}}
only these fns are available without explicit imports in the context of tasks: https://github.com/babashka/babashka/blob/master/src/babashka/impl/tasks.clj#L224-L236
the aliases mentioned are more from the context of scripting. maybe we can mention this in the book
that's sort of the mention of it: https://book.babashka.org/#_tasks_api
but doesnt say that the others arent there
yeah fully qualified ns should work
should work but always recommended to require
general rule is to require anything thats not clojure.core