This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # asami (44)
- # babashka (62)
- # beginners (84)
- # calva (42)
- # cider (5)
- # clj-kondo (32)
- # cljs-dev (8)
- # clojure (61)
- # clojure-australia (3)
- # clojure-berlin (1)
- # clojure-europe (12)
- # clojure-japan (3)
- # clojure-nl (4)
- # clojure-serbia (5)
- # clojure-spec (1)
- # clojure-uk (9)
- # clojurescript (31)
- # community-development (21)
- # conjure (5)
- # cursive (17)
- # datomic (14)
- # emacs (10)
- # etaoin (1)
- # figwheel-main (1)
- # fulcro (9)
- # garden (5)
- # graalvm (16)
- # helix (7)
- # honeysql (13)
- # jackdaw (25)
- # jobs (2)
- # lsp (21)
- # malli (25)
- # missionary (2)
- # mount (3)
- # off-topic (12)
- # practicalli (3)
- # re-frame (43)
- # reagent (45)
- # reitit (36)
- # releases (6)
- # remote-jobs (2)
- # reveal (28)
- # rewrite-clj (7)
- # shadow-cljs (45)
- # slack-help (4)
- # spacemacs (5)
- # sql (23)
- # startup-in-a-month (7)
- # tools-deps (59)
- # vim (26)
I'm trying to work on a babashka script using CIDER.
I've manually added a
src directory to the classpath.
How can I reload changed namespaces which are defined under
seem to reload the
(require '[babashka.classpath :refer [add-classpath]]) (add-classpath "src") (ns user (:require [ns.under.src.dir])) ns.under.src.dir/some-new-symbol
in normal Clojure
:reload-all also works, not sure if that is currently supported as well in babashka. this will cause all dependent namespaces to be reloaded
we don't have a lot of code yet, but some of the code is used from both babashka and jvm clojure. it's just confusing to have different workflows and different dependency specification conventions, depending on the execution environment. im not the only one on the team, so we would need to explain this to 4 other ppl too.
feel free to create an issue about this, if this is something that can be improved in babashka(.nrepl)
No idea if this is babashka related, Admin can remove if it doesn’t belong. 😃
(.format (java.time.LocalDateTime/now) java.time.format.DateTimeFormatter/ISO_OFFSET_DATE_TIME) => clojure.lang.ExceptionInfo: Unsupported field: OffsetSeconds
same would happen on jvm, but that format would work for e.g. `(.format (java.time.OffsetDateTime/now) java.time.format.DateTimeFormatter/ISO_OFFSET_DATE_TIME)`
My Google-foo is failing me - does bb include nrepl client? I know that there's a server implementation, but I can't find any reliable info about client support. I'd like to replace
lein repl :connect ... with bb in some way.
@lukaszkorecki There is not a client, but there is a library which allows you to implement a basic one fairly quicky. https://book.babashka.org/#_interacting_with_an_nrepl_server
I do have a natively compiled version of reply too, but this is just an experimental project.
Good! I'm prepping us for a security audit, so I'm a bit too paranoid these days. Re nrepl - most of the times we need to run a single command, but in some cases we need a full on connection to debug something in the live system, so I want to standarize our tooling and reduce its footprint (pulling a whole docker image with lein for this works, but is.... excessive)
but I guess you could also connect to the production repl from your local emacs / other via an ssh tunnel?
Technically yes, in practice - the company policy prohibits that (did I mention audits?)
yes. so the same developer can have access to this prisoned nREPL client box somewhere else? how is that more secure?
You have to jump through a couple of hoops to get to the machines which can start nrepl sessions. Now that I think about it - connecting from your local computer wouldn't work because we cannot open reverse tunnels in the first place.
assuming bb doesn't have to carry a ton of extra deps for this, it will be more like the above script, but better executed and built in
Let me check out
reply-cli - if it can do both interactive sessions and one-off evaluations it might be better than bundling the client with bb
I haven't published reply-cli publically because I hacked the code as quickly as I could to a working state
A new version of sql pods is out. This release adds better support for inserting and retrieving arrays. https://github.com/babashka/babashka-sql-pods/blob/master/CHANGELOG.md#v003 Babashka sql pods allow you to interact with databases like PostgreSQL, Oracle and MS SQL
It is like shelling out but more integrated, so you can just do function calls without having to do de/serialization yourself
See https://github.com/babashka/pod-registry for a list of available pods and examples
I want to be able to add features to babashka without bloating the binary too much with stuff that isn't used widely. You can either do this via libraries (I might implement the nREPL idea using a library instead), but bb libraries have the limitation that you can not access Java classes that aren't available in the bb image. You can also shell out to other binaries via clojure.java.shell or babashka.process, which works well, but is sometimes cumbersome. Also I had some ideas about FFI but this is not very extensible from the Java side (yet). So babashka pods are a kind of higher level FFI (with more overhead, e.g. we serialize args via json or transit, RPC-style) but it works well and performance is generally fast enough for scripting tasks.
bb/fs is not a pod, but just a library. you can use that in Clojure as well. But pods are also runnable in Clojure using the pods library (https://github.com/babashka/pods)
Thanks a lot for the explanation @borkdude! As always Clojure culture seems to favour real-world pragmatism. I love it!
I found this one easy to read and understand (though that’s probably because I mostly write Go) https://github.com/babashka/pod-babashka-go-sqlite3/blob/main/main.go
Cool! Although https://github.com/borkdude/sci/issues/549 made me wonder if we should continue supporting this as is, or that we should only support some pre-selected combination of interfaces. Which will then break if we add one more interface to it. I'm starting to think it would be safer to not support reify at all anymore... :(