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

[Mark Hammons]

I'm very interested. I'll watch the youtube video tomorrow, but I'm a 
little surprised I missed it cause I thought I had caught all the Devoxx 
talks, and of the upcoming technologies like loom, metropolis, panama, 
and valhalla, I'm most interested in panama (though I'm dying for all of 
them to be honest).

I'm going to finish the Wayland McWayface part 2 and part 3 demos by the 
end of this week, and hopefully the new release of panama with the fix 
for struct bytecode will be available then so I can rip out the java 
workarounds I have in place to let scala access the anonymous structs. 
After that I might try porting sway (which the wlroots library was 
designed for, and whose authors wrote the tutorials I'm implementing) to 
the jvm.

~Mark

On 2/26/19 10:18 PM, Maurizio Cimadamore wrote:
>
> On 26/02/2019 19:20, Mark Hammons wrote:
>> 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.
>
> Heh - your assumption is correct, upcalls is the least optimized code 
> path (if you are on Windows, downcalls aren't great either - but I 
> think you're on Linux, given the header you're working on :-)).
>
> See this:
>
> https://youtu.be/cfxBrYud9KM?t=1759
>
> Where I talk a bit about the current status of Panama performance and 
> possible further developments; in case you are interested, since I 
> gave that talk, we actually have a branch with all the performance 
> work - called "foreign+linkToNative", so that could be a way to get an 
> idea of what's coming.
>
> Maurizio
>
>
>>
>> ~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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>