Panama feedback

[Ty Young]

On 3/31/20 8:43 AM, Maurizio Cimadamore wrote:


<snip>


>
> I think here it would be nice to understand how to improve the current 
> jextract API to make these kind of things more easily configurable. 
> The main idea is that it should be possible for people to do this by 
> just using a Java program (which you can then launch using the single 
> source launcher) so the difference between tool and API client is 
> fairly thin.
>

I don't have too much interest in the jextract API, to be honest. Making 
bindings is already so easy(at least for the basic stuff I'm using it 
for) and my abstraction layer makes contextual, opinionated bindings 
choices like interpreting a char pointer as an MemoryArray<Byte>. I 
don't know if a one-size-fits-all API can be done since everyone is 
going to disagree on things like above: should a char pointer just be a 
char pointer in Java or an array of bytes?


(That said, I wouldn't mind giving it a spin if some basic tutorial or 
template code was provided.)


My understanding is that it works by generating plain-text class files 
which is something I've never done before nor have the slightest clue on 
how to make reliable. If there was a JDK API that could generate classes 
reliably and with the least amount of boilerplate I might do it.


<snip>


>
> So, what you want is creating a segment that has zero length. This 
> seems very ad-hoc, I don't think I like the idea of adding that 
> ability to the API, since a zero-length segment cannot really be 
> closed, etc.
>
> I think what you want is some API on top to create an array given an 
> element layout and size and which returns a MemoryAddress
>
> e.g.
>
> MemoryAddress allocateArray(MemoryLayout elementLayout, long size) {
>     if (size == 0L) return MemoryAddress.NULL
>     else { ... create segment and return base address ... }
> }
>

I'd like a variant that accepts a SequenceLayout too, but otherwise yes!


> This test:
>
> https://github.com/openjdk/panama-foreign/blob/63d3ee093a881e92dd57b1090c3fb7ebec1c4c15/test/jdk/java/foreign/StdLibTest.java#L310 
>
>
> is using an upcall for the qsort comparator. Should contain all the 
> relevant bits.


Thanks!


>
>
> Thanks
> Maurizio
>