Panama feedback

[Maurizio Cimadamore]

On 31/03/2020 23:30, Ty Young wrote:
>
> 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.

What I was saying was that, if we exposed the visitor that takes care of 
the code generation, then you don't even need to bother generating 
sources or classes. You get a tree of declaration (as parsed from clang 
- but wrapped in a nicer API) and you can transform the tree, by pruning 
the parts you don't want, to form a new (smaller) tree.

Then you can just call the code generator visitor, and the bits which 
"survived" the filtering will be generated.


>
>
> <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!

I'll think about this use case. To me, the "right" way to support this 
would be:

1) allow sequence layouts with zero elements, for completeness
2) when calling MemorySegment::allocateNative, if allocated size is 
zero, return the Nothing segment

I'm not sure how high priority this use case is, but this is something 
we can keep in the back of our mind in case we encounter a similar 
problem again.

Maurizio

>
>
>> 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
>>