Julia debugger in Jupyter or Org mode? - julia

I use Julia for academic research and I use literate analysis: text, code, and results live in the same document, and the results in sync with the code (similar to R-markdown, e.g. in RStudio). I can have the files in either Emacs Org-mode with Org-babel or in Jupyter with IJulia. I tried the Gallium debugger and it works well in a shell session, but not in Emacs or Jupyter. In both cases I get:
ERROR: UndefVarError: active_repl not defined
Stacktrace:
[1] RunDebugger(::Array{ASTInterpreter2.JuliaStackFrame,1}) at ~/.julia/v0.6/DebuggerFramework/src/DebuggerFramework.jl:238
Does anyone have a solution to combine literate analysis and code debugging in Julia?

Related

How to run a julia script through terminal

I have a script main.jl which prints a simple "Hello world" string:
println("Hello world!")
However, when trying to run the script through the terminal like this:
julia> main.jl
I get the error:
ERROR: type #main has no field jl
All the information I can find online suggests calling the script like I do to run it. I have assured that I'm in the correct directory - what am I doing wrong?
You are trying to run the file from the Julia REPL (as indicated by the julia> prompt at the beginning of the line). There, you have to include the file as #AndreWildberg mentions. This will run the commands from the file as if you had typed them into the REPL.
The information you found online might have been about running Julia from "normal" terminal, aka a console shell like bash on Linux. There, running julia main.jl will run the program, although the REPL method above is usually preferred for working with Julia.
(question about calling the script with arguments asked in the comment):
First of all, I'll mention that this is not the usual workflow with Julia scripts. I've been writing Julia code for years, and I had to look up how to handle command-line arguments because I've never once used them in Julia: usually what's done instead is that you define the functions you want in the file, with maybe a main function, and after doing an include, you call the main function (or whichever function you want to try out) with arguments.
Now, if your script already uses command-line arguments (and you don't want to change that), what you can do is assign to the variable that holds them, ARGS, before the include statement:
julia> push!(empty!(ARGS), "arg1")
1-element Vector{String}:
"arg1"
julia> include("main.jl")
Here we empty the ARGS to make sure any previous values are gone, then push the argument (or arguments) we want into it. You can try this out for educational purposes, but if you are new to the language, I would suggest learning and getting used to the more Julian workflow involving function calls that I've mentioned above.
The julia> prompt means your terminal is in Julia REPL mode and is expecting valid Julia code as input. The Julia code main.jl would mean that you want to return the value of a field named jl inside a variable named main. That is why you get that error. The Julia code you would use to run the contents of a file is include("main.jl"). Here the function include is passed the name of your file as a String. This is how you should run files from the REPL.
The instructions you read online are assuming your terminal is in shell mode. This is usually indicated by a $ prompt. Here your terminal is expecting code in whatever language your shell is using e.g. Bash, PowerShell, Zsh. When Julia is installed, it will (usually) add a julia command which works in any shell. The julia command by itself will transform your terminal from shell mode to REPL mode. This julia command can also take additional arguments like filenames. If you use the command julia main.jl in this environment, it will run the file using the Julia program and then exit you back to your terminal shell. This is how you should run files from the terminal shell.
A third way to run Julia files would be to install an IDE like VSCode. Then you can run code from a file with keyboard shortcuts rather than by typing commands.
See the Getting Started Documentation for more information.
Adding to Sundar R's answer, if you want to run script which takes commandline arguments from REPL, you can check this package: https://github.com/v-i-s-h/Runner.jl
It allows you to run you script from REPL with args like:
julia> #runit "main.jl arg1 arg2"
See the README.md for detailed examples.

ProfileView plot not showing when running Julia Code

I wanted to profile my code in Julia and I installed the package "ProfileView.jl". However, when I run the code the windows is popping for a second and closing immediately.
I have run the script from VS Code and also from the terminal. The code I am profiling is:
using ProfileView
#profview Mesh,MatPointData, AnalysisConstants = setupfunc(T)
In general, you should run ProfileView interactively in a REPL, not as part of a script. If you're using VSCode, you want to start the Julia REPL (Ctrl-Shift-P and then Julia: Start REPL); from the terminal, you want to run an interactive session, i.e., $ julia and not $ julia somescript.jl.
If you simply must use a script (again, not recommended because you'll lose access to some nice interactive functionality in ProfileView), see https://juliagraphics.github.io/Gtk.jl/latest/manual/nonreplusage/.

JuliaPro: import Jupiter notebook

I usually use Jupyter to have my interactive environment with Julia, now I am switching to JuliaPro, as they claim it is the fastest and easiest way of Julia programming. But, I cannot upload my .ipynb notebooks on JuliaPro. Are they compatible with each other? How can I work with my notebooks on JuliaPro? Thanks!
As was explained in the comments, the .ipynb file format was designed to be rendered in a browser, while Juno/Atom is a text editor that expects a plain text file for display. In general therefore you wouldn't be able to directly use an .ipynb file in Juno.
There is however an option to convert your notebooks to .jl scripts, which is exactly what Juno is expecting: in your Jupyter notebook click on File > Download as > Julia (.jl) (see below)
There's also an answer here that discusses a command line option if you need to batch convert a lot of files.
Also note that your choice of editor / programming environment is unrelated to the version of Julia you're using - while JuliaPro ships with Juno as standard (or potentially the Julia VS Code extension in future), nothing's keeping you from just doing using Pkg; Pkg.add("IJulia"); using IJulia; notebook() in your JuliaPro installation and continuing to work on your notebooks in Jupyter.

Is it possible to pass state from Julia REPL to a Jupyter notebook via IJulia?

i'd like to open a Julia REPL in a terminal window, do some work, and then launch a Julia notebook via IJulia and notebook(). is there any direct way of passing variables and their values from the REPL, so they would be available in the notebook? or effectively equivalent, a way to access the REPL namespace from a notebook? (i'd prefer to do this without creating temporary files or doing anything magical with memory.)

calling Qiime with system call from R

Hej,
When I try to call QIIME with a system call from R, i.e
system2("macqiime")
R stops responding. It's no problem with other command line programs though.
can certain programs not be called from R via system2() ?
MacQIIME version:
MacQIIME 1.8.0-20140103
Sourcing MacQIIME environment variables...
This is the same as a normal terminal shell, except your default
python is DIFFERENT (/macqiime/bin/python) and there are other new
QIIME-related things in your PATH.
(note that I am primarily interested to call QIIME from R Markdown with engine = "sh" which fails, too. But I strongly suspect the problems are related)
In my experience, when you call Qiime from unix command line, it usually creates a virtual shell of it`s own to run its commands which is different from regular system commands like ls or mv. I suspect you may not be able to run Qiime from within R unless you emulate that same shell or configuration Qiime requires. I tried to run it from a python script and was not successful.

Resources