Run Standard.Google in dual JVM mode
#14040
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JaroslavTulach
added
the
CI: No changelog needed
corepack pnpm i
corepack pnpm compile
corepack pnpm dev:gui
|
5 tasks
|
I have all the setup to execute the tests in regular JVM mode: now onto running the same tests in dual JVM mode. With bc03db6 there is eleven remaining failures: we are on track to get the dual JVM mode working for |
JaroslavTulach
added
the
CI: Clean build required
… JVMs have the same ID
JaroslavTulach
commented
Oct 7, 2025
| var emptySheetError = emptySheetType.invokeMember("Error"); | ||
| var errorType = EnsoMeta.getType("Standard.Base.Error", "Error"); | ||
| var error = errorType.invokeMember("throw", emptySheetError); | ||
| throw error.throwException(); |
There was a problem hiding this comment.
- cdbf8fb is a solution to dual exceptions problem, @AdRiley
- rather than throwing Java exception and then trying to convert it to
Empty_Sheet.Error - let's directly throw
Empty_Sheet.Error! - the
getSheetRangemethod returnsTable- as such we need to throw it asPanic(henceerror.throwException()- otherwise just
return error;to propagate the value as (dataflow)Error
- otherwise just
- because we throw
Panicwe havePanic.recoverin the Enso code - if we returned (dataflow)
Error- we could delete the Enso conversion code completely!
There was a problem hiding this comment.
- we can go even further with this approach, @jdunkerley
- if we just
return error;then there is no need to do anything special on the Enso side - as de343f3 illustrates, it is possible to remove
Empty_Sheet.handle_java_exception - the only drawback of the de343f3 is the change of function return type to
Object- we need to return either
TableorValueandObjectis the only common superclass
- we need to return either
- the
throw error.throwException()solution workarounds this by returning via an exception (at the cost of necessary handler on the Enso side)
3 tasks
|
Right now we have:
Other than that we are ready to move on. Heuréka! |
JaroslavTulach
commented
Oct 8, 2025
| error!("Current API vs Old API: {}", err); | ||
| error!("If you wish to overwrite the current API in the directory {}, run the following command {}, | ||
| error!("If you wish to overwrite the current API in the directory {}, run the following command | ||
| sbt \"runEngineDistribution --no-ir-caches --docs=api --in-project {}\" |
There was a problem hiding this comment.
This change, @AdRiley, @GregoryTravis, @jdunkerley, will print:
index 8b63b3d24d..f2c90e184d 100644
--- home/devel/NetBeansProjects/enso/enso/distribution/lib/Standard/Table/0.0.0-dev/docs/api/Errors.md
+++ home/devel/NetBeansProjects/enso/enso/built-distribution/enso-engine-2025.3.1-dev-linux-amd64/enso-2025.3.1-dev/lib/Standard/Table/2025.3.1-dev/docs/api/Errors.md
@@ -43,7 +43,7 @@
- to_display_text self -> Standard.Base.Any.Any
- type Empty_Sheet
- Error
- - handle_java_exception -> Standard.Base.Any.Any
+ - handle_java_exception ~action:Standard.Base.Any.Any -> Standard.Base.Any.Any
- to_display_text self -> Standard.Base.Any.Any
- type Existing_Column
- Error column_name:Standard.Base.Any.Any
ERROR main_internal: enso_build::engine::context: If you wish to overwrite the current API in the directory distribution/lib/Standard/Table/0.0.0-dev/docs/api, run the following command
sbt "runEngineDistribution --no-ir-caches --docs=api --in-project distribution/lib/Standard/Table/0.0.0-dev"
and commit the modified files
ERROR main_internal: enso_build_cli: error=API check failed for library Standard.Table
INFO main_internal: enso_build_cli: close
Error: API check failed for library Standard.Table
in case of API check failure. Which I can then directly copy and run the regenerator:
enso$ sbt "runEngineDistribution --no-ir-caches --docs=api --in-project distribution/lib/Standard/Table/0.0.0-dev"Please note the --no-ir-caches flag added for your convenience as the actionable applied after recent complains.
JaroslavTulach
force-pushed
the
wip/jtulach/DualGoogle
branch
from
c1f5e6e to
53f1b1a
Compare
JaroslavTulach
commented
Oct 8, 2025
| } | ||
|
|
||
| public Table getSheetRange( | ||
| public Object getSheetRange( |
There was a problem hiding this comment.
- need a common super type of
TableandValuebecause of returning Error.throw
JaroslavTulach
requested review from
GregoryTravis and
jdunkerley
as code owners
JaroslavTulach
changed the title
Standard.Google in dual JVM mode
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-10-08): Progress: .
|
There is now a last remaining failure: it should probably be mitigated by using the same technique as in 51366e2 |
I believe we are ready! @AdRiley please review and verify my claims. Thank you. |
JaroslavTulach
commented
Oct 9, 2025
| raw_table = self.internal_java_table | ||
| if raw_table.is_a table_class then raw_table else | ||
| # coming from the other JVM and deserves conversion | ||
| new_columns = raw_table.getColumns.map c-> column_class.new c.getName c.getStorage |
There was a problem hiding this comment.
- using same technique as in 51366e2
- e.g. converting via
ColumnStorage(which is an interface) - and creating new
TableforColumn(of the right class) delegating to proxy of the interface
JaroslavTulach
commented
Oct 9, 2025
| private static Value getBindings() { | ||
| return Context.getCurrent().getBindings("enso"); | ||
| var ctx = Context.getCurrent(); | ||
| var bindings = ctx.getPolyglotBindings().getMember("ensoBindings"); |
There was a problem hiding this comment.
- With these changes we can now access Enso classes even from dual JVM
JaroslavTulach
commented
Oct 9, 2025
| Convert a Java problem into its Enso equivalent. | ||
| translate_problem p = case p of | ||
| _ : InvalidAggregation -> | ||
| translate_problem p = case p.problemType of |
There was a problem hiding this comment.
Introduction of Problem.problemType() allow us to translate_problem regardless from which JVM it origins
JaroslavTulach
commented
Oct 9, 2025
|
|
||
| ```bash | ||
| enso$ ./run ide build | ||
| enso$ ls ./dist/ide/enso-linux-*.AppImage |
There was a problem hiding this comment.
- this would be very nice to automate, @otulach, @PabloBuchu!
- first of all we need to run the IDE and create the
GoogleSheetcredential via playwright - then we need to execute the
Google_Tests from CLI
Testing Google Sheets is showing an error... |
|
|
Further testing indicates this error only happens in the IDE. If we extend the test to 
and then run from command line. We get back the data from google sheets as we expect 
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-10-09): Progress: .
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-10-10): Progress: .
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-10-11): Progress: .
|
|
Updating the test project to this 
|
Thanks @AdRiley for the testing. Now, we other tasks like #14019 being integrated, let's move this PR on. I am getting following error: 
when trying your code. Obviously, I don't have access to your credentials. But on a general note: How can projects referencing secrets be made transferable between different people? |
JaroslavTulach
commented
Oct 30, 2025
| try { | ||
| polyglotJava = createPolyglotJava(ctx); | ||
| } catch (Throwable t) { | ||
| logger.log(Level.ERROR, "Cannot create polyglotJava", t); |
There was a problem hiding this comment.
- After merging the most recent
developin - and especially Launching ydoc-server together with language-server #13178
- we are now getting
INFO: Initializing OtherJvm support!
SEVERE: Cannot create polyglotJava
java.lang.AssertionError: Error creating JVM: -5
at org.enso.jvm.channel/org.enso.jvm.channel.JVM.initializeEnv(JVM.java:114)
at org.enso.jvm.channel/org.enso.jvm.channel.JVM.env(JVM.java:87)
at org.enso.jvm.channel/org.enso.jvm.channel.Channel.create(Channel.java:161)
at org.enso.jvm.interop/org.enso.jvm.interop.api.OtherJvmClassLoader.createImpl(OtherJvmClassLoader.java:129)
at org.enso.jvm.interop/org.enso.jvm.interop.api.OtherJvmClassLoader.create(OtherJvmClassLoader.java:76)
at org.enso.interpreter.epb.JavaPolyglotNode.create(JavaPolyglotNode.java:21)
at org.enso.interpreter.epb.ForeignEvalNode.parseJava(ForeignEvalNode.java:124)
- when trying to initialize the HotSpot JVM here
- because there already is one HotSpot JVM in the process (created by Launching ydoc-server together with language-server #13178)
- and the documentations says and continues to say it in the JDK 25 as well:
Creation of multiple VMs in a single process is not supported.
- one should probably read the specification more carefully before getting too optimistic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Description
Standard.Googlestd-bitsJava codeChecklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,