Finished part 1 of the Wayland McWayface tutorial of Drew DeVault - Issue with spi toolprovider interface and jextract

[Sundararajan Athijegannathan]

Yes - we've a test for jextract ToolProvider interface and it works. If 
jextract failed, it'll return non-zero exit code from "run" method.

Will you please provide your code snippet and/or test program?

Btw, you can run test program with System property setting 
-Djextract.debug=true. Also please pass  --log=INFO option to jextract 
tool. These should give some detail to debug.

Thanks,
-Sundar

On 25/02/19, 12:01 AM, Mark Hammons wrote:
> Hi Maurizio,
>
> Regarding 1) I would try to fork the global scope to create pointers 
> for my callbacks. However, since the object that was taking the 
> callbacks was created by a wlr_backend_autocreate foreign function 
> call, I guess the scopes were incompatible and it would not accept the 
> pointers from the forked scope. You can give it a shot with my 
> repository. Just pass in scope.fork to anywhere I'm passing in a scope 
> and you should see the access violation messages.
>
> 2) I'm glad to hear this has been completely fixed, and I look forward 
> to the next release. Will that be coming soon?
>
> 3) Yeah, I allocated a c array using the scope and filled it with my 
> data. It just feels like something that should be achievable by 
> passing in a java array to my scope.
>
> 4) That code looks like it's testing jextract. I'm not sure what''s 
> going on then, cause when I ran my tool runner method with jextract 
> and the appropriate arguments (and I tested the generated arguments by 
> copy pasting them to a standard command line), jextract returned 
> nothing and exited very quickly.
>
> Thanks,
>
> Mark
>
> On 2/24/19 1:30 AM, Maurizio Cimadamore wrote:
>>
>> On 23/02/2019 23:26, Mark Hammons wrote:
>>> Hi all,
>>>
>>> I've finally written a working implementation of the first part of 
>>> Drew DeVault's tutorial, and I wanted to put it here first to get 
>>> your feedback
>>>
>>> https://github.com/markehammons/Wayland-McWayface_JVM-edition/tree/Part1 
>>>
>> Thanks! I'll look into that in more details.
>>>
>>> I've tried using the new forked scopes in the recent release, but I 
>>> frequently hit issues of being unable to use pointers I need to use. 
>>> This usually happens with the allocated callbacks, so I assume I 
>>> could merge said callback's pointers into the scope of what they're 
>>> being assigned to, but I haven't tried that yet. The struct issue I 
>>> reported earlier continues to plague me, and has resulted in me 
>>> writing a few workaround classes in java. Also, I allocated a 
>>> c_array to communicate with a function call but is there no way to 
>>> just pass in a regular java array at this time?
>>
>> So:
>>
>> 1) I'd like to know more about the issues with pointer/callback - 
>> e.g. what issues have you encountered; if it mostly happens with 
>> callbacks, there could be some lurking issue with scoping of these 
>> callback pointers?
>>
>> 2) the struct issue has been fixed - you'll see that situation 
>> improved on the next binary build
>>
>> 3) if you want to pass an array to a native function you have to 
>> create a native array; while in the future we might provide 
>> 'civilization' options to emit signatures closer to what a Java 
>> developer would expect, that's not the goal now. You should be able 
>> to allocate a native array from Java array with relative ease.
>>
>>>
>>> Finally, and this is the biggest issue, I cannot get jextract 
>>> working via the spi.ToolProvider interface. If you look at the 
>>> build.sbt in the root of my project, I have defined a task binding 
>>> for jextract to be called and configured by sbt without having to 
>>> call outside of the JVM. When I tried this with jlink 
>>> (https://gist.github.com/markehammons/42d75709e060625f1a663b442842b461) 
>>> it worked fine, and spi.ToolProvider says it's finding jextract, 
>>> jextract is just not doing anything. I'm guessing the jextract tool 
>>> isn't hooked into ToolProvider yet?
>>
>> This surprises me - I'll leave this to Sundar - but I seem to recall 
>> that jextract was indeed hooked up and that we're even using that 
>> capability for testing? The following was pushed last year
>>
>> http://cr.openjdk.java.net/~sundar/jextract_tool_provider_testng/webrev.00/raw_files/new/test/jdk/com/sun/tools/jextract/JextractToolProviderTest.java 
>>
>>
>> Maurizio
>>
>>
>>>
>>> Anyway, tell me if you have any suggestions to improve my usage of 
>>> the foreign APIs in this project. And especially tell me if I can 
>>> get jextract working through the ToolProvider interface. I'd love to 
>>> start developing sbt and mill plugins for projects to bind native 
>>> code with, but I can't till that gets worked out.
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>>