My sbt plugin is working

[Mark Hammons]

> If that's something people would find useful we could spin binaries for
> memory access + ABI.

I'm fairly certain I would find it useful, especially if it's paired with the 
rest of the current foreign API. I've also been wanted to toy with the vector 
and SIMD additions. Basically, any EA releases and/or features you have the 
time and will to publish I'd be very interested in using (though I don't know 
if I could have the time for everything).

> Thanks _you_ for taking the time to play with out stuff!

It's really no problem. I can say without exaggeration that among the 
technologies I've tried for jvm to native interop, foreign is the best I've 
used so far (I've tried toying with JNI, JNA, and JNR). jextract works really 
well for creating the binding code and the binding code makes a lot of sense. 
It's why I want to build tooling to make it easier and more natural to use 
with scala, I'm really excited for it to become a part of a standard openjdk 
install.

Any EA builds you have the will and spare time to release would be greatly 
appreciated by me. I'm all about the myriad additions to the JVM project 
panama is bringing, and I'm eager to start building stuff using these 
technologies even if that means I have to rewrite stuff pretty frequently as 
your approach changes.

Again, thanks for the help Maurizio, and thanks for your effort on this 
project,
Mark

On Monday, November 11, 2019 4:39:50 PM CET Maurizio Cimadamore wrote:
> On 11/11/2019 15:30, Mark Hammons wrote:
> > Ah I see,
> > 
> > Is there any chance that this will be put into an early access release
> > anytime soon? I've never built openjdk myself before.
> 
> If that's something people would find useful we could spin binaries for
> memory access + ABI.
> 
> > I'll probably go ahead and generate a java interface for my scala trait to
> > inherit from for now, since I would like my plugin to depend on the latest
> > EA build of panama instead of requiring users to build a JDK to use it,
> > but I may well add a branch to my code that uses the LibraryLookup API to
> > get pure scala bindings so I can switch to that when it becomes available
> > in EA builds.
> > 
> > Thanks a ton for the help Maurizio,
> 
> Thanks _you_ for taking the time to play with out stuff!
> 
> Maurizio
> 
> > Mark
> > 
> > On Monday, November 11, 2019 4:22:34 PM CET Maurizio Cimadamore wrote:
> >> I was referring to SystemABI in foreign-abi - in that branch, the API is
> >> public, and there's a LibraryLookup API to lookup the library symbol you
> >> are looking for.
> >> 
> >> Maurizio
> >> 
> >> On 11/11/2019 14:24, Mark Hammons wrote:
> >>> Hi Maurizio,
> >>> 
> >>> I'm not sure I fully understand. SystemABI resides in
> >>> jdk.internal.foreign,
> >>> and trying to access it gives me an IllegalAccessError. Is there an API
> >>> I'm
> >>> missing under java.foreign to do this? And it's not very clear how I'd
> >>> use
> >>> SystemABI to look up the right function and get a method handle. Also,
> >>> if
> >>> it requires poking around in java internals, won't that make my library
> >>> fairly difficult to use as the users would probably have to add special
> >>> jvm options to override the IllegalAccessError?
> >>> 
> >>> Thanks,
> >>> Mark
> >>> 
> >>> On Monday, November 11, 2019 2:26:47 PM CET Maurizio Cimadamore wrote:
> >>>> On 11/11/2019 12:40, Mark Hammons wrote:
> >>>>> However, I was curious if it would be feasible for java.foreign to be
> >>>>> a
> >>>>> little more lenient in what it binds to. If I were able to define a
> >>>>> method like this in scala:
> >>>>> @NativeFunction("(i32*)v")
> >>>>> def fn(i: Array[Int]): Unit
> >>>>> 
> >>>>> and have java foreign recognize that as a valid binding
> >>>> 
> >>>> Uhm - not 100% sure about that. (i32*) means - one i32 parameter,
> >>>> followed by a varargs list - e.g. in C
> >>>> 
> >>>> f(int i, ...)
> >>>> 
> >>>> So, how can you prove that an Array[Int] is the right type to hold all
> >>>> of the parameters?
> >>>> 
> >>>> One thing you might want to consider actually, would be for you to use
> >>>> the SystemABI API directly, to get a MethodHandle that accessed the
> >>>> right native function, and maybe add a varargs adaptation on top. In
> >>>> other words, I'm not sure how much of what you are doing needs
> >>>> panama/foreign an the annotation stuff, and how much of what you could
> >>>> do using the low level support in foreign-abi. Since that's lower level
> >>>> it will give you many more options on how to surface it at the Scala
> >>>> level.
> >>>> 
> >>>> Maurizio
> >>>> 
> >>>>> , that would allow me
> >>>>> to have a pure scala binding and make java.foreign 100% compatible
> >>>>> with
> >>>>> scala. I'm hopefuly that this is a possibility, though I'd understand
> >>>>> if
> >>>>> it's not something the project panama team wants to do or devote
> >>>>> resources to.