You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I ran the tests with localbuild.py, tests/v2/test_1477-generator-entry-type-as-rvec.py::test_BitMaskedArray_NumpyArray attempted to compile AwkwardArrayDataSource_8748206908428 a second time. The test failed because Cling complained at awkward/_v2/_connect/rdataframe/to_rdataframe.py:288: AssertionError.
@ianna, do you have any idea how a class might accidentally get redefined? I'm a little stumped as to why it happened on my machine and not on yours (MacOS vs Linux?) and not in the tests (pip install vs localbuild.py?). I manually ran the tests, just to check it.
Could it be that the hash is missing some value that it should depend on? Like, is the hash calculation for AwkwardArrayDataSource going recursively through all the things it depends on, or is it only checking the top level? If so, then just putting a check before compile to avoid recompiling a previously existing AwkwardArrayDataSource would be the wrong thing to do because that would prevent different data sources from having different code, and the result would be confusing (probably segfaults, as they try to cast the data to the wrong types). If, on the other hand, the second class declaration really is the same code, then it should be prevented from being recompiled.
Actually, I'm no longer stumped: it's an intermittent problem: running several times, I haven't reproduced it. I do not believe that this was a hash collision (that I happened to get with probability 5.421010862427522e-20). Also, it's a rather low number to be a 64-bit hash: 8748206908428 << 18446744073709551615. Are the hashes being calculated correctly?
Since this is not a reproducible bug, the only thing you can do is scan the code carefully, looking for any state that the AwkwardArrayDataSource depends on that might be missing from the hash calculation. If you don't see any potential issues, then you can close this bug report, at least until we see it again.
The text was updated successfully, but these errors were encountered:
Version of Awkward Array
HEAD
Description and code to reproduce
When I ran the tests with
localbuild.py
,tests/v2/test_1477-generator-entry-type-as-rvec.py::test_BitMaskedArray_NumpyArray
attempted to compileAwkwardArrayDataSource_8748206908428
a second time. The test failed because Cling complained atawkward/_v2/_connect/rdataframe/to_rdataframe.py:288: AssertionError
.Full test output
@ianna, do you have any idea how a class might accidentally get redefined? I'm a little stumped as to why it happened on my machine and not on yours (MacOS vs Linux?) and not in the tests (pip install vs
localbuild.py
?). I manually ran the tests, just to check it.Could it be that the
hash
is missing some value that it should depend on? Like, is thehash
calculation forAwkwardArrayDataSource
going recursively through all the things it depends on, or is it only checking the top level? If so, then just putting a check beforecompile
to avoid recompiling a previously existingAwkwardArrayDataSource
would be the wrong thing to do because that would prevent different data sources from having different code, and the result would be confusing (probably segfaults, as they try to cast the data to the wrong types). If, on the other hand, the second class declaration really is the same code, then it should be prevented from being recompiled.Actually, I'm no longer stumped: it's an intermittent problem: running several times, I haven't reproduced it. I do not believe that this was a hash collision (that I happened to get with probability
5.421010862427522e-20
). Also, it's a rather low number to be a 64-bit hash:8748206908428 << 18446744073709551615
. Are the hashes being calculated correctly?Since this is not a reproducible bug, the only thing you can do is scan the code carefully, looking for any state that the AwkwardArrayDataSource depends on that might be missing from the hash calculation. If you don't see any potential issues, then you can close this bug report, at least until we see it again.
The text was updated successfully, but these errors were encountered: