[foreign-jextract] RFR 8237577 minimal jextract tool on jextract API

[Ty Young]

On 1/22/20 12:46 AM, John Rose wrote:
> On Jan 21, 2020, at 6:31 PM, Ty Young <youngty1997 at gmail.com 
> <mailto:youngty1997 at gmail.com>> wrote:
>>
>> Without a higher level abstraction I don't think I'm personally going 
>> to be using this as-is. Hopefully the jextract API really lets me 
>> improve things otherwise I think I'm going to do everything myself so 
>> that the bindings more closely resemble the old API.
>
> This is a fair observation.  It reminds me of the distinction in the
> git tools between porcelain and plumbing[1].  Maybe we’re still working
> on the plumbing?  But even if that’s the case it’s not too early to
> collect observations and requests for “porcelain”.


"plumbing" is a very apt way to describe Memory Access.


To be clear, I've been advocating for "porcelain" for awhile(relatively 
speaking). Like I said, I kinda knew it would turn out bad and had(if it 
wasn't evident before) the intention to wrap it in a higher level API of 
my own but uh... what jextract generates right now is a bit of an octopus.


It has:


- constants(good)


- var handles - even for struct fields(bad)


- memory layouts - not what I want/need(bad)


- method handles - functions themselves already exist(bad)


- functions - generates(good) but also generates struct field 
setters/getters?(bad)


So it seems kinda broken. The structs especially should probably be put 
into a class. That alone would clean things up a bit, I think. The 
exposure of memory method/var handles should be made an optional, non 
default jextract switch I think.


also, NVML uses a Pointer to an empty struct to represent a GPU:


typedef struct nvmlDevice_st* nvmlDevice_t;


which seems to be omitted from the generated class. I'm not entirely 
sure how to handle this manually either. I'm guessing I need to use 
ForeignUnsafe to get the Pointer from C(hence why, in the old API it's 
Pointer<Pointer<nvmlDevice_st>>). I guess the fact that a struct is 
being used is irrelevant from the eyes of Memory Access, since it 
doesn't have field and is therefore in an undefined state?


>
> — John
>
> [1]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain