This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-14
Channels
- # announcements (2)
- # aws (1)
- # babashka (18)
- # babashka-sci-dev (103)
- # beginners (165)
- # calva (51)
- # cider (8)
- # circleci (1)
- # clj-kondo (22)
- # clj-on-windows (2)
- # cljdoc (1)
- # cljfx (31)
- # cljs-dev (16)
- # clojure (81)
- # clojure-europe (71)
- # clojure-nl (7)
- # clojure-uk (11)
- # clojurescript (20)
- # code-reviews (26)
- # conjure (1)
- # contributions-welcome (1)
- # core-async (15)
- # cursive (8)
- # datomic (8)
- # defnpodcast (2)
- # eastwood (24)
- # emacs (10)
- # events (1)
- # fulcro (4)
- # funcool (31)
- # graalvm (43)
- # graphql (8)
- # honeysql (9)
- # introduce-yourself (1)
- # jobs (12)
- # kaocha (3)
- # lsp (28)
- # malli (4)
- # meander (4)
- # membrane (7)
- # off-topic (64)
- # other-languages (3)
- # pedestal (1)
- # polylith (31)
- # portal (5)
- # re-frame (4)
- # reitit (1)
- # releases (5)
- # rum (2)
- # schema (2)
- # sci (34)
- # shadow-cljs (21)
- # vscode (1)
@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 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.
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
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
;; 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"
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 😛
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
it worked like this in unixsocket-http too, but xsc added the chnage anyways
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)
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]]
?
yeah i want it to also accept a coll as the v in the query params map
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.
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
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
in circleci's cache
@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
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
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
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
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
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
yep, got it. thanks!
trying it now
hmm, same error
maybe it just needs a higher mem limit
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
ok original binary works too
want me to revert that last change?
after that we can merge and then do some updating, etc. I'll roll out the new version tomorrow
it's pushed