Enso builtins don't expose Enso methods

[JaroslavTulach]

Quite surprisingly Enso builtins don't expose Enso methods to org.graalvm.polyglot.Value. That results in quite surprising situations:

• cannot call Ref.get: https://github.com/enso-org/enso/pull/11577/files#r1848224116
• cannot call File.path on EnsoFile
• cannot call to_text on Vector - discovered while working on Warnings displayed after main exit do not use defined to_text #11569

Looks like Enso builtin types do not expose their Enso methods to org.graalvm.polyglot.Value. Let's write ValuesGenerator based test and verify all Enso builtins expose their (public) Enso methods properly.

[Akirathan]

The following test obviously fails:

enso/engine/runtime-integration-tests/src/test/java/org/enso/interpreter/test/builtins/BuiltinsExposeMethodsTest.java

Lines 41 to 51 in f9a00c6

	@Test
	public void booleanExportsMethods() {
	var src = """
	import Standard.Base.Runtime.Ref.Ref
	main =
	Ref.new 0
	""";
	var ref = ContextUtils.evalModule(ctx, src);
	assertThat("'get' member is invocable",
	ref.canInvokeMember("get"), is(true));
	}

ref.canInvokeMember("get") sends isMemberInvocable("get") message to the interop library implementation of Ref. Ref does not expose such message and, therefore, fails.

Interop protocol for Atom changed recently in #11217 and its getMembers message implementation says in the docs:

enso/engine/runtime/src/main/java/org/enso/interpreter/runtime/data/atom/Atom.java

Lines 156 to 160 in 04075c5

	/**
	* Returns list of fields of the Atom. If {@code includeInternal} is true, all methods, including
	* project-private, are included. Fields are returned as filed getters, i.e., methods. Only fields
	* for the constructor that was used to construct this atom are returned.
	*/

The obvious solution for this issue is to make the interop protocol for every builtin consistent with the protocol of Atom. More specifically, make these interop messages consistent:

• getMembers
• hasMembers
• isMemberReadable
• isMemberInvocable
• isMemberInternal
• getMetaObject
• hasMetaObject

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-11-29):

Progress: - Add a test that collects all the builtin objects, and checks that they expose Enso methods (coverage almost 100%)

• Let's first do a small refactoring - Refactor runtime-integration-tests - move some tests to more dedicated packages #11720
• Review of Enhance Managed_Resource to allow implementation of in-memory caches #11577 and Intersection types & type checks #11600 It should be finished by 2024-12-04.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-04):

Progress: - Increased test coverage - also try to invoke some methods on the builtin types.

• Every builtin type extends BuiltinObject.
  • Enforced during annotation processing.
• PR ready for review. It should be finished by 2024-12-04.

[enso-bot]

Pavel Marek reports a new STANDUP for the provided date (2024-12-09):

Progress: - Encountered a regression in not functional benchmarks - #11808

• Helping Dmitry with Scala, and other dependencies, version bumps
• Creating my so far biggest Enso workflow for analysing our benchmarks. What a great experience! It should be finished by 2024-12-11.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-11):

Progress: - Found the reason why tests are failing and created a minimal reproducer

• Turns out this is a blocker - Refactor Storage.vectorizedOrFallbackBinaryMap to accept Value instea… #11835 (comment)
• Investigating how we can accept Value in stdlib Java methods without making major changes.
• Quickfix for failing Benchmark Upload GH action at Fix benchmarks upload GH Action #11842
  • Docs and style improvements for https://github.com/enso-org/engine-benchmark-results It should be finished by 2024-12-11.

GitHub

GitHub - enso-org/engine-benchmark-results: https://enso-org.github.io/engine-benchmark-results/

https://enso-org.github.io/engine-benchmark-results/ - enso-org/engine-benchmark-results

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-12):

Progress: - Struggling with the blocker #11835

• Seems like this would require non-trivial changes in Java methods in stdlibs that can be called from Enso
• Alternative: builtin objects do not have members, but their types have
  • Type exports hasMembers method and invokeMember.
• Rewriting the PR to the new approach - Builtins expose Enso methods #11687 (comment) It should be finished by 2024-12-17.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-13):

Progress: - Review of #11850

• Separate PR - Every builtin type has a common super class #11861
  • Still same failures? It should be finished by 2024-12-17.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-16):

Progress: - Found out the bug that causes Invalid polyglot layer sharing assertion errors - #11861 (comment)

• Tests are green, but still need to investigate the invalid sharing error.
• Started investigation on where is the InvalidSharingAssertionError coming from - Every builtin type has a common super class #11861 (review)
  • Should every EnsoContext has a separate instance of Builtins, or can they be shared?
  • How does this relate to the static field Builtins.loadedBuiltinConstructors? It should be finished by 2024-12-17.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-17):

Progress: - Adding debugging info when current context is different than the one in the cached value.

• Also store stack traces. It should be finished by 2024-12-17.

[JaroslavTulach]

• Should every EnsoContext has a separate instance of Builtins, or can they be shared?

No, they cannot be shared. Each EnsoContext should currently have its own instance of Builtins.

• How does this relate to the static field Builtins.loadedBuiltinConstructors?

Right, how? I'd like to know the answer too. Preferably without me using the debugger.

[Akirathan]

• Should every EnsoContext has a separate instance of Builtins, or can they be shared?

No, they cannot be shared. Each EnsoContext should currently have its own instance of Builtins.

• How does this relate to the static field Builtins.loadedBuiltinConstructors?

Right, how? I'd like to know the answer too. Preferably without me using the debugger.

@JaroslavTulach Answer provided in #11861 (comment)

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-23):

Progress: - Integrate some review feedback.

• Tests are green, benchmarks scheduled - Every builtin type has a common super class #11861 (comment) It should be finished by 2024-12-27.