$ cat /tmp/foo.clj





(defn foo []
  (+ 1 2 :foo))

(foo)

$ bb -f /tmp/foo.clj
java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to java.lang.Number [at /tmp/foo.clj, line 7, column 3]
     3:
     4:
     5:
     6: (defn foo []
     7:   (+ 1 2 :foo))
          ^--- clojure.lang.Keyword cannot be cast to java.lang.Number [at /tmp/foo.clj, line 7, column 3]
     8:
     9: (foo)
Stacktrace:
   clojure.core/+ - <built-in>
   user/foo - /tmp/foo.clj:7:3
   user/foo - /tmp/foo.clj:6:1
   user - /tmp/foo.clj:9:1

Some things to consider: - Should we only show the context with the error message and not the first line which contains the same error message? - Should we show the stacktrace by default or write it to a temp .edn file like clojure does?

The formatting is helpful and reminds me of what I saw from shadow-cljs warnings when testing rewrite-cljc against shadow-cljs.

I’ll try to dig up a sample if you are not already familiar.

Not familiar, so example welcome

Did not quickly find one on web, so turned on deprecation warnings for rewrite-cljc here’s a sample:

Thanks for sharing

So shadow does use coloring to make some things stand out. We can do that I guess.

Not sure if all terminals support this and if we should detect this, etc.

Ya, the coloring is interesting. Also inspired by shadow-cljs, might consider not repeating filename and line number in contextual message?

7:   (+ 1 2 :foo))
          ^--- clojure.lang.Keyword cannot be cast to java.lang.Number [at /tmp/foo.clj, line 7, column 3]

7:   (+ 1 2 :foo))
          ^--- clojure.lang.Keyword cannot be cast to java.lang.Number

yes

I’ll try triggering a stack trace under shadow-cljs and see if it can offer inspiration there as well…

Hmm… not sure… I’m only using shadow-cljs to to run unit tests… maybe somebody more familiar with shadow-cljs can give a stack trace example.

But… now I’m also now reminded of figwheel-main. I think it does formatting of errors?

Yes, that was the initial inspiration, jeroenvandijk did the initial implementation based on that

Yeah good example first thing in README https://github.com/bhauman/figwheel-main/blob/master/README.md

Ah cool

As to your question: > - Should we only show the context with the error message and not the first line which contains the same error message?

I think the first line is just saying pretty much the same thing as the contextual message and does not add value.

ok

And as to: > - Should we show the stacktrace by default or write it to a temp .edn file like clojure does?

I’m not sure. If the stack trace is huge and scrolls the summary off the screen, that would make the details hide the summary. But you had the idea of maybe only showing the first 5 and last 5 items, so maybe that would solve that? But what if you really need the full trace? I was initially annoyed by the change in clojure to write the stack trace to an edn file, but then got over it quickly when I realized they also added the --report option.

If you need the full trace you can do --verbose

Right… I see, tx.

So I guess the question is, is the contextual message typically enough info, and the stack trace typically noise?

We can also make each stack element contextual

But maybe that's a bit too much

I think it's useful to know where things started and ended. The part in the middle is usually not that interesting

That’s my experience as well.

Am I right in thinking-out-loud that: for clojure one goal is to make it easy for tooling to take advantage of and use data it spits out to provide a good experience for the user. This would also be true for babashka as well, but babashka being a scripting tool, is used stand-alone and should provide some of the niceties that clojure does not want to concern itself with. Hence your contextual message.

One thing I'd like to do different with babashka is spit out file locations that you can click on (either in terminal or emacs) so it will point you to the right file.

I've personally never used error information as data from clojure shell invocations

The current stack trace has this

I guess we can have both: spit out data and show useful information. We can do the data bit later if people want it, but I don't expect it.

Example: https://twitter.com/borkdude/status/1294701203008389120

Clickable paths is a thoughtful feature.

As I ramble away, I’m thinking what I would like would be terse by default (I think the context message would be all I need usually), with an option to be less terse (maybe adds your 5/5 stack trace with context for each item), and then an option to be fully verbose (full stack trace with context for every item). I wonder what other folks think? (hint hint others! ). And maybe I would not really need the middle option. Terse or fully verbose might do.

With stack traces I most often use the first few lines up to the first project specific frame that isn’t some sort of helper function.

Does babashka support multi-threading (in one script)?

On the JVM, jdbc requires a native dependency (`sqljdbc_auth.dll`) to connect to SQL Server via "Integrated Authentication". Does that sound like something can work with Babashka?

@isak Loading native libraries works, also in GraalVM, but that needs to be built into babashka or a babashka pod. We have babashka pods for several database flavors: https://github.com/babashka/babashka-sql-pods. As of now there is no SQL Server pod.

So contributing a pod or feature flag to babashka yourself would probably be the only way right now.

Ok, sounds good

Here are some examples of feature flags: https://github.com/borkdude/babashka/blob/master/doc/build.md#feature-flags Here is more information about pods: https://github.com/babashka/babashka.pods

Is there anything like https://github.com/vadimdemedes/ink for building babashka based cli apps?

Not that I know of

the only thing that i've come across so far for the jvm is https://picocli.info/

@grahamcarlyle That doesn't do react-like rendering as far as I know? There is also react-blessed for node. I've gotten it to work with Reagent once.

i wasn't so much interested in ink for its react like api, though thats nice, i was interested in any libs that would support developing simple cli apps in babashka

Do you mean command line parsing?

Babashka comes with clojure.tools.cli as a library. There is also https://github.com/nubank/docopt.clj#babashka.

There's also work on cli-matic to make it compatible: https://github.com/l3nz/cli-matic/issues/113

More for coloured text rendering, and simple layout, basic input, progress bars etc.

@grahamcarlyle

$ export BABASHKA_CLASSPATH=$(clojure -Spath -Sdeps '{:deps {io.aviso/pretty {:mvn/version "RELEASE"}}}')
$ bb -e "(require '[io.aviso.ansi :as ansi]) (println (str \"The following text will be \" ansi/bold-red-font \"bold and red\" ansi/reset-font \".\"))"

Might be worth documenting at https://github.com/borkdude/babashka/blob/master/doc/libraries.md

Made an issue for that: https://github.com/borkdude/babashka/issues/547

@grahamcarlyle This ansi code is also pretty useful, for clearing the screen: https://twitter.com/borkdude/status/1278357459363602432

Here's an overview that should be usable to build some of this stuff maybe: http://ascii-table.com/ansi-escape-sequences-vt-100.php