This is surely a naive question, but: how hard would it be to embed julia
inside a C/C++ application? Choose one: medium, hard, very hard, very very
hard, or downright impossible. :-)
I took an idle gander at the code in julia_init (init.c), and I was wondering
if in some miraculous world one could snip out some of those lines, and then
have some mechanism for feeding commands to julia and receiving return values.
Two applications occur to me:
1. I could call julia from Matlab. It would be sort of like a MEX syntax,
except that over time I'd be building up a library of julia code that, once
julia has everything I need, would make it easier to switch to full-julia.
(Right now julia is a "side project" indepdent of my real work.)
2. GUIs. Mike, I only dimly understand you current work on the graphics
system, but it seems you're writing native-julia plotting. This is great;
within Matlab, I've long wished for the ability to tweak their default
plotting capabilities, and you're setting up just such a system. From peeking
at your code, this seems to involve lots of ccalls to draw on a cairo canvas.
What about communication in the other direction, from the canvas to julia? Is
there a clear mechanism for setting up callbacks from graphical objects back
to julia functions? If the answer is "no," then I wonder if embedding julia
inside a larger Qt/GTK/whatever GUI would make that more straightforward?
Since I know nothing about these issues, it would be nice to hear back from
core developers, even if the answer is "not without an incredible amount of
work."
Best,
--Tim
Jameson is right, we need some more hooks like getting the list of
defined symbols from a module.
On Tue, Mar 20, 2012 at 9:24 AM, Tim Holy <tim....@gmail.com> wrote:
Add them to src/julia.expmap
-Keno
I think a better interface would be to write a C function that returns
a cell array of the symbols bound in a given Module (jl_module_t*).
That will be much more forwards-compatible, plus you don't have to
check isbound() on everything.