Fork me on GitHub
#sci
<
2021-09-01
>
gmercer07:09:53

Hi, I have a Java project that has been leveraging the clojure RT object to use edn as config, in turn the edn may have clojure functions as values and other goodies, we were looking at throwing Graal at our project, and thinking we could switch out direct use of clojure RT and using sci to interpret instead. I am just having trouble finding the core entrypoint to bootstrap sci .. so that I could eventually call

sci.core$eval_string_STAR_.invokeStatic(sciCtx, code) or sci.core$eval_string(code)
hidden behind a Java facade. Is this possible ?

borkdude07:09:06

I think it’s also possible to make one function in Clojure to do your SCI config and then use genclass to make it available to Java

borkdude07:09:23

Those are your two options

gmercer07:09:38

thanks - and sticking to the constraints of sci .. should make Graal a possibility

borkdude07:09:00

@gmercer note that you can also make clojure.lang.RT available in SCI, I'm not sure why you were using that

borkdude07:09:50

but programming against clojure.lang.RT is not recommended, as its basically an implementation detail of Clojure, not intended as an API

gmercer08:09:40

@borkdude probably old school stackoverflow examples .. unfortunately, I am still getting Graal defining class from bytecodes not supported, desperately combining over babashka to see how it is done 😉

borkdude08:09:33

@gmercer if you need any help on closed source code I can also come on to a call or something and you can pay me. if it's open source I could just take a look at the code. Just letting you know that this is a possibility :)

borkdude08:09:02

sometimes just using the flag --report-unsupported-elements-at-runtime can be helpful as graal may think you will hit something at runtime in the compiler which you actually don't