This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-05
Channels
- # adventofcode (138)
- # announcements (1)
- # babashka (4)
- # beginners (71)
- # biff (2)
- # calva (7)
- # cider (20)
- # clj-kondo (4)
- # cljsrn (4)
- # clojure (36)
- # clojure-europe (37)
- # clojure-nl (2)
- # clojure-norway (27)
- # clojure-portugal (1)
- # clojure-uk (4)
- # clojurescript (8)
- # emacs (3)
- # graphql (1)
- # hugsql (4)
- # humbleui (6)
- # hyperfiddle (1)
- # jobs-discuss (18)
- # joyride (2)
- # malli (17)
- # meander (7)
- # membrane (8)
- # off-topic (16)
- # pathom (14)
- # portal (4)
- # rdf (36)
- # reitit (4)
- # releases (2)
- # remote-jobs (1)
- # scittle (15)
- # shadow-cljs (13)
- # tools-deps (40)
Are there any examples of dynamically building an instance of a protocol when :extend-via-metadata
is false? Is it possible short of generating bytecode?
I’d like to do it dynamically, i.e. data driven. Let’s say I’m given the protocol definition var, a method symbol, and an fn
, and I’d like to return an instance of the protocol that calls f. That’s easy to do when :extend-via-metadata
is true. Is it possible to do when its false
I mean with eval yes, but otherwise I'd say it'd require messing with internals if it's possible at all.
@U050ECB92 sure, if that makes it easier
you can automatically generate a proxy that delegates:
(defn make-proxy [f] (reify (sig [this ...args] (f ...args))))
statically make one uber-proxy like above, or dynamically using eval (probably memoized by protofn)
If I don’t know the signature of the protocol ahead of time, how do I build that proxy [edit] without eval?
you're not going to get away from calling eval if you can be passed an arbitrary protocol impl that you need to make
I just need an existing function. I don’t need eval when :extend-via-metadata
is true, so I find it plausible I can do it without. It looks like calling reify*
directly might work, will investigate more
This seems to work (I guess it's an accidental behavior, though):
(defprotocol P (m [this]))
(extend (class conj) P {:m (fn [_] "conj")})
(m conj) ;=> "conj"
Forgot to add args.lenght
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AFn.java#L140
Hey Everyone, Need some help with Java Interop, Trying to write a Clojure version of this class --> https://docs.amazonaws.cn/en_us/neptune/latest/userguide/access-graph-gremlin-java.html Mainly creating the Cluster and GraphTraversalSource. I also had a look at Orge, Tinkerpop library for Clojure. But Couldn’t find any examples to connect to remote Gremlin Server. Any help will be much appreciated. Thanks!
for creating a Cluster object you can create it like :
(def builder (Cluster/build))
...
...
(def cluster (.create builder))
and then looks like you need to import org.apache.tinkerpop.gremlin.process.traversal.AnonymousTraversalSource
, like :
(ns ...
(:import [org.apache.tinkerpop.gremlin.process.traversal AnonymousTraversalSource ...]
...))
so you can then do like:
(def g (.withRemote (AnonymousTraversalSource/traversal) (DriverRemoteConnection/using cluster)))
does it make sense?
Please don’t crosspost in multiple channels and if you do so then at least link your postings
@U0739PUFQ thank you! this works!
We bundle some 3rd party drivers into jar with jar uf metabase.jar modules/*.jar
. This is throwing a java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 61.0
. Our jar is a multi-release jar and as far as I can tell, it is because there is a classfile in there that is compiled against classfile 61 (java 17), but it is done in a way such that the multi-release should allow it.
META-INF/versions/17/com/oracle/truffle/api/staticobject/StaticPropertyValidator.class
I would expect that a multi-release jar can see classfiles it does not understand if they are in the versions/17/…
format. Is this a wrong assumption? Can we not run jar uf …
with java 11 if there are java 17 classfiles around in a multi-release format?
the module-info.class in the jar is what has that major.minor version and is what is causing jar to barf, not the stuff under versions
that sounds like a decent guess. Does that mean that jar
cannot handle multi-release jars which contain class files for versions greater than the jdk being used? Seems like a weird thing and nothing seems obviously wrong here
yes
cannot handle multi-release jars which contain class files for versions greater than the jdk being used
Dang. Is that true? Documented anywhere? Seems wild that “java” can correctly ignore the Java 17 files there with the multi release jar but “jar” cannot