This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (110)
- # announcements (30)
- # aws (2)
- # babashka (39)
- # babashka-sci-dev (112)
- # beginners (155)
- # calva (5)
- # cider (12)
- # clj-kondo (11)
- # cljs-dev (1)
- # cljsrn (2)
- # clojure (144)
- # clojure-australia (2)
- # clojure-europe (14)
- # clojure-nl (5)
- # clojure-spec (3)
- # clojure-uk (2)
- # clojurescript (22)
- # core-async (23)
- # cursive (31)
- # data-science (3)
- # emacs (12)
- # events (1)
- # fulcro (8)
- # honeysql (7)
- # jobs-discuss (11)
- # lsp (1)
- # missionary (28)
- # nextjournal (7)
- # off-topic (64)
- # pedestal (3)
- # polylith (19)
- # reagent (14)
- # reitit (12)
- # releases (4)
- # shadow-cljs (33)
- # tools-deps (3)
- # xtdb (3)
Wrote some babashka today to mitigate log4j issues on all our servers. Thanks so much for the awesome tools!
Too bad, that would make my AoC code a lot faster... Now I have to build something similar myself...
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.
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
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.
deftype + only protocols could probably work but this isn't typically how deftype is used
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
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"?
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.
> 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 🙏
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
Currently we only allow one Java interface in reify and pre-generate those types and link them to the run time implementation
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...
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.
I think the deftype thing could work, if we went with the "be all types" thing, but then this could still give runtime errors:
It could blow up with: yeah, actually the user didn't provide an implementation for this...
(if (instance? ILookup my-deftype-thing) (get my-def-type-thing :a) ...)
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
yes, we could, but this would not work when this type was passed to a precompiled function which uses instance
The current version of bb should already be significantly faster than compared to Dec 21
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?