This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-25
Channels
- # announcements (8)
- # babashka (58)
- # beginners (59)
- # biff (4)
- # calva (39)
- # cider (2)
- # clj-kondo (8)
- # clj-together (4)
- # cljdoc (5)
- # cljsrn (1)
- # clojure (60)
- # clojure-australia (2)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojurescript (13)
- # conjure (10)
- # cursive (9)
- # datomic (5)
- # dev-tooling (1)
- # emacs (6)
- # events (1)
- # graalvm (38)
- # graphql (5)
- # joyride (1)
- # kaocha (3)
- # lsp (23)
- # malli (2)
- # mount (2)
- # off-topic (31)
- # other-languages (13)
- # pathom (3)
- # polylith (12)
- # portal (4)
- # practicalli (22)
- # re-frame (6)
- # reagent (3)
- # releases (3)
- # sql (4)
- # squint (3)
- # tools-build (10)
- # tools-deps (10)
- # xtdb (4)
I have a bb.edn
with:
{:deps {local/build {:local/root "build"}}
:tasks {,,,}}
When I try to run tasks from a different directory using the -f
switch, this will fail as it cannot resolve the :local/root
:
bb -f ../bb.edn tasks
----- Error --------------------------------------------------------------------
Type: clojure.lang.ExceptionInfo
Message: Could not resolve symbol: local/build
Phase: analysis
It seems the :local/root
is resolved from the current working directory, instead of the directory containing bb.edn
. Is this a bug? Is there another way to specify :local/root
to resolve relative to bb.edn
?hey hey @U922FGW59! you could try with --deps-root <dir>
bb --config /path/to/bb.edn --deps-root /path/to/src
Oh man, so I just confused --config
with -f
. Thanks and sorry for not reading properly ☀️
someone here using kubernetes recently is it? 😉
Actually no 😄
But somehow it seemed most natural to use -f
when I want to tell “use that file”
Hello, is there any preferred babashka-compatible library that would offer similar functions as cp/with-shutdown
, cp/threadpool
and cp/upmap
from clj-commons/claypoole
? Basically just some pmap
alternative where one could easily plug a custom-sized threadpool.. Thanks.
I'm not aware of one but if youre willing to create an fixed size java.util.concurrent.Executor and submit tasks to it, should work the same and on bb too
The
{lambdaisland/clj-diff {:mvn/version "1.4.78"}}
library is now compatible with #CLX41ASCS - thanks @plexusIs bb -e '(load-string (slurp "
the best way to run a remote script?
slurp
only works if you don't have any redirections, so maybe babashka.curl
is better
I plan on working on babashka.http-server
based on java.net.http
in the coming quarter or so, so we have one canonical http client that is compatible with babashka.curl and clj-http-ish things
yep, the standard interface to all of this would be awesome
{lambdaisland/deep-diff2 {:mvn/version "2.6.166"}}
is now #babashka compatible as well - thanks @plexus
Demo:
https://twitter.com/borkdude/status/1596115043611205633
I'm writing a blog post for the GraalVM medium blog about babashka. Does anyone want to help with proof-reading?
I can give it a shot!
sure, what is your github handle @U018QDQGZ9Q?
Just caumond: https://github.com/caumond. the joy to have a quite rare name.😁
Just added a ddiff
tool to my bbin-installable scripts:
$ bbin install
$ ddiff <(echo '[1 2 3]') <(echo '[1 2 4]')
[1 2 -3 +4]
With a script wrapping pod.babashka.filewatcher
that bottoms out to calling (tasks/run 'test:bb args)
on change, which (in short, as we discussed a few days ago) runs (exec 'cognitect.test-runner.api/test)
:
If a test is failing, and changed to pass, the passing state will update correctly on the next run. But editing a test to make it fail still reports as passing on every run until quitting the watcher script and starting it over. Same for any new tests. Have to restart the script to pick up any new tests.
Any ideas?
The first example would require knowing what namespaces need reloading. Would tools.namespace offer any ways around that?
I am evaling forms in repl, but in Clojure. The point is to be able to keep an eye on BB compatibility
I'm not exactly sure what you mean. If you can make any kind of repro that I can run locally, that would be easier to say something about
Tried using your fork of tools.namespace to reload changed namespaces, but it throws on requiring clojure.tools.namespace.repl
(which holds the refresh
function).
Could not resolve symbol: clojure.core/*loaded-libs*
@U90R0EPHA this is currently not something in SCI, but I could take a look at that
Not sure I understand what "this" refers to in that statement. I think you are saying SCI lacks *loaded-libs*
? That was what i gathered already from the error.
Brought it up because:
1. It's another data point on attempts to solve ^above.
2. Point it out to you regarding tools.namespace fork. Since you bothered to fork it Babashka, it seems like it would be nice if the primary user-facing API function refresh
was actually usable there.