Fork me on GitHub
#sci
<
2021-07-26
>
phronmophobic20:07:59

I'm getting an error when I try to instantiate a java class in a sci repl.

user> (java.net.URL. "")
java.lang.IllegalArgumentException: No matching ctor found for class java.net.URL user *cider-repl examples/t3tr0s-bare:192.168.0.48:23456(clj)*:1:1
I don't think it's a graalvm issue since I can call a compiled function from sci that constructs a URL. I've added :classes to my sci context like so:
:classes {'java.net.URL java.net.URL}

borkdude20:07:08

you should add java.net.URL to your reflection config

borkdude20:07:28

since interop in SCI is implemented using reflection

borkdude20:07:07

In babashka I generate the reflection config programmatically from a list of classes

borkdude20:07:14

which I also feed to SCI

phronmophobic20:07:24

ah, ok. when I tried adding it to the reflection config, I started getting duplicate symbol errors duplicate symbol "_JNI_OnLoad_prefs"

phronmophobic20:07:03

which I couldn't figure out how to fix, so I'll probably just stick with exposing a compiled function that can create urls.

borkdude20:07:32

I think it's worth looking into, supporting normal interop is useful

borkdude20:07:30

I see some gluon related thing in google when I search for this

phronmophobic20:07:33

I did spend some time looking into it, but couldn't figure it out. The only reference I could find on the internet is https://githubmemory.com/repo/gluonhq/substrate/issues/948

borkdude20:07:45

right, weird!

phronmophobic20:07:53

which is the same error. It might go away if I upgrade.

borkdude20:07:05

you could also fake the constructor by inserting a function .URL. into clojure.core ;)

borkdude20:07:17

that's how I implemented interop in the very beginning in SCI ;)

phronmophobic20:07:02

yea, I'm ok with using a workaround for now. I'm hoping that the issue will resolve itself with a future upgrade.

borkdude20:07:13

sure, that sounds alright

borkdude20:07:51

maybe couldn't hurt to post an issue about it on the graalvm tracker, even just so others can find it and react to it or so

borkdude20:07:03

but they likely want a repro

phronmophobic20:07:19

I wasn't able to get the defrecord protocol extension to work. The issue is that in compiled clojure code, I create protocols and then all the code is defined in terms of those protocols. If I call the protocols directly in sci, everything works using the multimethod example you provided, but if I call a compiled function that eventually calls the compiled version of a procotol, then it doesn't know how to dispatch on the sci record instance.

borkdude20:07:31

yes, you should "patch" that compiled function to go through the multimethod first if you want this to work

borkdude20:07:52

you can perhaps do so using alter-var-root

phronmophobic20:07:45

I found that alter-var-root doesn't work in graalvm code, probably because of direct linking

borkdude20:07:46

but only the compiled function should be patch inside sci I guess, since your entire program runs in SCI right

phronmophobic20:07:03

but I could do something similar

borkdude20:07:04

yes, you should take direct linking into account and patch the entire "tree"

phronmophobic20:07:57

the code I'm calling is my own library, so I could probably add some graalvm reader conditionals to just use multimethods

phronmophobic20:07:44

ok, that sounds like a plan. I'll give it a try at some point. Thanks for the tip!

borkdude20:07:31

yeah, or you could load a patch namespace or so first before everything else. this is what I'm sometimes doing in babashka as well

borkdude20:07:06

I have one namespace like:

(ns aaaa-this-has-to-be-first-because-patches
  ;; we need pprint loaded first, it patches pprint to not bloat the GraalVM binary
  (:require [babashka.impl.pprint]))
;)

borkdude20:07:19

it's called aaaa-... so it's always loaded first when the libspecs are sorted alphabetically

phronmophobic20:07:26

I did not know that was a thing notbad

borkdude21:07:43

@smith.adriane you could also consider marking your compile time functions with ^:redef

borkdude21:07:55

then you are able to patch them and direct linking won't affect those

phronmophobic21:07:51

yea, that seems like it might be a good option