Is there something like *sci-version* ?
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]))))FWIW, I noticed these are not available in sci by default.
cast unquote-splicing update-keys update-vals
will those be added?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