I'm having issues with the new sci release that I've included in my build and I thought it would be useful to show empirically which SCI is being used.

Seems like it would be nice in bb too

it might be present in *clojure-version*

isn't

well not from bb

you can obtain the SCI version using (slurp (io/resource "SCI_VERSION"))

in your host

bb repl gives

user=> (slurp (io/resource "SCI_VERSION"))
(slurp (io/resource "SCI_VERSION"))
java.lang.IllegalArgumentException: Cannot open <nil> as a Reader. [at <repl>:2:1]

in your host

not sure what that means then

not in the SCI program but outside of the SCI program

it's part of the SCI library

I see, so I could make my own *sci-version* is what you are implying?

yes

will do. I think this would be useful when reporting SCI issues...

most of the time I use SCI as a git dependency so it's not as useful in that case

just tag your releases so people can find out what deps.edn you're using in the version they use

well at this point I would be reporting issues with current local builds

ok

makes sense

I've also got an option in bb called: bb describe which prints a map with dependencies used

or rather, what features are used

and bb print-deps prints dependencies used

but SCI isn't in there I think

maybe it should be in there though

since SCI itself is also exposed in bb

anyway, this is something you could do as well

(I'm having an issue with the latest sci, and anticipating you wanting to see I really am using a specific version...)

I will add those to my todo!

it would be useful if you could use deps.edn in this case, even if only for running a development version so you can find out what commit caused the issue for you

what SCI commit

I use both lein and deps.edn in bb

deps.edn for development

me too

ah ok

well I generate a deps.edn using your thinger

oh yeah haha

I'm only using releases for deps (not git deps) at this point.

org.babashka/sci {:git/url " :git/sha "<commit-sha>"}

what kind of issue are you facing? perhaps it rings a bell

I'll mention it elsewhere in a few mins

👍

$ ys -pC '*sci-version*'
{:major 0, :minor 8, :incremental 41}

using

(def sci-version
  (sci/new-var '*sci-version*
    (->>
      (io/resource "SCI_VERSION")
      slurp
      str/trim-newline
      (#(str/split % #"\."))
      (map #(if (re-matches #"\d+" %) (parse-long %) %))
      (zipmap [:major :minor :incremental :qualifier]))))

Many others too, but the others seemed very esoteric to me. TBH I've never use the 4 above, but they seemed possibly useful.

SCI should work with older versions of clojure so for now it's better if you add those manually

with sci/copy-var

aha, that makes sense

so they would work if added as far as you know?

unquote-splicing isn't really used in programs. I've never come across a program that used cast

check

I also noticed dosync but transactions is probably a big can of worms

check bb which has that

but most people never use it

sci is pretty amazing. was it a lot of work?

yes

how long was it from conception to birth?

Well, it was quite useful already from the beginning but a lot has happened in the last 4 years to improve performance etc

lingy (my perl platform for clojure) would take a lot to get fully bootstrapped. but sci+graal makes getting yamlscript bootstrapped trivial. even though "trivial" is turning into 6+ months.

it's always the little things that slow me down... but the overall picture hasn't changed since when I learned about sci/graal in July

Every week I thought, I'll get it done this week. 😄 And I haven't taken barely a day off