This PR proposes a new DLL API, Jassoc, which allows binding an object of A directly to a name in J.
Motivation
J ships j.dll and libj.so with different capabilities if the former is built with OLECOM. Only in COM interface, J.dll is able to put structural data in J using an array of boxes. In COM, the structural data is a multi-dimensional array of VARIANT. But to the other language bindings, this is not possible, because JSetM doesn't allow it. This is different from JGetM which does allow accessing arrays of A from the DLL interface.
In order to exchange Python's tuple or np.array of Object with J, we need to put arrays of A into J using the non-COM, dynamic library interface.
DIscussion
One option might be adding this functionality to the existing JSetM. But JSetM assumes that we are not copying data from A back to J. Meanwhile,
Processing structural data ends up having recursive calls, and the natural outcome of that call is A.
We don't want to allocate an array of A in a foreign language's heap just for the purpose of fitting into JSetM's interface, because no foreign language can make use of A.
In a word, we want to allocate A on J's heap using Jga, update its content, and give that array a name in J.
Doing so has an extra desired property. In the past, a foreign language must provide data in int64_t or double, because JSetM won't be able to copy from a contiguous memory of int32_t or float. But if we can assign A back to J, we can form A first, and do the copying outside. This copy doesn't need to be memcpy.
Implementation
The patch originates from a change on an older branch that has no j903 multithreaded areas. That change worked well, but the patch in this PR is rebased accordingly and provided as-is. We haven't tested it because J upstream is not CMake-enabled.
Abstract
This PR proposes a new DLL API,
Jassoc, which allows binding an object ofAdirectly to a name in J.Motivation
J ships
j.dllandlibj.sowith different capabilities if the former is built withOLECOM. Only in COM interface, J.dll is able to put structural data in J using an array of boxes. In COM, the structural data is a multi-dimensional array ofVARIANT. But to the other language bindings, this is not possible, becauseJSetMdoesn't allow it. This is different fromJGetMwhich does allow accessing arrays ofAfrom the DLL interface.In order to exchange Python's
tupleornp.arrayofObjectwith J, we need to put arrays ofAinto J using the non-COM, dynamic library interface.DIscussion
One option might be adding this functionality to the existing
JSetM. ButJSetMassumes that we are not copying data fromAback to J. Meanwhile,A.Ain a foreign language's heap just for the purpose of fitting intoJSetM's interface, because no foreign language can make use ofA.In a word, we want to allocate
Aon J's heap usingJga, update its content, and give that array a name in J.Doing so has an extra desired property. In the past, a foreign language must provide data in
int64_tordouble, becauseJSetMwon't be able to copy from a contiguous memory ofint32_torfloat. But if we can assignAback to J, we can formAfirst, and do the copying outside. This copy doesn't need to bememcpy.Implementation
The patch originates from a change on an older branch that has no j903 multithreaded areas. That change worked well, but the patch in this PR is rebased accordingly and provided as-is. We haven't tested it because J upstream is not CMake-enabled.