Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to and GraalVM slack:
Saikyun 2020-06-22T11:52:53.455200Z

@borkdude is it easy to start a (socket) repl for sci running on clojure+graalvm? I looked around a bit in the docs for sci, but couldn't find an answer

Saikyun 2020-06-22T11:53:33.456100Z

could one use clojure.core.server/start-server with sci somehow? 🙂

borkdude 2020-06-22T11:53:44.456400Z

@saikyun The most complete example I have of this is babashka, which ships with both socket repl and nREPL

borkdude 2020-06-22T11:54:28.457300Z

babashka.nrepl is the easiest to integrate since that's been split out into a library:

Saikyun 2020-06-22T11:55:21.458100Z

ah, cool, thanks for the info 🙂

borkdude 2020-06-22T11:56:12.458700Z

if you need a socket REPL we could make a similar project which splits out the socket repl from babashka for use in other sci GraalVM projects

Saikyun 2020-06-22T11:57:19.459500Z

hehe, my favourite repl client is based on socket repl. but in this case, I'm mostly looking for speeding up my iteration cycle when trying out things in graalvm.

Saikyun 2020-06-22T11:57:37.460Z

so for now, trying the nrepl version is more than good enough for me 🙂

borkdude 2020-06-22T11:58:24.460600Z

the best iteration cycle is probably: develop on the JVM as long as possible and only compile to native as a last step

Saikyun 2020-06-22T11:58:48.461Z

agree. in this case though, it's native image specific behaviour I'm trying to inspect

borkdude 2020-06-22T11:58:53.461200Z

ah right

Saikyun 2020-06-22T11:59:31.461900Z

specifically, I'm trying to figure out the differences and similarities between polyglot with llvm context, and graalvm.c

Saikyun 2020-06-22T12:15:15.462700Z

@borkdude I got babashka.nrepl working in a jvm repl, but when trying to run it with native image I get this:

[thread:42] scope: ForkJoinPool-2-worker-21
  [thread:42] scope: ForkJoinPool-2-worker-21.ClosedWorldAnalysis
  Context: StructuredGraph:8140{AnalysisMethod<sci.impl.Reflector.canAccess -> HotSpotMethod<Reflector.canAccess(Method, Object)>>}
  Context: AnalysisMethod<sci.impl.Reflector.canAccess -> HotSpotMethod<Reflector.canAccess(Method, Object)>>
      [thread:42] scope: ForkJoinPool-2-worker-21.ClosedWorldAnalysis.AnalysisGraphBuilderPhase.IntrinsifyMethodHandles
      Context: StructuredGraph:8180{HotSpotMethod<Invokers$Holder.invoke_MT(Object, Object, Object, Object)>}
      Exception raised in scope ForkJoinPool-2-worker-21.ClosedWorldAnalysis.AnalysisGraphBuilderPhase.IntrinsifyMethodHandles: Invoke with MethodHandle argument could not be reduced to at most a single call or single field access. The method handle must be a compile time constant, e.g., be loaded from a `static final` field. Method that contains the method handle invocation: java.lang.invoke.Invokers$Holder.invoke_MT(Object, Object, Object, Object)

Saikyun 2020-06-22T12:15:24.462900Z

any ideas? 🙂

Saikyun 2020-06-22T12:15:40.463200Z

I use this example:

borkdude 2020-06-22T12:15:50.463600Z

yes, this is because you're probably using graalvm jdk11?

borkdude 2020-06-22T12:16:20.463900Z


Saikyun 2020-06-22T12:16:20.464Z


Saikyun 2020-06-22T12:16:28.464400Z

ah, thanks

borkdude 2020-06-22T12:16:52.464600Z

Also you'll need

borkdude 2020-06-22T12:16:55.464900Z


Saikyun 2020-06-22T12:17:44.465200Z

I'll try it! 🙂

Saikyun 2020-06-22T12:19:47.465600Z

ah, of course I'm on a unsupported version of graalvm ^^;

Saikyun 2020-06-22T12:19:57.466Z


Saikyun 2020-06-22T12:20:06.466200Z

maybe I should try a non-dev version

borkdude 2020-06-22T12:20:17.466500Z

is there a reason you're using the dev version?

borkdude 2020-06-22T12:20:42.467Z

you can still use your dev version, but you'll need this to compile yourself:

Saikyun 2020-06-22T12:20:47.467300Z

I'm actually not sure anymore. I ended up here when trying various examples

Saikyun 2020-06-22T12:21:15.467800Z

aha, I could just import the source?

borkdude 2020-06-22T12:21:43.468300Z

it depends on svm.jar in the graalvm distribution so you'll also need to add that to your classpath when compiling it

borkdude 2020-06-22T12:22:03.468600Z

dev versions don't have a published version of svm.jar on maven

Saikyun 2020-06-22T12:23:25.469200Z

okay, I see. I found svm.jar in my graalvm distribution, so I'll give it a shot 🙂

Saikyun 2020-06-22T12:35:50.469500Z

hah, now it works. thanks a lot! this will be very helpful 🙂

Saikyun 2020-06-22T12:38:07.470100Z

I feel a bit of discomfort when I think about the research and work you've had to do to get it all running this well. thanks a lot for that!

Saikyun 2020-06-22T12:38:27.470700Z

I've already peeked a lot at babashka to get started with ni + clojure, so that's been very helpful as well 🙂

Saikyun 2020-06-22T12:50:01.472300Z

hm, for some reason I'm having trouble calling static methods on classes. I've added the class to reflection.json and added this flag to ni call: "-H:ReflectionConfigurationFiles=reflection.json". I can eval the class name, but all methods on it seem gone (despite being able to call them in the source code precisely before the call to start-server!)

Saikyun 2020-06-22T12:50:42.472500Z

nvm, now it works

Saikyun 2020-06-22T12:51:02.473Z

not sure what I did wrong first though 😛 oh well

Saikyun 2020-06-22T12:52:35.473600Z

now I just get segfaults when trying to call (c) native functions, haha. I guess that's progress

Saikyun 2020-06-22T13:13:09.474400Z

is there a way inside the clojure source to know if one is in native-image or not? trying to find if one could set compile flags in leiningen somehow, but so far coming up short

borkdude 2020-06-22T13:55:38.474800Z

@saikyun Yes, check (System/getProperties), there are some graalvm specific things in there

Saikyun 2020-06-22T13:56:10.475Z

thanks 🙂