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

[Mark Hammons]

Probably. I don't know if it's the reason the tool provider isn't 
working though, I'll have to test that later. In other news, I was 
testing the power consumption of my implementation vs the original c 
implementation of this software (with some minor tweaks since the 
wlroots library has had incompatible changes since this software was 
published), and the jvm implementation isn't super far off the original. 
It uses 2x the power on average, and when I look at what's going on with 
visualvm it says most of the time spent is on native callbacks  (not 
entirely surprising since one of the callbacks is called 60 times per 
second or more).

I would assume that the foreign interface is still not fully optimized? 
If it isn't, that seems like pretty great news cause it's already 
performing very well. If it is, well, it's still pretty promising.

~Mark

On 2/26/19 12:16 AM, Maurizio Cimadamore wrote:
> Could you be experiencing this?
>
> https://github.com/scala/bug/issues/11381
>
> The problem reported by SBT looks the same, and it's JDK 12-related.
>
> Maurizio
>
> On 25/02/2019 21:25, Maurizio Cimadamore wrote:
>> That doesn't look good.
>>
>> I suggest you try to Java-ize your example and try again. If that 
>> works, then we're looking at an issue which could be caused by some 
>> incompatibility between sbt and the Panama JDK (e.g. does sbt support 
>> classfiles of that version number?) or, possibly, some more obscure 
>> bug in the Panama JDK.
>>
>> Maurizio
>>
>> On 25/02/2019 20:51, Mark Hammons wrote:
>>> I gave it a shot, and changed my setProperty to a getProperty to 
>>> make sure the debug flag was set and still no helpful debug 
>>> information. This gets printed out whenever I run sbt, so maybe it's 
>>> related?
>>>
>>> error: error while loading String, class file 
>>> '/modules/java.base/java/lang/String.class' is broken
>>> (class java.lang.NullPointerException/null)
>>>
>>> On 2/25/19 3:11 PM, Mark Hammons wrote:
>>>> I will do this when I return home tonight.
>>>>
>>>> On 25/02/2019 12:37, Maurizio Cimadamore wrote:
>>>>>
>>>>> On 25/02/2019 00:40, Mark Hammons wrote:
>>>>>> So at least I know the command is failing, but still no output as 
>>>>>> to why. 
>>>>>
>>>>> Error code 4 means jextract failed with some runtime exception - 
>>>>> but the "jextract.debug" option should print the exception message:
>>>>>
>>>>> ```
>>>>> ctx.err.println(re.getMessage());
>>>>> if (Main.DEBUG) {
>>>>>   re.printStackTrace(ctx.err);
>>>>> }
>>>>> return RUNTIME_ERROR;
>>>>> ```
>>>>>
>>>>> I'm not sure setting the property the way you do is the right way 
>>>>> to go. The property is cached in a static field:
>>>>>
>>>>> ```
>>>>> public static final boolean DEBUG = 
>>>>> Boolean.getBoolean("jextract.debug");
>>>>> ```
>>>>>
>>>>> So you are basically depending on the order in which classes are 
>>>>> loaded/initialized here. Can you try to pass -Djextract.debug to 
>>>>> the VM directly instead of doing it from the program? (not 100% 
>>>>> sure that is why you are getting no output, but let's try to 
>>>>> remove as many accidental factors as possible).
>>>>>
>>>>>
>>>>> Maurizio
>>>>>
>>>>>
>>>>>
>>>>