Clojurians Log v2

@borkdude we dont have a formal ability to send multiple values to the same key in the query params in bb.curl right? we currently pass a map to :query-params. I need this in https://github.com/lispyclouds/contajners/issues/8 . We can send a vector of vectors and that could work as a hack but if you think its a useful thing to add i can add the same functionality as https://github.com/into-docker/unixsocket-http/issues/17

@rahul080327 Is the proposal to add a vector as a value for repeated args?

yes

The [[k v] [k v]] approach already works too right?

yes it would but feels a bit hacky maybe? i was thinking we can keep it like clj-http does?

If I were you I would maybe have replied that this is a sufficient way to do it. It's not accidental at all, the implementation treats the associative as a seq of key-vals.

Also the [[k v] [k v]] approach allows you to specify the order of params

if that is important for whatever reason

right, the thing was it would need some translation in the contajners layer and its a bit of a mismatch when people read the docker/podman docs and try to send a list like its documented and it fails

ah I see

is the issue that contaijners uses bb curl?

yeah thats how i make it run on bb

i can just do the translation in contajners too

I think it's sufficient to document the [[k v]] approach and translate it in contaijners

cool will go ahead with that

the clj-http also has :multi-param-style which you didn't introduce but just went ahead and treated vectors always as if you would specify multiple keys

?

oh sorry I misread the clj-http docs

;; default style, with :multi-param-style unset
:a [1 2 3] => "a=1&a=2&a=3"
;; with :multi-param-style :array, a repeating param with array suffix
;; (PHP-style):
:a [1 2 3] => "a[]=1&a[]=2&a[]=3"

ah well, if this is important, we can support this too I guess :)

but [[k v]] should remain working

I think you would have to do the translation to support older bb's anyway

yeah i would do it in a similar way as https://github.com/into-docker/unixsocket-http/pull/18/files

wouldnt really need a translation in contajners if we implement this in bb.curl. its broken currently if you pass a list 😛

:-)

what happens then? glancing at the code, it looks like it should work

well then contajners code is fine, its just that the vec that you pass is converted to a str and docker/podman isnt very happy at that

what it wants is ?containers=id1&containers=id2 and what it sees now is containers=[id1, id2]

sure but if you pass [["containers" "id1"] ["containers" "id2"]] to bb curl it should work right

yep it would. with the translation in contajners. wanted your opinion if its something we'd wanna add in bb.curl too, to keep it like clj-http

I already replied above. you will have to do the translation anyway for older bb's

it worked like this in unixsocket-http too, but xsc added the chnage anyways

but adding that seems fine. you don't think it's a breaking behavior?

i was thinking i would just check if v is a coll? in https://github.com/babashka/babashka.curl/blob/master/src/babashka/curl.clj#L102 and do the recur differently?

instead of just (str v)

please answer my question ;)

would not be breaking right? {:a 42} and {:a [42 43]} should both work if passed to :query-params as well as [[:a 42] [:a 43]]?

you're changing the behavior or {:a [42 43]} then right?

yeah i want it to also accept a coll as the v in the query params map

I don't think coll? is the right predicate. it should be sequential? imo

a map is also a coll?

right, brb in a bit!

So to summarize: 1. You would have to do the translation in contaijners anyway, since older bb's don't have this new query-params feature 2. Adding it to bb.curl seems fine, but I'm a bit concerned about breaking changes: the behavior of {:a [1 2 3]} is changed, instead of a=[1 2 3] we get a=1&a=2&a=3. Not sure if this is even worth the change. My inclination is to keep the old behavior and just document how to get multiple keys with the same name, but I could be convinced otherwise with strong arguments :)

yeah my only argument is that this makes it explicit that this key in the query params has multiple values and since bb.curl was inspired by clj-http, we can follow its behavior 😄 but i see the point of the change of behaviour and i can just add it as a translation to contajners

> i can just add it as a translation to contajners not only can, you should because of older versions of bb, a point which I've been trying to make several times now ;)

imo [["a" "1"] ["a" "2"]] is pretty explicit and resembles the query string even more than {:a [1 2]} but perhaps if you have a lot of those, it becomes annoying.

adding too much magic always is going to shoot you in the foot in the long run

yes, i was missing the point of bb being a runtime and not another lib 😅

> but perhaps if you have a lot of those, it becomes annoying its all gonna be generated in my case so not an issue 😄

heres the doc PR: https://github.com/babashka/babashka.curl/pull/42

perfect, thank you

hmm, I think I should add the arch into the graalvm dir. think it's not re-downloading b/c it has the amd64 one cached already.

@cap10morgan hmm.

bin/gu: cannot execute binary file: Exec format error

Exited with code exit status 126

cached, how so?

in circleci's cache

oh yes, I see

you can add the arch name into the cache key perhaps

I think this time it will work

@cap10morgan so perhaps you can smoke-test this on your work env: https://560-325868827-gh.circle-artifacts.com/0/release/pod-babashka-aws-0.1.0-linux-aarch64-static.zip

can do

after that I can release to pod registry. but perhaps we also want to update the cognitect lib, while I'm at it. I'll do that after merge

you probably know that you can load a pod by path too right?

yep, thanks

ok finally got that arm64 pod build packaged up and deployed w/ my app. getting this error from it: /opt/pods/pod-babashka-aws: error while loading shared libraries: cannot make segment writable for relocation: Cannot allocate memory

this is an aws lambda function

wut

does that arm64 environment have glibc?

it's amazon linux 2, so I would think so

what do you get for ldd /opt/pods/pod-babashka-aws and are you 100% sure you have the right binary? :)

pretty sure but I'll double check

I see some info here too: https://linux-tips.com/t/cannot-make-segment-writable-for-relocation-error/481/2

perhaps some security thing?

ldd pod-babashka-aws outputs:

linux-vdso.so.1 (0x0000ffffb6ed9000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffffb093b000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffb091a000)
	libc.so.6 => /lib64/libc.so.6 (0x0000ffffb0794000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffffb6e9b000)

seems like I can run the pod in an amazonlinux:2 docker container locally, so yeah security thing in the lambda env seems likely

perhaps @rahul080327 knows something

are you using a custom docker env for lambda?

don't think so

it's the provided.al2 runtime

perhaps we need to leave out the --static flag altogether and only provide the other one

worth a shot

So here:

if [ "$BABASHKA_STATIC" = "true" ]; then
    args+=("--static")
    if [ "$BABASHKA_MUSL" = "true" ]; then
        args+=("--libc=musl"
               # see 
               "-H:CCompilerOption=-Wl,-z,stack-size=2097152")
    else
        # see 
        args+=("-H:+StaticExecutableWithDynamicLibC")
    fi
fi

move args+=("--static") to the musl part only

ok

if that is the solution, then we need to change it in the bb bash as well

https://563-325868827-gh.circle-artifacts.com/0/release/pod-babashka-aws-0.1.0-linux-aarch64-static.zip

it's there

yep, got it. thanks!

trying it now

hmm, same error

:'(

maybe it just needs a higher mem limit

what's the memory limit now?

128MB

In the blog post I linked earlier they have some kind of patch tool to work around that security thing

I think that fixed it

just needed a higher mem limit

I'll try the original binary again too

ah alright. weird! graalvm images normally don't take a lot of mem

ok original binary works too

want me to revert that last change?

yeah, let's do that

after that we can merge and then do some updating, etc. I'll roll out the new version tomorrow

it's pushed