Fork me on GitHub
#babashka
<
2022-12-30
>
jjttjj16:12:51

Am I doing something wrong here:

(require '[babashka.deps :as deps])
  (deps/add-deps '{:deps {java-http-clj/java-http-clj {:mvn/version "0.4.3"}}})
  (require '[java-http-clj.core :as http])
Gives the error:
Can't change/establish root binding of #'clojure.core/*warn-on-reflection* with set

borkdude16:12:09

What is your bb version and how are you executing the above code, in a script, repl?

jjttjj16:12:24

babashka v1.0.168 and executing it in a socket repl

borkdude16:12:11

workaround:

(binding [*warn-on-reflection* *warn-on-reflection*]
  (require '[java-http-clj.core :as http]))
please post an issue

jjttjj16:12:25

Awesome and will do, thanks!

borkdude20:12:57

Dear babashka friends! Just finished up writing the babashka http-client today and I think it's ready to be used. Please provide your feedback while this library is in flux so we can move it to a built-in somewhere in 2023! https://github.com/babashka/http-client

👀 4
🍻 8
🎉 7
teodorlu09:12:15

(def resp (client/post "" {:body "From Clojure"}))
(json/parse-string (:body resp)) ;;=> {"args" {}, "data" "", ...}
Is this example right? I expected to see "from Clojure" somewhere in the response body.

teodorlu09:12:39

I like how you handle POST file uploads with io/file or io/input-stream.

teodorlu09:12:19

Is it possible to deref a CompletableFuture? In other words, is it possible to deref the result of an async get request?

borkdude10:12:54

@U3X7174KS I corrected the output, "From Clojure" was indeed missing

👍 1
borkdude10:12:13

I don't think it's possible to directly implement IDeref for CompletableFuture but we could implement a wrapper like we did for process maybe...

1
borkdude10:12:17

oh wait, deref does work! :)

😄 1
borkdude10:12:42

user=> (def fut (client/get "" {:async true}))
#'user/fut
user=> @future 

borkdude10:12:18

since it works on all java.util.concurrent.Future

borkdude10:12:16

updated README

💯 1
teodorlu10:12:36

At first, I expected that clj-http supported deref for getting the result of async requests. I see that's not the case, clj-http has callbacks. https://github.com/dakrone/clj-http#async-http-request

borkdude10:12:25

That Apache future doesn't derive from java.util.concurrent.Future

borkdude10:12:22

To implement chaining you can use something like this: https://github.com/babashka/http-client/blob/aa5b209e678b4d76e19f3d5e265533310a851515/src/babashka/http_client/internal.clj#L176 which I use internally to chain the interceptors onto the future

borkdude10:12:51

oh wait, that apache future also derives from java.util.concurrent.Future so I guess you could use deref there too

jjttjj17:12:04

cool! I haven't thought much of how separate of a concern it should technically be, but would you consider adding websocket functionality to this? Or would that belong in a different library that depends on this? In practice I often use both together and I like that java-http-clj offers it as a packaged deal

borkdude18:12:55

> would you consider adding websocket functionality to this? yes, todo

nice 1
littleli13:01:15

Just a side question, is it virtual thread friendly? I believe they changed underlying code on Java 19+ and it should be vthreads friendly.

borkdude13:01:25

http-client doesn't really do anything vthread specific - what underlying code did they change? CompletableFuture?

littleli13:01:57

I believe they just changed internal implementation, API remains the same - in Java tradition. I recall Ron Pressler mentioned this, cannot really find the reference though.

borkdude13:01:43

Well, http-client doesn't use any hidden / private Java module stuff, so I think it should be ok? ;)

littleli13:01:20

yeah, of course 🙂

littleli13:01:00

It looks great 👏