This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (6)
- # babashka (17)
- # beginners (70)
- # calva (6)
- # chlorine-clover (88)
- # cider (9)
- # cljs-dev (9)
- # clojure (66)
- # clojure-australia (3)
- # clojure-czech (5)
- # clojure-europe (73)
- # clojure-nl (5)
- # clojure-spec (62)
- # clojure-uk (38)
- # clojurescript (30)
- # cursive (10)
- # datomic (16)
- # events (1)
- # figwheel-main (1)
- # fulcro (6)
- # graphql (21)
- # helix (4)
- # jackdaw (1)
- # jobs-rus (1)
- # kaocha (3)
- # luminus (11)
- # malli (28)
- # pedestal (3)
- # re-frame (2)
- # reagent (3)
- # sci (2)
- # shadow-cljs (21)
- # spacemacs (2)
- # sql (25)
- # timbre (2)
- # tools-deps (9)
- # tree-sitter (1)
- # xtdb (21)
Out of curiosity, is the ebook about babashka still a thing? :)
Everything that has been done about the book is hosted here:
The chapter about child processes is already stale because of
I'm not sure if I want to continue with the book or just make the README pages in the babashka repo better.
As I'm funded by Clojurists Together I spent all my time on development and not writing this book (since the book may be sold for money in the future, something which I'm also not sure about ;))
I would buy it 🙂 If it is good tutorial in the end.
I wonder how many examples from the clojure cookbook work or could be ported to bb: https://github.com/clojure-cookbook/clojure-cookbook
Wrote some docs about "choosing the right http client": https://github.com/borkdude/babashka#choosing-the-right-client For babashka 1.0.0 I envision we can have a http://java.net.http client that replaces all the options.
has anyone ever investigated compiling SCI into C++ with https://ferret-lang.org/ ?
It would surprise me if the sci clojure code was compatible with ferret all the way down. But there is documentation around how to compile sci to a native .so library and how to call it from Python for example: https://github.com/borkdude/sci/blob/master/doc/libsci.md#using-libsci-from-python
I'm considering incorporating https://github.com/borkdude/deps.clj into babashka, so you can use a
babashka.edn to resolve deps without manually having to set
But this will still require a JVM for resolving those deps if these deps aren't already downloaded. :thinking_face:
I like this. Even though you need the JVM for resolving the deps, this is still a big improvement?
At least no / less implicit dependencies
I'm collecting ideas here: https://github.com/borkdude/babashka/issues/473
@UE21H2HHD What's your use case?
I’d like rewrite-cljc scripts to be self contained and at the same time avoid them having the responsibility of altering classpath to bring in deps. More of an elegance thing, I suppose.
I added an alternative suggestion for declaring the deps https://github.com/borkdude/babashka/issues/473#issuecomment-724892457