[foreign] RFR 8208199: Revisit one interface per header file approach
Samuel Audet
samuel.audet at gmail.com
Thu Aug 16 04:54:38 UTC 2018
BTW2, I've recently started to document how to use the InfoMap of
JavaCPP (this corresponds to what John refers to as "side file") for
specific situations as a sort of guide:
https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes
I hope that some of these ideas can make there way to jextract...
Samuel
On 08/09/2018 11:57 AM, Samuel Audet wrote:
> BTW, we can do some pretty nasty stuff with the preprocessor. For
> example, how would jextract handle something like this?
>
> // header.h
> #ifdef USE_DOUBLE
> #define real double
> #define func(f) f
> #endif
>
> #ifdef USE_FLOAT
> #define real float
> #define func(f) s ## f
> #endif
>
> #ifdef USE_HALF
> #define real half
> #define func(f) h ## f
> #endif
>
> real func(some_function)(real *data);
> int some_other_function();
>
> In this case, users are expected to include header.h more than once,
> with different values for the type. Do we create 3 classes? If so, how
> do we specify their names? Or do we generate only one class with all the
> functions in them? If so, how do we resolve the inevitable name clashes
> such as with some_other_function()?
>
> More to the point, this isn't some imaginary scenario, this is exactly
> how CMINPACK works, we need to think about those things:
> https://github.com/bytedeco/javacpp-presets/tree/master/cminpack
>
> Does jextract offer ways to work around this kind of situation? If the
> community here is serious about scientific applications, we need to
> think about the libraries we want to support! For example, we could make
> a list or something and target those...
>
> Samuel
>
> On 08/08/2018 10:06 PM, Maurizio Cimadamore wrote:
>>
>>
>> On 08/08/18 13:25, Sundararajan Athijegannathan wrote:
>>> May I suggest that we go with the current scheme (which is minimal
>>> changes) and revisit based on use-cases?
>> While I'm fine with the changes, and I agree that they are 'minimal',
>> I'm also worried that they add a new design dimension that is not
>> fully explored. Some of the issues with the approach are the lack of
>> granularity in specifying the set of headers to be 'followed', as well
>> as the fact that this new multi-header mode completely invalidates the
>> assumptions of unresolved layout resolution - the assumption there was
>> that any layout mentioned in a class C could be resolvable by looking
>> at the outermost enclosing class of C (**).
>>
>> My feeling is that we have both missing metadata and missing jextract
>> options here.
>>
>> (**) Consider this example:
>>
>> //a.h
>> import "b.h"
>>
>> void fn(struct S);
>>
>> //b.h
>> struct S { int i; };
>>
>> If you extract this with jextract, you get two headers, one for 'a'
>> and one for 'b'. The function descriptor for 'fn', which is in
>> 'a.class' will refer to the layout of S, which is in B.class. With
>> your patch, a.class will also 'implement' b.class. Here, the resolver
>> for a.class knows nothing about S. The only way to support this
>> resolution is via ad-hoc prescanning of all classes in the signatures
>> of a.class (which we currently do, but it's a mouthful, design-wise).
>>
>> My hope here is to come up with a mechanism to specify related headers
>> both from a point of view of jextract flag (e.g. so that jextract will
>> follow headers), but also in a way so that the information about the
>> header relationship is preserved at runtime into some metadata; that
>> way, the information can be used to perform layout resolution in a
>> precise and well-defined way.
>>
>> While this patch defines no additional metadata, one could argue that
>> the injected subtyping relationship it provides is, itself, some form
>> of metadata we could exploit during resolution. And, using inheritance
>> has the obvious advantage of exposing a model that 'makes sense' for
>> Java users.
>>
>> With all these things in mind, let's give this code a try - and see if
>> we can fit a story for better layout resolution on top of it.
>>
>> Cheers
>> Maurizio
>>
>>
>
More information about the panama-dev
mailing list