Add Jassoc API to directly associate a name to A #22
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.
Abstract
This PR proposes a new DLL API,
Jassoc
, which allows binding an object ofA
directly to a name in J.Motivation
J ships
j.dll
andlibj.so
with 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, becauseJSetM
doesn't allow it. This is different fromJGetM
which does allow accessing arrays ofA
from the DLL interface.In order to exchange Python's
tuple
ornp.array
ofObject
with J, we need to put arrays ofA
into J using the non-COM, dynamic library interface.DIscussion
One option might be adding this functionality to the existing
JSetM
. ButJSetM
assumes that we are not copying data fromA
back to J. Meanwhile,A
.A
in 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
A
on 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_t
ordouble
, becauseJSetM
won't be able to copy from a contiguous memory ofint32_t
orfloat
. But if we can assignA
back to J, we can formA
first, 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.