Clojurians Log v2

@borkdude Thank you so much!

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?

@henryw374 all classes are manually mapped into the interpreter. See babashka.impl.classes

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

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.

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]

but as borkdude says to be imported the class must be manually mapped

Yes. PRs with explanation of why the class is needed welcome.

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

Sounds useful. I'll put a note in the tick ticket about it

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

Or maybe it’s peanuts and not important, just something I noticed

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"}}}'

Thanks for all the hard work you've put into babashka @borkdude!

https://github.com/djblue/portal#api-usage

Wow, what kind of magic is this!

The kind that clojure and it's awesome community makes possible! 😄

Even the viewer works in babashka :)

I had to roll my own http server implementation but https://gist.github.com/borkdude/dca50a3d5a48ac6ab2ef6aa58a4e9f6b made it super easy to do

:)

I'm impressed!

Added it to the changelogs

Sweet, thanks!

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

True. Sci saves location information on them

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

I think you can just strip :line and :column, etc then.

user=> (meta 'x)
{:line 1, :column 7, :end-line 1, :end-column 9}

Of course it's better to not have to work around it

Example of new error reporting in 0.2.0. You can even see the &env and &form locals on error during macro-expansion now: