[foreign] Panama EA - August 2019 edition

[Ty Young]

On 8/30/19 12:25 PM, Maurizio Cimadamore wrote:
>
> On 30/08/2019 17:59, Ty Young wrote:
>>
>> On 8/28/19 5:11 AM, Maurizio Cimadamore wrote:
>>> I just want to clarify on this point below; the foreign memory 
>>> access work does not, in any way, hinder the higher level 
>>> functionalities provided by the foreign API/binder. We arrived at 
>>> the foreign memory access API because we felt that something low 
>>> level was missing - e.g. that the high level Pointer API was doing 
>>> too much at once; and that users not interested in a high-level API, 
>>> but still wanting to access off-heap data would not be served very 
>>> well by the Pointer API alone.
>>>
>>> So, moving forward you can expect the bulk of the foreign API to be 
>>> relatively stable (well, it's a prototype, so we might tweak things 
>>> here and there); what will really change is how this API is 
>>> _implemented_ - that is, moving forward the foreign API will be 
>>> built _on top_ of the lower memory access and ABI layers. But 
>>> high-level use cases using jextract need not to worry about this.
>>>
>>> I hope this clarifies better where we'd like to land.
>>
>>
>> Yes, it does greatly. Thanks for clarifying.
>>
>>
>> Speaking of the Pointer API, could a method be added to wrap a 
>> pointer in another pointer for **char string pointers? AFAIK, the 
>> only way to do that is:
>>
>>
>> <LIB>.scope().allocate(<LIB>.scope().allocateCString("").type().pointer()); 
>>
>>
>>
>> ...which gets the Pointer<Pointer<Byte>> type that I need but I'm not 
>> entirely sure if this is the correct way to go about getting the 
>> type. Using the layout of a throwaway pointer layout just seems wrong 
>> and wasteful.
>
> If you want to allocate a Pointer<Pointer<Byte>> you can do this:
>
>
> <LIB>.scope().allocate(NativeTypes.UINT8.pointer());
>

Is the size the same as a C String with that?


>
> Maurizio
>
>
>>
>>
>>>
>>> Cheers
>>> Maurizio
>>>
>>> On 19/08/2019 10:33, sundararajan.athijegannathan at oracle.com wrote:
>>>>>
>>>>> All that said, how close is Panama? Is this foreign memory API 
>>>>> going to stay going forward or will the project take a major 
>>>>> shift? I'd *really* like to start putting this to use and am 
>>>>> willing to make adjustment where needed if minor changes are made, 
>>>>> but if the entire foreign API is scrapped it isn't worth it.
>>>>
>>>>
>>>> Panama "memory access" ("memaccess" panama-dev branch) API is 
>>>> expected to become stable first and then other parts of 
>>>> java.foreign later ("foreign" branch stuff).