Fork me on GitHub
#babashka
<
2023-11-13
>
grzm00:11:27

https://github.com/grzm/awyeah-api com.grzm/awyeah-api {:git/tag "v0.8.79", :git/sha "0399fec"} is available • Catch up to aws-api 0.8.686 (2023-07-11) • Also include aws-api refactoring commits up to 5900e35 (2023-07-12)

🎉 1
grzm02:11:20

@borkdude @seancorfield I've opened https://github.com/grzm/awyeah-api/issues/11 to track support for aws-api auto-refreshing creds in awyeah-api (https://clojurians.slack.com/archives/C09N0H1RB/p1669251196815769) . Looks like the only class we're currently missing in babashka is java.util.concurrent.ScheduledFuture. Is this something you'd be amenable to adding, @borkdude? (I haven't yet taken a look yet at what kind of size impact it would have on the binary.)

1
lispyclouds06:11:14

On a side note, it looks like its used only to https://github.com/cognitect-labs/aws-api/blob/7352ec647ff19f6a14cbbfc5e581c48a8183ebf1/src/cognitect/aws/credentials.clj#L103 the cancel call? Since it inherits from j.u.c.Future with the cancel method and it’s supported in bb, we can type hint with that? (.cancel ^Future r true)

grzm07:11:30

Yeah, that looks like it'll work. Thanks, @U7ERLH6JX!

1
borkdude07:11:42

Ok please test and let me know. Happy to look into the class adding if necessary

borkdude09:11:06

I don't notice any binary size increase, so I'm just going to add this

🚀 1
borkdude09:11:37

done. The new test version can be installed / tested with:

bash <(curl ) --dev-build --dir /tmp
(once the current master CI build finishes)

grzm06:11:28

I thought Runnable was available in babashka (based on my naïve reading of https://github.com/babashka/babashka/commit/ea4f56886d6728a51505e8c23da2ad49174f64d9) but I got errors when using ^Runnable as a hint. Works fine in babashaka without the hint though, so a little cljc and Robert's your mother's brother.

borkdude07:11:55

Try it fully qualified

borkdude08:11:18

java.lang.Runnable works, I'll fix the unqualified usage

👍 1
Paul Hempel16:11:58

Hi everyone. I wanted to run the HTMX todoapp example and all I get is the file-server response. I suppose this shouldn’t be the case (or I don’t understand something^^). Maybe someone has an idea :thinking_face: https://github.com/babashka/babashka/blob/aa654a9eaddd8ad15df12c5c7338f7a775346cbf/examples/htmx_todoapp.clj#L9

1
borkdude16:11:11

This is what I'm seeing when I run:

bb htmx_todo_app.clj

Paul Hempel16:11:55

You know what I realized: I still run on v1.1 I’m pretty sure something will change after brew has finished upgrading 😅

borkdude16:11:04

probably :)

borkdude16:11:16

also check the browser console maybe

borkdude16:11:47

I've tried with chrome

Paul Hempel16:11:42

Chrome did the trick. Maybe some content-blocker is infering with my default FF

borkdude16:11:29

could be, perhaps the right content-type would fix it as well

Paul Hempel16:11:57

(defn render [handler & [status]]
  {:status (or status 200)
   :headers {"Content-Type" "text/html"}
   :body (h/html handler)})
That’s something I already added to be sure.

borkdude16:11:15

I also tested with ff, works right here on mac

borkdude16:11:41

could also try adding these headers:

"Cross-Origin-Opener-Policy" "same-origin"

borkdude16:11:46

else, no idea

borkdude16:11:21

no, those headers probably don't make sense

borkdude16:11:32

but could be a cross origin scripting thing

Paul Hempel16:11:50

Your repo was what I started with. But I suppose I have to do some Firefox deepdiving as Chromium works fine. Anyways thanks for helping with debugging - the rest is ‘it doesn’t run on my machine’ ^^ 🙌

Paul Hempel16:11:46

Okay, I did it. It was my VS Code ‘live preview’ plugin which was somehow injecting its own code (without being active) and FF did not like that. Little weird things…