The Julia programming language is getting a reputation for being easily learned, fast in execution, and adaptable to number crunching. At the same time, the developers have been focusing on developing the language in a non-RPM environment. So as we explore this new territory we openSUSE rpm users are pulled in by the promise of faster processing, but need to be careful since things might not always turn out as expected.
My first steps reassure me that basically Julia works in openSUSE Leap 42.1, although it did not work "out of the box". The following are some notes to file on the path I took to get things going. My goal here is to have a Python-like environment which can act as a basic processing utility, calling this and that function as required including shell utilities, but with the added benefit of a compiled result and extended number processing capability.
The openSUSE Linux repositories offer a precompiled version of Julia, and this was easy to install. Very quickly I was able to get this version running in the command line interface and was able to add two to one and get three, and initialize a variable to an array, very much like Python without having to pull in libraries such as numpy. It was a good start; it is a bit like Matlab/Octave in that respect.
The first problem arose when I tried to use matplotlib. I was able to install the package PyPlot and set up a plot example, the plot would generate a PyObject, but would not display on the monitor even with a forced show request. The solution to this was to change the default backend for matplotlib in
/usr/lib64/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc to "backend : TkAgg". After this change, plots displayed fine from the command line interface.
The second problem was that during the installation of some packages something would initiate a call to the Yast package manager asking for root permission to do something. But it did not say what it wanted. On an experimental machine I allowed it to continue, but the list of things it wanted to do was never displayed. Dismissing the process seemed to make no difference, but probably something in the background is incomplete.
This points to the fact that Julia currently supports the "apt" family of package management, but not the zypper type repositories. The Julia developers may get around to adding this capability soon so it might be as well to keep a cutting edge version going by updating frequently from the git repository.
An integrated development environment is a handy tool, allowing edits and running, stopping and other script execution controls. IJulia works quite well (it does suffer from the root permission issue mentioned above, but runs nevertheless) but the notebook format, while it is great as a record keeper and tutorial support is not quite what I am looking for.
Still it is early days yet in the history of Julia, so while I am waiting for a better option, using the gedit gnome editor set for Julia parsing together with the Julia REPL (command line interface) running in a terminal window works pretty well so far. My setup is as follows: using the left half of the screen for the REPL terminal window, call julia with the -q option to avoid the banner, then the right hand side of the screen is divided into upper half for the pyplot graphs, and the lower half for gedit to edit the content of *.jl scripts. Then in the REPL issue the command
include("test1.jl") for example to run the script and produce the required output. Even better is a multiple screen situation with windows open where you will.
In a full IDE setup, the editor will be help-aware; in this case Gedit is not help aware, but the Julia REPL is. At the time of writing, the development version of Julia is not dot-aware, so the code
plt.clf() for example, to clear a figure, has to be submitted as
On the first call to any packages, expect Julia to be slow as it recompiles stale Julia files, then much faster in subsequent runs.