Hi,
When building SlicerCAT I’m thinking about installing Julia (+miniconda) instead of Slicer’s Python while keeping Slicer+Python tight interaction.
If someone has any thoughts please give an advice.
Hi,
When building SlicerCAT I’m thinking about installing Julia (+miniconda) instead of Slicer’s Python while keeping Slicer+Python tight interaction.
If someone has any thoughts please give an advice.
I don’t think anybody has tried to interface Slicer with Julia. We are pretty happy with the vast amount of packages available for Python and we can implement all performance-critical code in C++.
A couple of years ago we tried to build Slicer against miniconda Python libraries and it seemed to work, but since we can use pip
in Slicer now, there is not much motivation in trying to use conda.
I decided not to use miniconda so far but I’m going to use Julia.
To install Julia I’m going to use crossplatform python module Jill.py. It will install Julia in some dir inside build tree like C:/C/d/julia-1.6
. Then I need to add Julia to CPack to make installation available for usual user. I can see that Slicer handles CPack modules via SlicerBlockInstallMyLib.cmake
and SlicerExtensionCPack.cmake
but there is quite a lot of code and for now I can’t understand how can I apply the same Slicer CPackaging style to Julia (maybe because it is time to go to sleep).
But anyway, if somebody has instruction please give me an advice.
You actually already have several options to run Julia scripts directly from Slicer as CLI modules.
You can implement CLI modules in any language. For now, you need to create an executable (sh, bat, py, exe,…) launcher the starts your script with Julia. But with a small change in Slicer core, you could implement direct Julia launching capability the same way as Python CLIs. See example here:
If Julia.exe startup time is too slow then you can do the same that we did for Matlab. We implemented a very simple TCP server in Matlab that receives commands from Slicer executes them, and sends back to result to Slicer. See details here:
Slicer also supports the Jupyter kernel protocol, so you can access Slicer features via this interface.
If you want to run Julia inside the Slicer process then it should be possible, too, but much more complicated. Python can be either extended (you load your libraries into Python and let Python execute it) or Python can be embedded (your application instantiates and manages a Python interpreter). We embed Python into Slicer so that we have better control over the application and to keep Python an optional component. Probably the simplest way to integrate Julia in the Slicer application is to embed Julia - if it has this option. You may be able to extend Julia with Slicer, this is how TCL integration worked years ago. For a few years, Slicer extended TCL and embedded Python. You can go back in the version history of Slicer and see how it was implemented.
@lassoan thank you very much for consulting me.
Even I’m not an experienced Julia user I can see that Julia has tight integration with python. Julia can call python via PyCall and python is able to call Julia via PyJulia. So for now I mostly rely on this python-julia communication. I think the problem will arise when I start integrating Julia scripts and I will comeback to this thread.
Didn’t know about this file, thank you.
It seems this is not an issue anymore but here is why started this topic:
I bundle julia programming language along with SlicerCAT and I wasn’t able to build a package (pyjulia) because its dependency (PyCall) used to be built against python.exe
while pyjulia determined that it is invoked from PythonSlicer.exe
(pyjulia used to raise an exception about this).
But as I figured out later the problem was within Slicer build tree python library is copied to Slicer-build
and the inconsistency was invoked by that: PyCall links to python-install/bin/python39.dll
and pyjulia links to Slicer-build/bin/python39.dll
.
This is not an issue when SlicerCAT is installed (tested).
PyCall links to
python-install/bin/python39.dll
and pyjulia links toSlicer-build/bin/python39.dll
.
Technically, the linking is done at build-time against python-install/libs/python39.lib
.
If you share a link to your custom application, we should be able to provide hints on how to set the launcher settings to ensure the proper dynamic libraries are resolved (by for example setting relevant launcher settings).
I created CTK launcher around julia programming lang and I have set there env variables to resolve mentionned issue.
P.S. yesterday I made the repo private as I’m not sure about the future of the project. It is an enthusiastic project but I spend too much time on this without any interest in the sense of sponsorship so far.