This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-28
Channels
- # announcements (2)
- # babashka (36)
- # beginners (29)
- # bristol-clojurians (2)
- # calva (3)
- # cider (102)
- # circleci (7)
- # clj-kondo (5)
- # cljs-dev (7)
- # clojure (117)
- # clojure-europe (23)
- # clojure-korea (1)
- # clojure-nl (1)
- # clojure-spec (15)
- # clojure-uk (47)
- # clojurescript (43)
- # code-reviews (1)
- # community-development (1)
- # conjure (32)
- # cursive (1)
- # datalog (15)
- # datomic (14)
- # emacs (18)
- # fulcro (9)
- # helix (23)
- # jackdaw (1)
- # jobs-discuss (10)
- # meander (8)
- # membrane (57)
- # off-topic (4)
- # portal (2)
- # re-frame (22)
- # reagent (1)
- # reitit (9)
- # reveal (3)
- # rewrite-clj (14)
- # shadow-cljs (22)
- # spacemacs (27)
- # sql (34)
- # testing (6)
- # tools-deps (40)
- # vim (5)
- # vrac (15)
- # xtdb (2)
This may be my naivety about Graalvm, but how can bb have included java.time.Duration for example, (which imports DateTimeParseException), but DateTimeParseException itself is not included in such a way that we can import
it?
I think it’s a good question. If I understand your question correctly it is: “how come I cannot catch an exception that should be there based upon the imports of declared classes?” My guess is that the uses of these classes are compiled into the minimum amount of byte code. So the outcome is not the original class anymore i.e. you cannot catch the exception of that class anymore. Anyway, I’m not sure about the details. Also guessing here
yeah I guess it's something like that . FYI`(java.time.Duration/parse "sdf")` prints java.time.format.DateTimeParseException: Text cannot be parsed to a Duration [at line 10, column 1]
@henryw374 all classes are manually mapped into the interpreter. See babashka.impl.classes
ok I see. thanks. I see it is still not all the classes from java.time. would there be any objection to having them all?
not saying I need any more... at some point I will try getting Tick or http://clojure.to work and it's possible there are others they refer to.
I think binary size and compilation time are considerations for adding classes. Indirect overhead is keeping track of the administratoin of what class does what and why to keep it.
Maybe a script that shows what’s missing and/or a PR that adds those helps determining if adding them all is just a small increase
Btw I noticed that cljc.java-time is loading macrovich. Maybe that dep can be skipped for bb since it’s not needed for anything probably. It does work.
But loading that code does take a little bit of the startup that can be optimized maybe
ah interesting. it's a long story about why it was needed originally. It could now be avoided if cljc.java-time creates .clj and .cljs files instead of .cljc ones. I was planning to do that at some point anyway for other reasons
Babashka v0.2.0 is out! 🎉 New features: uberjar, better error messages (context, locals, stack trace), support for clojure.datafy and more! Release notes: https://github.com/borkdude/babashka/blob/master/CHANGELOG.md#v020-2020-08-28

To play with the new clojure.datafy support in the 0.2.0 release, you can use portal:
> bb -cp clj -Spath -Sdeps '{:deps {djblue/portal {:mvn/version "0.4.0"}}}'
I had to roll my own http server implementation but https://gist.github.com/borkdude/dca50a3d5a48ac6ab2ef6aa58a4e9f6b made it super easy to do
I did ran into this bug in babashka https://github.com/djblue/portal/issues/11 caused by transit-clj 😬
It exists on the jvm, but it's much easier to run into in babashka because I think it uses metadata more liberally
You might want to workaround it by just stripping the metadata before transitizing it?
The issue with that is the sometimes the metadata is put there by users implementing protocols