Clojurians Log v2

Hi all, is there a way to get babshka to automatically handle logging of data from an ExceptionInfo exception or do I need to catch and log them myself? Some code:

(def some-map {:a 1 :b 2 :c 3})




(throw (ex-info "ABC" some-map))

----- Error --------------------------------------------------------------------
Type:     clojure.lang.ExceptionInfo
Message:  ABC
Location: /home/dstephens/git/ccm/ui/i18n/./translate.clj:249:1

----- Context ------------------------------------------------------------------
245: 
246: 
247: 
248: 
249: (throw (ex-info "ABC" some-map))
     ^--- ABC

hmm, I think the error output could be made nicer showing the contents of the ex-data

feel free to post an issue (and optionally a PR)

I'm thinking something like this:

Type:     clojure.lang.ExceptionInfo
Message:  ABC
Data: ....

okay cool, I've been meaning to understanding how babashka actually works for a while so I'll have a look. Yeah, that's sort of what I was expecting to see

We could also support:

(Thread/setDefaultUncaughtExceptionHandler
 (reify Thread$UncaughtExceptionHandler
   (uncaughtException [_ thread ex]
     (log/error ex "Uncaught exception on" (.getName thread)))))

feel free to post another issue about that too

maybe a nicer API like (set-default-uncaught-exception-handler! ...) in babashka.utils or whatever could also work

Let's first add the ex-data to the error output

I raised https://github.com/babashka/babashka/issues/730 for the ex-data, hope I've captured enough.

thanks!

FYI, datascript seems to work with Graalvm now https://github.com/BrunoBonacci/graalvm-clojure/pull/34/

yeah, babashka already has a datascript feature flag :)

ah ok cool. Missed that 😅

Thanks

• I was misled by this comment Datascript does not compile at all when using clojure 1.10.

In the other graalvm-clojure repo

are there any recent improvements for this btw? last time I tried it, it really took a long time and the binary was huge

du -h target/datascript
 28M	target/datascript

maybe it is because of the reflect-config trick. Could be made smaller i guess

ok, maybe try again then by updating the feature flag. @jeroenvandijk have you seen this btw? https://yyhh.org/blog/2021/02/writing-c-code-in-javaclojure-graalvm-specific-programming/ a durable datascript, we can make a pod out of this

ah no i haven’t. Will check it out

Thanks

Really cool that it’s posssible. Will stay away from C myself for now 😅

yes. soon we will have a sqlite-ish pod but then based on datalog, how cool :)

the author is now working in a CLI version first. maybe, if he's open to it, I can add pod support to that

Super nice 🙂

for babashka.fs , is there some criteria for what to implement, and what not to implement, from the inspiration libs?

@duncan540 dunno - what do you have in mind?

Something like expanding ~ in path strings to the home directory, I guess is a shell thing and not a Java thing. Handy though

yeah, I think such things could be handy, but I've never personally needed it. can you give an example when one would need this in a clojure program?

by not having this, people will maybe write more cross-OS friendly code, like (fs/path (System/getProperty "user.home"))

If I write some script for a personal automation task, I don't want to hardcode my username in the script

$ bb -e '(System/getProperty "user.home")'
"/Users/borkdude"

yep that works. I guess it's just a question of how much of a "light touch" writing Bash-style scripts in bb aims to have

I think adding a home function that does the above is still good

since not all people might know how this works in Clojure / JVM

I remember we talked about a "light" way too have the equivalent of Bash set -e mode, and you came up with this nice macro:

(defmacro $$
  [& args]
  `(let [proc ^{:inherit true :dir fs/*cwd*} (child/$ ~@args)]
     (child/check proc)
     nil))

(brb)

The clj-commons/fs library has (fs/expand-home "~/path/to/something"). That's like Python's os.path.expanduser("~/path/to/something") and obviously it just happens natively in Bash

and this should also work on Windows while "~" isn't a thing there? why not just (fs/path (fs/home) "foo" "bar")? This is even more preferable than writing hard-coded file separators

maybe a function that will parse a unix shell path to a normal fs path could be nice though. So ~/path/to/something will even work on Windows

(I'm thinking out loud as you can tell)

yep that true, writing paths as a single string is just a hard habit to break after writing a ton of Bash over the years

This is number one: https://github.com/babashka/fs/issues/12 The other one needs more hammock time maybe. Is ~ the only thing to expand? Are there other things that need expansion? Env vars?

The deluxe version of ~ that I have a hunch hardly anyone knows exists is that you can put another user's name after the tilde. So ~alice/path/to/something. Env vars would certainly be useful for writing Bash style scripts. I haven't personally noticed the lack of them though. ~ is equivalent to ${HOME} I guess.

I'll just make an issue about this and then we'll think about it some more. People can react there so we can see if more people want this. My hunch currently is that this is fairly easy to do using a custom defined function

Cool - thank you for considering it!

https://github.com/babashka/fs/issues/13

Hey 👋:skin-tone-2: I'm looking to run cljfmt in babashka; which needs rewrite-clj. Replacing it with rewrite-cljc didn't work because it relies on clojure.lang.IMeta . Has anyone walked this path before 😬 ?

I don't think that path will work, since you will also have to run all of tools.reader, etc inside babashka. Even if this would work, I don't think it would perform as good as in clojure itself, which kind of misses the purpose of using babashka for good startup time.

Having said that, there is a cljfmt binary I think? There is also a zprint binary and the zprint binary uses sci (the same interpreter that bb uses) for configuring certain things using functions.

But if there is a good use case to add clojure.lang.IMeta, you can convince me to add it

Thanks for the pointers. I am looking to integrate a couple of formatters in a single point of entry. But since the process will take several seconds; I might not win much by using babashka here over a lean clj project :thinking_face:

Exactly. If the program already takes a few seconds in an already started JVM (with all the namespaces already loaded), it's probably better to just run it on the JVM

And if you want to optimize startup time for all of these formatters, you can compile this into a GraalVM binary later on

This makes sense :thumbsup::skin-tone-2: Haven't played with Graal on a first hand but this seems like a good moment 🙂

https://github.com/lread/clj-graal-docs is a good place to start, also the #graalvm channel

zprint is an impressive program. it's quite amazing how systematic the configuration can be

Thanks, appreciate the help