Java Values are displayed differently in the Chrome Devtools debugger #7890
Comments
Yes, Enso doesn't convert non-primitive values until they need to be converted.
No. The general rule is to convert values as late as possible.
There is a concept of a view |
|
Pavel Marek reports a new STANDUP for today (2024-11-11): Progress: - Assisting Hubert with JPMS-related settings.
|
|
One of my first tasks in Enso was to handle dates, times and datetimes interop properly. That was done by converting the values to Enso before method invocation:
|
@JaroslavTulach That does not seem right. For a primitive @Test // Put this test inside MetaObjectTest.java
public void myTest() {
var primNum = ctx.asValue((int) 5432);
assertThat(primNum.fitsInInt(), is(true));
assertThat(primNum.getMetaObject(), is(notNullValue()));
}This test passes. So host language clearly assigns meta objects to primitive values. Do you think guest languages should have a different contract? |
|
Moreover, the current state of Enso primitive values is as follows (this test passes on develop): @Test
public void myTest() {
var g = ValuesGenerator.create(ctx, ValuesGenerator.Language.ENSO);
g.numbers()
.stream()
.filter(Value::fitsInLong)
.forEach(num -> {
assertThat(num + " Enso primitive long numbers don't have meta object",
num.getMetaObject(),
is(nullValue()));
});
g.numbers()
.stream()
.filter(num -> !num.fitsInLong() && !num.fitsInDouble() && num.fitsInBigInteger())
.forEach(num -> {
assertThat(num + " Enso big integer numbers have meta object",
num.getMetaObject(),
is(notNullValue()));
});
g.booleans()
.forEach(bool -> {
assertThat(bool + " Enso primitive booleans have meta object",
bool.getMetaObject(),
is(notNullValue()));
});
}In other words. Primitive numbers (those that fit inside long) don't have a meta object, but big integers have. Moreover, primitive booleans have meta objects. This is confusing and not consistent. I assume that we should ensure that all the primitive Enso values have meta objects. Right? |
|
Host primitive boolean also has meta object: @Test
public void javaBoolHasMeta() {
var b = ctx.asValue(true);
assertThat(b.isBoolean(), is(true));
assertThat(b.getMetaObject(), is(notNullValue()));
} |
|
The same is true for js and python - their primitive values have meta objects: (the following test passes on develop as well) @Test
public void guestBoolHasMeta() {
var jsBool = ctx.eval("js", "true");
var pyBool = ctx.eval("python", "True");
assertThat(jsBool.isBoolean(), is(true));
assertThat(pyBool.isBoolean(), is(true));
assertThat(jsBool.getMetaObject(), is(notNullValue()));
assertThat(pyBool.getMetaObject(), is(notNullValue()));
}
@Test
public void guestIntHasMeta() {
var jsInt = ctx.eval("js", "42");
var pyInt = ctx.eval("python", "42");
assertThat(jsInt.isNumber(), is(true));
assertThat(pyInt.isNumber(), is(true));
assertThat(jsInt.getMetaObject(), is(notNullValue()));
assertThat(pyInt.getMetaObject(), is(notNullValue()));
} |
|
Pavel Marek reports a new STANDUP for today (2024-11-12): Progress: - Found out violations of Truffle contracts (on develop):
|
|
Pavel Marek reports a new STANDUP for today (2024-11-13): Progress: - Fixing
|
No, if ...
...the TCK is OK with that, then having ...
... consistency is important. |
I am not sure what you mean by inspired, but PythonAbstractObject has to be |
Yes, but how else would you ensure that hasLanguage and getLanguage messages are implemented for every object? |
I would write a test that uses
I see. I am checking with Christian Humer, but I guess you are right. |
Consider the following program:
run it with
--inspectand set the breakpoint atIO.println d_java.We will see the following Scope:
We can see that the value coming from Java is displayed differently than the one from Enso, even though both are a
Date. It is probably because Enso did not manage yet to perform its polyglot conversions. Shall they be performed before displaying the object?Another issue can be seen when we interact with the REPL:
We can see that values coming from polyglot calls (e.g.
next) behave Java-like and the ones that are 'correctly' displayed come from builtin methods (e.g.Date_Time.date) which ensure the Enso polyglot conversion happens.I'm not sure if this is a bug - although ideally the behaviour of the Debugger should be consistent regardless of where the value is coming from.
What may be especially misleading is that the Java values display all kinds of Java methods they have:
But these methods won't work, because of how the Enso interop works (once we do a call, we do the polyglot conversion and it's no longer a Java
LocalDatebut anEnsoDate):That is quite misleading, so I think ideally we should fix it and show the value for what it is to the user - an Enso date. I'm not sure how big of a priority this is though.
The text was updated successfully, but these errors were encountered: