This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-26
Channels
- # aws-lambda (15)
- # babashka (7)
- # beginners (124)
- # calva (7)
- # cider (19)
- # clj-kondo (26)
- # clojure (261)
- # clojure-australia (3)
- # clojure-dev (10)
- # clojure-europe (45)
- # clojure-nl (4)
- # clojure-uk (6)
- # clojurescript (10)
- # datomic (7)
- # depstar (7)
- # emacs (11)
- # fulcro (41)
- # graalvm (48)
- # helix (1)
- # honeysql (17)
- # inf-clojure (7)
- # introduce-yourself (3)
- # jackdaw (2)
- # lsp (36)
- # malli (2)
- # meander (2)
- # membrane (1)
- # missionary (11)
- # off-topic (17)
- # pathom (83)
- # polylith (15)
- # re-frame (31)
- # reagent (42)
- # sci (35)
- # shadow-cljs (13)
- # spacemacs (13)
- # sql (19)
- # timbre (3)
- # tools-deps (77)
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}
In babashka I generate the reflection config programmatically from a list of classes
ah, ok. when I tried adding it to the reflection config, I started getting duplicate symbol errors duplicate symbol "_JNI_OnLoad_prefs"
which I couldn't figure out how to fix, so I'll probably just stick with exposing a compiled function that can create urls.
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
which is the same error. It might go away if I upgrade.
you could also fake the constructor by inserting a function
into clojure.core
;)
yea, I'm ok with using a workaround for now. I'm hoping that the issue will resolve itself with a future upgrade.
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
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.
yes, you should "patch" that compiled function to go through the multimethod first if you want this to work
interesting
I found that alter-var-root
doesn't work in graalvm code, probably because of direct linking
but only the compiled function should be patch inside sci I guess, since your entire program runs in SCI right
but I could do something similar
the code I'm calling is my own library, so I could probably add some graalvm reader conditionals to just use multimethods
ok, that sounds like a plan. I'll give it a try at some point. Thanks for the tip!
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
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]))
;)it's called aaaa-...
so it's always loaded first when the libspecs are sorted alphabetically
I did not know that was a thing
@smith.adriane you could also consider marking your compile time functions with ^:redef
yea, that seems like it might be a good option