Pointer/Scope API questions

[Ty Young]

On 1/7/20 11:11 AM, Maurizio Cimadamore wrote:
>
>>>
>>> We will start working on pushing an initial implementation for the 
>>> minimal extraction tool.
>>
>>
>> If you're sure this is the route you're going towards i'd be happy to 
>> take it for a spin if it's in a semi-usable state. Do you plan on 
>> doing a basic run down of how to use it?
>
> Of course - in the next few weeks, we plan to (1) push a minimal 
> workable jextract tool based on the API, then (2) rework all existing 
> documented usages examples of jextract to be based on top of the 
> minimal bindings (3) release a binary snapshot with memory access + 
> native method handle + minimal jextract.
>
> Does that sound good?


Sorry if i'm coming off as pushy. Yes, that sounds great.


>
>>
>>
>>>
>>>>
>>>>
>>>> I don't feel like Pointer should be abandoned though. Pointer is an 
>>>> interface, not an implementation.... If there are platform specific 
>>>> details that need to be worked out then that's an implementation 
>>>> issue. jextract can(and actively does) have the ability to dump 
>>>> working binding code that can be modified as desired. Could 
>>>> jextract not simply have the ability to generate very generic 
>>>> bindings for those that just want native access quickly(or don't 
>>>> care about cross-platform or whatever else) or as a base to work 
>>>> off of to provide higher quality bindings? 
>>>
>>> As I said, a jextract tool will be provided, only it will not do 
>>> exactly what it does today, and the methods it will generate will be 
>>> slightly lower level. Exactly how much lower level, is still TBD - 
>>> we are at a very early stage, but with more experience working with 
>>> minimal bindings, my hope is that we will soon converge to an 
>>> idiomatic form that is both usable and, yet, primitive enough to be 
>>> extensible.
>>
>>
>> For my use case(example: [1]) currently I'm not even using jextract 
>> bindings raw but instead creating a wrapper to convert the C function 
>> bindings to an object oriented API. Based on prior discussion on 
>> accessing functions not specified in a header, its sounding like the 
>> use of jextract can be/is null and void in part or completely if you 
>> can just define everything yourself. By the end of this, what 
>> benefits is jextract even providing exactly?
>
> I remember your use case - if you have no header, jextract can't help 
> you much - it couldn't before, it will not be able to in the future.


To be clear, my use case involves wrapping *multiple* native API 
libraries into multiple Java object orientated abstracted APIs. All but 
one have a header, and that's what I brought up awhile ago.


What I linked is an example of how an Nvidia attribute is implemented in 
my API. I linked it because it shows how to-the-point and easy Pointer 
is. My API implements 50+ Nvidia attributes which is very easy(as I 
linked) under Pointer... however doing this without some higher level 
would result in these small implementations becoming much larger - 
unless of course I make my own Pointer... but for use cases like mine, 
defining what a Pointer is when Project Panama could provide that 
definition(from an interface prospective) hurts more than it helps.


What if someone made bindings of CUDA and wanted to use my(or someone 
else's bindings/abstractions) APIs together? Again, name clashes and 
fragmentation.


>
> But let's not pretend this is the common case - what you are doing in 
> [1] is very very very specific. In 99.999999% cases, users do have 
> some headers to work with. In which cases jextract will use the info 
> from the header to generate all layouts, var handles, method handles, 
> and some static wrappers on top.


Fair enough.


>
> Maurizio
>
>>
>>
>> [1] 
>> https://github.com/BlueGoliath/GoliathEnviousNative/blob/master/modules/org.goliath.envious.nvml/src/main/java/org/goliath/envious/nvml/local/attributes/utilization/NVMLGPUGraphicsUtilizationAttribute.java
>>
>>
>>>
>>> Maurizio
>>>
>>>