Closed rcaudy closed 2 years ago
Your local python version shouldn't matter - it should be running the tests inside docker.
I'm more worried why others aren't seeing this same error.
I can do this with groovy
if I intentionally give the wrong type as input:
// Setup:
t=io.deephaven.csv.CsvTools.readCsv("/Users/rcaudy/dev/deephaven/community/current/core/py/server/tests/data/test_table.csv")
pt=t.partitionBy("c","e")
// This works:
c=pt.constituentFor(917, 167)
// This does not:
c=pt.constituentFor((short)917, 167)
So, one answer here might be to make MatchFilter
more permissive about compatible numeric types, and downcast/upcast accordingly.
Alternatively, PartitionedTableImpl.constituentFor
could do that, or the Python wrapper could try to adjust it.
Meanwhile, we have no idea why this is breaking sometimes vs other times.
Interestingly, without my validation patch, short
is fine from Groovy.
Not that interesting, it intentionally works that way:
public static int[] getUnboxedIntArray(Object[] boxedArray) {
final int[] result = new int[boxedArray.length];
for (int i = 0; i < result.length; i++) {
result[i] = (boxedArray[i] != null ? (((Number) boxedArray[i]).intValue()) : NULL_INT);
}
return result;
}
So now we need to understand why Python is causing issues in some cases that we would not expect.
I did some println
style debugging in Python and Java.
This output is a little bit out of order, but Python thinks it is passing 917 and 167, which Java is getting as a Short
917 and a Byte
-89:
[class java.lang.Short, class java.lang.Byte]
[917, -89]
[917]
[917]
[-89]
[-89]
test_get_constituent (tests.test_partitioned_table.PartitionedTableTestCase) ... FAIL (0.008s)
before: [917, 167]
after: (917, 167)
This just looks like bad truncation to byte.
This seems to pass:
Index: py/jpy/src/main/c/jpy_jtype.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/py/jpy/src/main/c/jpy_jtype.c b/py/jpy/src/main/c/jpy_jtype.c
--- a/py/jpy/src/main/c/jpy_jtype.c (revision d7ec73b94db205df5a559a8ad881bb23ac20ac64)
+++ b/py/jpy/src/main/c/jpy_jtype.c (date 1654549792772)
@@ -448,14 +448,16 @@
int JType_CreateJavaNumberFromPythonInt(JNIEnv* jenv, JPy_JType* type, PyObject* pyArg, jobject* objectRef)
{
jvalue value;
- char b;
+ signed char b;
short s;
long i;
long long j;
j = JPy_AS_JLONG(pyArg);
i = (int) j;
s = (short) j;
- b = (char) j;
+ b = (signed char) j;
+
+ fprintf(stderr, "j%d, i%d, s%d, b%d\n", j, i, s, b);
if (i != j) {
value.j = j;
Bug Description:
There is a bug in
test_partitioned_table.py
fortest_get_constituent
. Excerpted from results of./gradlew :Integrations:test-py-deephaven
:Adding some code to the Java side highlights that this is an issue with type conversions (Python types not matching the expected Java types). There is an additional mystery of why it fails for me, but not CI or @jmao-denver .
Version Information:
Git SHA:
ef8560504bd9b650a8e0717aed8aad93a74261d3
(current head ofdeephaven/deephaven-core:main
)Java Patch:
The following Java patch makes the issue evident:
More Revealing Error:
With that applied, the error becomes:
This shows pretty convincingly that the issue is type conversion (or the lack thereof).