Closed twadleigh closed 5 years ago
As the marshaling code copied over from MATLAB.jl
evolves, the common ground between it and mexjulia
is shrinking. It may be a bit before we can assess to what extent this is still a useful thing to do.
I think it would also be nice to just rely on MATLAB
to take care of the functionality needed? Looking over some of the files in mexjulia
it looks like you based them on an older fork of MATLAB
, which had many issues with segfaulting.
@musm, I will check out the recent patches on MATLAB.jl
and apply them. However, mexjulia
currently relies on patches in the mxarray
code that don't make sense in the MATLAB.jl
context.
For instance, one very invasive change that had to be made for mexjulia
was the elimination of the own
field. In the mexjulia
context, MATLAB deletes the memory for unused objects itself when the mex function returns. To let Julia participate at all in the memory management of MxArray
s will require careful object tracking and proper scoping constructs. For now, it leaves it all to MATLAB.
MxArray( ..., false)
would disable the own
and let you manage it without having Julia call a finalizer.
https://github.com/JuliaInterop/MATLAB.jl/blob/master/src/mxarray.jl#L7
But perhaps that is not as sophisticated as you require.
The story gets more complicated, for instance, when you allow the user to make values persist across calls to mexjulia
via mexMakeArrayPersistent
. To make matters worse, mexMakeArrayPersistent
makes values that can't be passed back to MATLAB (without a copy). Managing both scoped and persistent values in a user-friendly way will require a lot of machinery that doesn't apply to the MATLAB.jl
context.
Probably called
MxArrays
orMxBase
.