Run whole test/Base_Tests with NI

[JaroslavTulach]

Pull Request Description

Fixes #10126 by various changes to make more test/Base_Tests pass in the Enso mode.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• [x] All code follows the Java, Rust style guides.
• [x] Test whole test/Base_Tests via ./runner in CI

[JaroslavTulach]

We can run whole ./runner --run test/Base_Tests and not crash now. That's marks the first milestone:

• tests is still something to work on as there is 416 failed tests

after 20f9589 fixes we are down to

• 302 failed tests

after d61e5d2 we have

• 210 failed tests

finally (for today) with 501c07d we are down to

• 60 test failures

[JaroslavTulach]

With cae2521faa the conversion failure:

  - [FAILED] should format correctly [2ms]
               Reason: '123,456,789.87654' did not equal '123.456.789,87654' (at /runner/_work/enso/enso/test/Base_Tests/src/Data/Decimal_Spec.enso:714:13-75).

goes away and we have just 82 failed tests - it is more than yesterday (we have problems converting EnsoInputStream to hosted java.io.InputStream), but it is certainly less than earlier today.

[JaroslavTulach]

we have problems converting EnsoInputStream to hosted java.io.InputStream),

This is a particularly interesting problem.

We want to create something that looks like java.io.InputStream in the engine builtin (that's the engine level Java), we want to let Enso programs access that object as it has all InputStream methods - that's done by EnsoInputStream which extends TruffleObject, implements InteropLibrary and exposes invokeMember message for read & co. This works as well.

However then we want to pass this object into libraries Java level (the parser API expects an InputStream). However that's not the same Java level as the engine! Moreover, in the NI mode those can even be different JVMs - one native image compiled and one hotspot JVM or Espresso! In such a setup: What looks like InputStream on the engine level is just an opaque reference on the libraries level.

Update: Fixed by 0695d1b5be

PS: It worked so far (as implemented by @hubertp) with asGuestObject because both engine and libraries were running in the same JVM - e.g. the InputStream reference was not opaque. But with NI+JVM mode (as outlined in the 3rd party libraries section) we cannot get the parsing working this way.

[JaroslavTulach]

With 0695d1b the XML InputStream issue is fixed and we are down to

• 56 failures - lowest number seen so far
• 40 failures after solving the Charset issue in d03ba23

[JaroslavTulach]

Another day and the test fight goes on:

• down to 30 failures with ec0918f
• down to 26 failures with 6ab352e, but test/Table_Tests seem to be broken
• just 7 failures with cc14d91
• last two tests failing after 4c2089f

It's the final count down!

[JaroslavTulach]

This is a huge step forward. Congratulations on making all the tests pass in such a short time. Will there be a follow-up PR enabling test/Table_Tests as well?

The next step is to implement

• 5298

-e.g. work on support for --jvm option, detection of compiled & 3rd party libraries as described in the #10121 discussion. From a perspective of that task, it is important to have some "3rd party library" (not compiled by NI). Standard.Table can play such a role.