More efficient MEX or MEX-like interface

[David Bateman]

Moving to maintainers as requested (sorry got very off topic)

John W. Eaton wrote:
> The proper way to allow linking with non-free plugins is to use an
> exception to the GPL.  However, that means changing the license of
> Octave, and I'm not sure that we can do that given the number of
> contributors and the fact that we have not been collecting copyright
> disclaimers or assignments for some time now (I started out by doing
> that, but then decided to stop in an effort to make development go
> faster, and to attract more contributors).  Also, if we use an
> exception, we must consider how that affects the licensing situation
> with respect to all the dependencies that are linked with Octave.

I think a license exception is out of the question as well for the very 
valid reasons you describe.


> 
> | The current situation 
> | where the freely distributable API to Octave is mex is a bit stupid,
> 
> I'm not sure I would call it the "freely distributable API".  Maybe
> you mean the API that (apparently) allows non-free plugins (since we
> can't really claim that a MEX file was written specifically for
> Octave)?

Yes this is what I mean. Though note I said API and not ABI, since its 
seems obvious that a binary of a mex-file built with Octave becomes 
subject to the GPL and so can not be distributed.

> I guess these are two separate issues: (1) distribution of binary MEX
> files for Octave (2) using binary MEX files built for Matlab with
> Octave.

Use of matlab binaries I couldn't really care about, and I think 
distributions of Octave mex-binaries are probably subject to the GPL, 
though if they weren't that would be a plus.

>  
> | though its the choice that FreeMat made and if Octave chooses to go that 
> | way, then optimizing that interface becomes a priority.
> 
> One of the primary sources of efficiency problems for the MEX
> interface is the difference in the way Octave handles data
> internally.  For example, Octave stores complex data in arrays of
> pairs of real and imaginary values while Matlab stores them in
> separate real and imaginary arrays.  Since the MEX interface allows
> direct access to the pointers to the real and imaginary arrays,
> passing data in that arrangement forces a copy in Octave but not in
> Matlab.  So if we want better effiency with this interface, I think we
> have to rewrite much of the internals of Octave to store complex data
> differently.

I thought that it some cases there were additional copies of object when 
a pointer was requested even for non complex data due to const/non-const 
issues. I would not suggest altering Octave to have matlabs split 
real/imag parts of matrix values form as that is not C99 compatible and 
we'd just have to but the parts back together when calling external 
libraries.

> OTOH, we could maybe define a similar simplistic interface that
> provides similar capabilities to the MEX interface but that is
> efficient for the internals of Octave, but taht doesn't actually
> expose the internals of Octave.  In that sense, it would just be a
> slightly extended MEX interface.  Could we apply an exception to the
> GPL for this interface?  I'm not sure.

Even just adding an mxGetPz and mxGetComplexData function to the mex 
interface would improve the situation. Though god I hate mex and much 
prefer to write in oct-files...

D.




> 
> In any case, discussions about how best to do this are probably more
> appropriate for the maintainers list.
> 
> jwe