function result = jlcall(varargin)
% result = jlcall('fname', arg1, arg2, ...)
% call a Julia function with arguments from Matlab
if nargin == 0 % demo
task = {'foo', 2, 3}; % demo fun, defined in jsoncall.jl
else
task = varargin;
end
% create pipe and write function and parameter(s) to pipe
pipename = tempname;
pipe = java.io.FileOutputStream(pipename);
pipe.write(uint8(jsonencode(task)));
pipe.close;
% run Julia and read result back
system(sprintf('julia jsoncall.jl %s', unixpath(pipename)))
fid = fopen(pipename, 'r');
c = fread(fid);
result = jsondecode(char(c'));
fclose(fid);
function path_unix = unixpath(path_pc)
%convert path to unix version
path_unix = path_pc;
path_unix(strfind(path_unix,'\'))='/';
# jsoncall.jl
using JSON3 # get JSON3.jl from repository first
function foo(a,b) # demo function
a+b, a*b
end
jsonfile = ARGS[1] # called as > julia jsoncall.jl <json_cmdfile>
io = open(jsonfile, "r") # open IOStream as read/write
data = read(io) # read UTF8 data from stream
close(io) # close stream
cmd = JSON3.read(String(data)) # unpack stream into [fun, farg] array
fun = Symbol(cmd[1]) # first element is Julia function name,
result = @eval $fun(cmd[2:end]...) # others are function arguments
io = open(jsonfile, "w")
write(io, JSON3.write(result)) # (over-)write result back to stream
close(io) # close stream
Open points:
my first use of pipes/streams
output formatting: where Julia outputs a tuple of two, Matlab creates an an nx2 array.
replace json by msgpack for performance, might help with type formatting as well.
In many ways this is a first-timer, so please feel free to improve the code!
The obvious problem with Matlab interoperability is that you can only work/develop/maintain it if you have a (rather expensive) Matlab license. That basically limits your options to
Work on it yourself or try to find other people in the same situation to collaborate with.
Convince some commercial company that there is a solid business case in this area.
Many years ago I could have helped out with 1 but my company has replaced all Matlab use with Julia and Python, so I have no longer a Matlab license available and no interest in the solutions.
I suspect the main social reason that this hasn’t seen more active development is just that most people who move to Julia from Matlab switch 100%, especially since so many Matlab users are in academia where they can just make the full switch any time they want without needing any permission. That was the case for me, anyways. Would be great to have interop though!
You might also see if anyone has thoughts in the #matlabsconders channel on Slack or Zulip – not very active compared to #expytriates or #r-efugees but may have some relevant people subscribed.
DECAES is written in the open-source Julia programming language. Julia and command line interfaces are available through this package.
The examples repository additionally provides a MATLAB interface via the MATLAB function decaes.m.
Disclaimer, I have no first hand knowledge of this area. Just interested and trying to help. Discount accordingly.
I don’t understand the premise of “sneaking” Julia into a company’s software stack. At this stage of its lifecycle, Julia, its package ecosystem and related tooling are mature enough to be evaluated on their own merits: a company may just adopt Julia, or do a pilot project with it, etc. This should be an above-board decision at the appropriate managerial level.
If a project starts migrating to Julia, calling Matlab from Julia and replacing parts gradually may be the best approach, with eg
That said, most of the Matlab to Julia migrations I have seen (in academia) were data-centered: parts of a toolkit would just read and dump results in CSV or HDF5, so migrating a particular piece could be done independently of the rest.
Thanks @Tamas_Papp for asking.
OK, the post title is a teaser, not a statement about Julia’s maturity
We use Matlab a lot for prototyping, then Matlab Coder to go faster, then Matlab mcc to avoid licenses, using individual MCR runtime directories for parallel jobs,…
From some translated code I see Julia speed gains of 10x…100x.
The problem is that we will not be able to change horses immediately.
There is the acceptance problem but also complex legacy Matlab code, e.g. design of experiments management (Matlab-on-top).
So the sneaking would be more on the colleague and operational level.
From this the title of my posting.
Hi there, thanks for mentioning my talk and package! Unfortunately, I would not describe my approach in DECAES.jl as “calling Julia from Matlab”. Rather, @Tamas_Papp has characterized what I have done to a tee:
In DECAES.jl, the inputs to the processing pipeline are simply paths to MRI images on disk, and after some processing, output MRI images are written out to .mat files. DECAES.jl provides a CLI for ease of use outside of Julia, and in particular the Matlab function decaes.m simply calls out to the CLI via a system call from Matlab.
