cheshire is, you can parse JSON with that

👍 Was just about to guess that 🙂

What determines what goes in to Babashka? In the case of clojure.data.json, it "sounds" more standard than cheshire, but maybe the usage isn't high enough to warrent including it?

3 years ago Cheshire was imo still the dominant JSON library which, by including it, enabled running a plethora of libraries from source. Meanwhile data.json caught up in performance, three years ago it was relatively much slower. You can add data.json to bb in bb.edn - it works from source but because it’s interpreted, it’s not fast to parse a megabyte of JSON. In the future, if data.json might become the defacto JSON lib, perhaps it’s a good idea to include it.

Cool, thanks for the explanation @borkdude

I have considered offering an API to which libraries can program, rather than a specific JSON library so this implementation can be abstracted away, https://github.com/clj-easy/tools.misc

This is probably an nrepl problem. can you try:

(binding [*unchecked-math* *unchecked-math*]
  (require '[malli.core :as malli]))

Please post an issue about it

(binding [*unchecked-math* *unchecked-math*]
  (require '[malli.core :as malli]))

Should i post the issue for nrepl or for bb? I am not sure if it is a problem in nrepl or bb

Is it the same as this one? https://github.com/babashka/babashka/issues/1456

Similar, but not same, but I added your problem to this issue now

there is also this https://github.com/babashka/babashka/issues/1330

That one was solved, and the solution to your problem is similar

so feel free to make a PR if you want

i will try, thank you!

The solution would be to add the unchecked math var here: https://github.com/babashka/babashka/commit/4c0d34b7c8de78c3b54d3d21b41d980da9f41fc3#diff-8afee3c27290022a97944edbbf6ccc957df49cb30cdd41af6cd13f205ddf3138R16

Where should i add a test? I found these tests but it seems this is not the right place? https://github.com/babashka/babashka.nrepl/blob/ad763a78f1bc327a493ff0b650aa5408ecbf4819/test/babashka/nrepl/server_test.clj#L406

why isn't that the right place?

If i add unchecked-math to the place you proposed, the added test still fails. When if remove babashka.impl.clojure.core/warn-on-reflection from :thread-bind [babashka.impl.clojure.core/warn-on-reflection] then the warn-on-reflection dynamic var test still succeeds https://github.com/babashka/babashka/commit/4c0d34b7c8de78c3b54d3d21b41d980da9f41fc3#diff-8afee3c27290022a97944edbbf6ccc957df49cb30cdd41af6cd13f205ddf3138R16 . So I thought that the tests in babashka.nrepl are not related to this.

@U01169S0E0N Ah, this is probably because babashka.nrepl and babashka are separate projects and the tests of babashka.nrepl have a specific configuration, that is decoupled from babashka

I think you should only make changes to babashka, not babashka.nrepl

and also the test should only live in babashka, not in the babashka.nrepl project

could you point me to a place where the test should be in the babashka project?

I'll have a look. We have a copy of those nrepl tests in babashka, but at some point babashka.nrepl was made a library that can be used in babashka-like projects

Those tests are here: https://github.com/babashka/babashka/blob/master/test/babashka/impl/nrepl_server_test.clj

perfect! Thank you

My test fails and i don't know why. Sorry. https://github.com/babashka/babashka/compare/master...axks:babashka:nrepl-unchecked-math

I'll take a look after dinner :)

It was a little more complex so I went ahead and solved some issues. Next time it should be easier. https://github.com/babashka/babashka/commit/3aca5057909ba3b81da594eaa66fd94435484cbb

thank you!!!

I think it's best to add a directory, e.g. bb to your :paths and then just put normal code in there for REPL usage and then hook that up to tasks

unless I am misunderstanding, then I need to split up my tasks across multiple files, when I want it all self-contained in just bb.edn, that's half the beauty of it

You can also spin up an nREPL server as a task: https://book.babashka.org/#_repl_2

Will that repl have the :requires loaded?

if that REPL depends on the other tasks you want to use in the REPL, then yes

All I want to do is work on my tasks in the repl, not actually have the repl as a task, this is strictly for debugging my tasks. I'd like to avoid having to convert my :requires to a form the nrepl understands, but I can live with it

so my tasks don't need the repl to work normally

you make the REPL task depend on the other tasks you want to debug

I'm using conjure which knows to spawn a bb nrepl server when I open bb.edn

ah, ok that might work

thank you

you can spawn an nREPL server programmatically using (babashka.nrepl.server/start-server! {:port 1337})

Yep, but would be nice to let conjure handle it

Oooh, bike-shedding ❤️ I personally prefer as little nesting as possible.

So you prefer babashka.http-client right?

1. What are the odds you will have a future <thing> that will be competing? e.g. a different http-server, but this time also supporting ring, etc. 2. I think nesting is nice, but the question is are we subdividing via domain or library? (e.g. imagine babashka added support aleph, which offers both client and server; would that be babashka.http-client-aleph babashka.aleph.client or babashka.http.aleph-client? 3. In a similar vein, why is it babashka.nrepl.client instead of babashka.repl.client or babashka.repl.nrepl-client? What if we want a different repl implementation?

I think it's babashka.nrepl.server because the original one was called nrepl.server https://github.com/nrepl/nrepl/blob/8c431a07e071e87176942a53f3ed9e2f62a2587a/src/clojure/nrepl/server.clj#L1

Fair enough, but I thought we were bike-shedding about naming conventions. My what-if questions assume you would not be beholden to past decisions :]

I've also considered renaming babashka.http-server to babashka.file-server since it serves static files... but it's not an FTP server, it's still an http server... and it's called like that in other projects like Python too ... Ah well, I think babashka.http-client is just fine then.

OK, another bike-shed for you:

babashka.http-client.interceptors (plural)
babashka.http-client.interceptor (single)

(or perhaps the socket stuff can just live in the main namespace really)

I like singular, but it assumes you agree with this reasoning:

(:require [babashka.http-client.interceptor :as interceptor])

(interceptor/sanitize-request)

interceptor/default-interceptors

(interceptor/defaults) ?

or if you insist:

interceptor/foo
interceptor/bar

;; separae ns:
interceptors/super-secret
interceptors/permissive

speaking about context, defaults tells me less

I might just mash everyhing into the http-client namespace

> speaking about context, defaults tells me less My point was I like to choose names that may not convey enough information without the namespace; so interceptor/sanitize-request vs http/sanitize-request-interceptors It’s just a convention I like to use, but adding the suffix at the end hints that maybe this is a different context (hence namespace)

But the argument “everything goes in http” also works :]

ah you're right, I think I went with the interceptors namespace because I didn't like to suffix every interceptor

Gotta go afk, thanks for the 🚲 @borkdude

https://github.com/babashka/http-client/blob/main/API.md#babashka.http-client.interceptors

you too

Let's discuss in a thread. Yes, but this is a library which serves static files https://github.com/babashka/http-server

One nice thing about its api is that you can pick whether you want to use functions or data, eg (client/send! {:method :get} ... vs (client/get ... I think this is different than your current approach

bb http-client has (request {:method :get :uri ...})

Oh, cool! 🙂

Missed that

bb http-client builds on the java.net.http client (which is already part of bb), and with the :async option you get back a future. Probably supporting a callback will be sufficient to deal with async stuff, rather than pulling in more dependencies

Or with Project Loom bb, no one cares about call backs anymore 😄 at least that my hope for contajners