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

[Jorn Vernee]

Hi Mark,

> 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.

We have Scope::allocateArray(LayoutType<X>, Object); for that. e.g.:

```
     try (Scope scope = Scope.globalScope().fork()) {
         Array<Integer> nativeArr = 
scope.allocateArray(NativeTypes.INT32, new int[]{ 1, 2, 3 });
         nativeArr.iterate().map(Pointer::get).forEach(out::println); // 
1 2 3
     }
```

> 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.

I'm not sure what's going on there. I can use the ToolProvider interface 
to run jextract successfully e.g.:

```
     private static final ToolProvider JEXTRACT = 
ToolProvider.findFirst("jextract").get();

     public static void main(String[] args) {
         test();
     }

     public static void test() {
         Path dir = Paths.get("J:\\WS\\jextract\\test");
         Path jar = Paths.get("Test.jar");
         Path testH = dir.resolve("test1.h");

         System.setProperty("jextract.debug", "true");
         int result = JEXTRACT.run(System.out, System.err,
                 "-o", jar.toString(),
                 "--no-locations",
                 "-t", "org",
                 "--",
                 testH.toString());
         System.out.println(result);
     }
```

Which still works today and produces a jar.

The only thing I could say looking at your build script [1] is that you 
seem to be printing out the jextract results to System.out and 
System.err but then returning 2 empty Strings instead:

```
     val result = for(tool <- maybeTool) yield {
         println(s"running ${tool.name()}")
         val stdOut = new ByteArrayOutputStream()
         val errOut = new ByteArrayOutputStream()
         tool.run(new PrintWriter(System.out), new 
PrintWriter(System.err), arguments: _*)
         (new String(stdOut.toByteArray), new String(errOut.toByteArray))
     }
```

But, I suppose that is just for testing?

Also, like in my snippet, you could try enabling jextract debug output 
with `System.setProperty("jextract.debug", "true");` and see if anything 
is printed then.

Jorn

[1] : 
https://github.com/markehammons/Wayland-McWayface_JVM-edition/blob/master/build.sbt

Mark Hammons schreef op 2019-02-24 19:31:
> 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
>>> 
>>>