This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (6)
- # beginners (117)
- # calva (22)
- # cider (7)
- # clara (56)
- # clj-kondo (8)
- # cljdoc (3)
- # cljfx (26)
- # clojure (58)
- # clojure-czech (2)
- # clojure-europe (20)
- # clojure-greece (1)
- # clojure-india (7)
- # clojure-nl (11)
- # clojure-uk (100)
- # clojurescript (48)
- # conjure (24)
- # cursive (117)
- # data-science (3)
- # datascript (5)
- # datomic (33)
- # emacs (29)
- # figwheel-main (3)
- # fulcro (12)
- # jobs (1)
- # malli (40)
- # parinfer (4)
- # pathom (1)
- # quil (2)
- # re-frame (17)
- # reagent (20)
- # reitit (1)
- # reveal (97)
- # ring (5)
- # shadow-cljs (11)
- # spacemacs (12)
- # sql (4)
- # tools-deps (18)
- # xtdb (25)
Hi all, somebody pointed me to Malli (thx @borkdude @hobosarefriends) because of the situation with spec being alpha and spec2 on the horizon. But then I noticed in the Malli readme that it says: “Pre-alpha”, which scares me a bit. Can somebody clarify the situation and whether or not this is a good time to start using Malli? Our situation by the way is that we have a big existing codebase without any sort of spec/schema, so in that respect we’re starting from scratch.
All the solutions are officially still alpha. Trying any of them is a good learning experience. If you don’t have specific requirements, I would suggest to start with clojure.spec (1) as it has the most examples and documentation. I think Malli is modelled like spec(2) so any learnings with clojure.spec will be applicable later in malli
Although @ikitommi mentioned that the goal of the current Clojurists Together funding is to make a stable (non-alpha) release?
Good point 🙂
There's some discussion on github that might be interesting: https://github.com/metosin/malli/issues/207
@ikitommi A small heads up I have generated a Malli spec that can validate all of our cfn templates (around 30, pretty big and complete). I’ll try to publish it soon and point to some pitfalls. One thing that is hard to debug are (deeply nested) recursive schemas. Without the use of
[:ref …] it will give a stackoverflow error without a good pointer. And I had to do a trick in the
:multi dispatch to prevent
:invalid-type errors and to stay compatible with spell-check. All in all it works pretty well! Thanks
@ikitommi Here is the current state of my AWS cloudformation malli code https://github.com/jeroenvandijk/aws.cloudformation.malli/blob/master/src/adgoji/aws/cloudformation/malli/validation.clj#L15-L232
Maybe useful information; I’ve reduced the usage of
:or and used
:multi instead to prevent super long lists of errors (reduces branching factor)
I think I broke proper spell check feedback by not using a keyword as dispatch function. I’ll look into this soon again
@stefan.van.den.oord Just checked that last bullet on “last things before initial stable release” yesterday. will clean up corners and will ship the alpha, most likely next week.
the public api has been mostly stable since june, there has been small changes in the advanced user / extender api, and most likely will be after the first release.
@ikitommi (Note my remarks on borkdude/dynaload. I'm currently solving a problem with GraalVM. Using resolve at runtime bloats the binary with +20MB. But it does work.)
@borkdude sorry, read you message, but didn’t have time to answer. There is no GraalVM tests atm, should be.
I will publish dynaload 0.2.0 or so that will have breaking changes to fix this problem, but I'll notify you
when writing libraries, the goals matter a lot. few years ago, didn’t know much about perf. can’t add that later. now, the cljs bundle size, learned how to handle that. Next: GraalVM as a target.
yeah. I have a
dynaload-graal-friendly branch, with
currently this code still bloats:
so it's either in find-ns or in the namespace interop
#?(:clj (defn resolve* [sym] ;; TODO: this adds + 20MB to the GraalVM binary #_(let [ns (symbol (namespace sym)) v (symbol (name sym))] (when-let [ns (find-ns ns)] (.getMapping ^clojure.lang.Namespace ns v)))))
I think using this interop will make GraalVM think it should hold on to more that it actually needs
so what we can do is only resolve at compile time. The user should take care of requiring the lib namespace before they load the dynaloaded code, else it will be considered not there.
have this on my project Justfile:
# start backend nrepl @backend: clj -A:dev:test:common:backend -e "(require '[hashp.core])" -m nrepl.cmdline -i -C
just take care in your main to require those libs first, then it will be solved. we can make this behavior graalvm only for example by reading an environment variable or java property
so: 1. cljs: preload or direct require 2. jvm: just in a classpath 3. graalvm: direct require , right?
can one differentiate if the lib is required or just in the classpath in 2? could be an option in dynaload?
@ikitommi 1) I think in CLJS the order of require doesn't matter, because the check happens at runtime at the first deref. 2) this works because CLJ has runtime require 3) Like 1, but now the order matters, since we check at compile time, before the deref. About checking the classpath: not sure how this would look. That's kind of the same as compile time resolve.
Checking whether you are in a GraalVM binary already works, but that's too late. You have to check at (Clojure) compile time.
So based on setting
-J-Dborkdude.dynaload.target=graalvm-native we could alter the behavior or 2 to 3
@ikitommi Pushed dynaload 0.2.1 with better support for GraalVM binaries: https://github.com/borkdude/dynaload#graalvm