Fork me on GitHub
Sam Ritchie13:12:52

Announcing v0.2.0 of clerk-utils , a library designed to help write interactive docs like with #clerk. This release adds a show-cljs macro that makes it easy to use clerk with cljc files, as well as a docs page documenting how to use Clerk with a custom ClojureScript bundle: See the interactive docs notebook for more detail: • Release notes: • Clojars: • Github: • cljdoc:

🚀 15
🎉 4

Dewey Search: A "not completely terrible" web page for finding clojure libraries that are hosted on github. Edit: • Added page • Topics and authors are now clickable to show filtered view source:

🆒 11
clj-kondo 5
🎉 6

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!

org.babashka/http-client {:mvn/version "0.0.1"}

🎉 25
babashka 6
🚀 6
Ivar Refsdal14:01:44

Great stuff as always! However at my work we've had a problems when using with respect to network timeouts. For example request timeout does not cover receival of the body: Not sure if this can be solved perfectly at a higher level such as babashka/http-client or not (or just mitigated).

Ivar Refsdal14:01:25

I have not looked super close at it, but my personal preference as of now is to just stay away from :-/


@UGJE0MM0W The workaround that occurred to me also is mentioned here: > A possibility for the caller is to make use of the CompletableFuture API (get/join will accept a timeout, or CF::orTimeout can be called). IIRC - in that case, it will still be the responsibility of the caller to cancel the request. babashka http-client isn't going to fix JDK issues, unless the workaround is super obvious


babashka.curl and httpkit will still be available options in bb though



user=> (let [resp (http/get "" {:async true})] (deref resp 1000 ::too-late))


user=> (let [resp (http/get "" {:async true})] (deref resp 1200 ::too-late))
{:status 200,

👍 2
Ivar Refsdal14:01:51

That's an OK-ish workaround I think. One problem we also had is that it takes a long time before a HTTP/2 connection is marked bad/dead. Requests kept piling onto the same dead connection, so a bunch of requests (eventually) timed out, thus we had a flood of timeouts. HTTP/2 is the default as far as I know. Using HTTP/1.1 would be better in this case.


@UGJE0MM0W I don't think so:

user=> (:version (let [resp (http/get "" {:async true})] (deref resp 1000 (delay (do (future-cancel resp) ::too-late)))))

Ivar Refsdal14:01:01

I think so:

Returns the preferred HTTP protocol version for this client. The default value is HttpClient.Version.HTTP_2


I wonder why I'm getting :http1.1 - I'll dig deeper


perhaps because the other side doesn't support http2?


anyway, you can set it using :version :http1.1

Ivar Refsdal14:01:30

other site: I guess so. I see that you are doing some http-version stuff as well


I updated the docs to set the version

Ivar Refsdal14:01:39

Anyway... My experience on an unstable network (Azure container instances) + http2 (default) is unfortunately not very good with I'd be hard pressed to recommend it in such a setting. I also cannot recommend Azure container instances per se. The problem lies with the JDK of course, not babashka/http-client. I have no idea if babashka.curl/httpkit is better. clj-http is http1.1 default + timeouts that are respected AFAIK, which is what I've stuck with.


If that works for you, keep using it :)


Announcing Fulcro Internationalization, version 1.0 This library supplies features for easily internationalizing Fulcro applications: • Use your native language in the code strings • Extract those to GNU gettext POT files • Use PoEdit or other great tools to generate translations in supported languages • Dynamically load the translations per locale from your server

🎉 18
🔣 3
fulcro 2