Fork me on GitHub
#babashka
<
2021-12-15
>
Michael W00:12:23

Wrote some babashka today to mitigate log4j issues on all our servers. Thanks so much for the awesome tools!

🎉 4
Björn Ebbinghaus15:12:32

clojure.data.priority-map isn't supported by babashka as far as I can see?

borkdude15:12:18

It's not built-in and also it doesn't work from source due to deftype

Björn Ebbinghaus15:12:40

Too bad, that would make my AoC code a lot faster... Now I have to build something similar myself...

borkdude15:12:52

I'll keep it in mind

cldwalker15:12:53

@U4VT24ZM3 Hi. There’s https://github.com/babashka/sci/issues/345 if you come across other deftype issues. I added another lib to this today

Björn Ebbinghaus15:12:58

@U08ALHZ2N Hm... I appreciate your effort, but it doesn't seem sustainable to me to adapt every library using deftype to Sci. 1. If SCI wants to be a universal Clojure interpreter, it has to support every Clojure Library that will ever be written. Otherwise, you would fragment the Clojure ecosystem into sci-compatible and non-sci-compatible. 2. If SCI doesn't want to be universal, it shouldn't grow any more than the absolute necessary libraries, otherwise we would sometime land at point 1.

cldwalker15:12:20

I’m not looking to workaround these issues but rather compile a list of libraries that are blocked on deftype support. If the list is useful enough to people than perhaps the community will rally to tackle support

borkdude15:12:15

It's not only a matter of wanting, but also of constraints. deftype is often used for implementing Java interfaces. In GraalVM native you cannot define new types at runtime, there is no JVM bytecode stuff anymore. The choice you still have here is: compile the library natively and provide the functions with the SCI config (like many libraries in babashka). Or make a babashka pod around the library.

borkdude15:12:25

I do want to support this, I just don't know how.

borkdude15:12:48

deftype + only protocols could probably work but this isn't typically how deftype is used

borkdude15:12:12

We were almost there at one point, but this introduced a weird typing issue. What we did was that deftype would create a type that implemented a list of all available interfaces and then mapped to the user's implementation. But this had as a side effect that (instance? CustomType x) would always return true, even if the user didn't provide an implementation

borkdude15:12:59

I'm also not sure if I understand point 2. What does it mean that "it shouldn't grow any more than the absolute necessary libraries"?

borkdude15:12:14

I think it's better to support something than nothing.

borkdude15:12:04

If you want data priority map in your graalvm binary, this can work with SCI, no problem, just not from source currently. It's a matter of choices: we can't include just any library in bb without becoming the entire clojars in one binary. But feel free to post issues so other users can provide feedback and eventually, who knows.

cldwalker15:12:35

> We were almost there at one point, but this introduced a weird typing issue. What we did was that deftype would create a type that implemented a list of all available interfaces and then mapped to the user’s implementation. But this had as a side effect that `(instance? CustomType x)` would always return true, even if the user didn’t provide an implementation Exciting! I didn’t know you had spiked on this. I’m hoping with enough hammock time a path forward emerges 🙏

borkdude15:12:13

Believe me, if I would know a good solution today, it would already be in there :)

borkdude15:12:52

You can read some of this stuff around issue 540 and surrounding commits

borkdude15:12:01

That was about reify but the problem is very similar

borkdude15:12:07

The issue is that you have to generate a real type at compile time that is the exact match of a mix of Java interfaces that the user will provide at runtime

borkdude15:12:36

Currently we only allow one Java interface in reify and pre-generate those types and link them to the run time implementation

borkdude15:12:48

but for deftype, there's often a Java interface or ... 5

Björn Ebbinghaus16:12:58

Ok. I have to explain. First: My initial question was flawed by my misunderstanding. I thought, that in the absence of a bb.edn, babashka would pull the deps from the deps.edn. So I thought "Well BB doesn't support priority-map", not checking if I did something wrong myself. Which may have led to me misunderstanding the whole situation. I am not sure. Second (it shouldn't grow any more than the absolute necessary libraries) Well, it's a dark vision of the future. 🙂 Imagine SCI gets so wide-spread, that it is head-to-head with JVM Clojure ... Then we would have a fragmented Clojure ecosystem of sci-compatible and non-sci-compatible libraries, unless every library that will ever be written is SCI compatible. Wouldn't it? But as I said, I think I may have misunderstood something and the statement was me not knowing what I was talking about...

borkdude16:12:31

babashka only gets deps from bb.edn

borkdude16:12:46

some libraries use reader conditionals to make it work for JVM and bb

borkdude16:12:02

you can look at it this way: babashka, like CLJS, is a dialect of Clojure which tries to be close, but within the limits of its host.

borkdude16:12:22

and sometimes libraries have to introduce host-specific things to deal with that

borkdude16:12:31

the bb host being graalvm native

borkdude16:12:36

I think the deftype thing could work, if we went with the "be all types" thing, but then this could still give runtime errors:

(if (instance? ILookup my-deftype-thing) (get my-def-type-thing :a) ...)
It could blow up with: yeah, actually the user didn't provide an implementation for this...

cldwalker16:12:43

Could we modify sci’s instance? check to fail checks to my-deftype-thing? Perhaps the amount of calls like that in the wild are near zero. Failing would make it explicit that it’s not supported

borkdude17:12:16

yes, we could, but this would not work when this type was passed to a precompiled function which uses instance

👍 1
borkdude11:03:16

@U4VT24ZM3 I'm adding clojure.data.priority-map as a built-in in the next release of babashka (already available via https://github.com/babashka/babashka-dev-builds)

Björn Ebbinghaus12:03:07

👍 Nice! But no hurry, Advent of Code 2022 is still months away! 😉

borkdude12:03:54

The current version of bb should already be significantly faster than compared to Dec 21

borkdude15:12:05

Thanks to @cap10morgan and @rahul080327: 0.7.1-SNAPSHOT docker image available for arm64!

🎉 2
javi19:12:17

just got a new M1 macbook air and after installing babashka via homebrew i get “bad CPU type in executable : bb” any advice on how to sort this?

borkdude19:12:41

@fj.abanses you should use rosetta2 to run babashka on macOS. /cc @cap10morgan

javi19:12:39

thanks!