Currently, it takes a few seconds for the Julia interpreter to start on my machine when running any .jl file.
I'm wondering if there is a simple solution to this, such as a way to have a background pool of interpreters ready to execute scripts or a way to make the Julia repl, once opened, execute a .jl file (and possibly do so with the -p argument to properly handle multithreaded scripts) ?
I'm wondering if there is a simple solution to this, such as [...] a way to make the Julia repl, once opened, execute a .jl file [...].
You can execute a .jl file in a running Julia REPL with the include() function. For example, to execute a file foo.jl, enter the Julia REPL and do:
julia> include("test.jl")
The file will then be executed within the REPL. However, this is unlikely to solve your problem, since the file execution will probably take multiple seconds as well. The REPL itself starts quickly, the long execution time stems from Julia taking a long time to load the file.
You can partially address this issue with Revise.jl. Revise.jl is a Julia package that automatically and quickly reloads your imported files and packages when they are edited. Thus, you could mitigate your issue by only having to load the .jl file once at startup. Here is a quick example of using Revise.jl:
julia> Pkg.add("Example")
INFO: Installing Example v0.4.1
INFO: Package database updated
julia> using Revise # importantly, this must come before `using Example`
julia> using Example
julia> hello("world")
"Hello, world"
Related
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.
Running a Julia file in REPL
julia> include("foo.jl")
julia> include("foo.jl")
gives different running time but it doesn't seem to be the case when I run it from the terminal
$ julia foo.jl
$ julia foo.jl
Is there a standard method for saving compiled files outside of Julia?
Normally Julia compiles functions the first time they're used within a given Julia instance, so each time you call julia foo.jl from the command line it will need to re-compile whatever code is called in foo.jl.
If you want to store a compiled version of foo.jl, you can use the PackageCompiler package (https://github.com/JuliaLang/PackageCompiler.jl) which will replace your original Julia binary (where the code in foo.jl has not been compiled) with a new one where foo.jl has been compiled.
Note that you probably don't want to do this if you're actively developing foo.jl as it takes some time to make each new Julia sysimage. If that's the case, you can just create a small script that loads all the packages and calls the same functions you want to call. Once that sysimage is compiled you should be able to import the same packages and use the same functions with no additional compilation time.
If you're re-running it to test changes to the underlying code, also consider using Revise.
There is a Julia package for running Julia as a daemon: https://github.com/dmolina/DaemonMode.jl which is worth checking out. Doesn't exactly answer the question about "how to save compiled Julia code" but it could probably improve the workflow you are after.
I have exe file which was built on C++. The exe file needs an input argument.
Now i want to launch multiple exe file from Rstudio by changing the input arguments so that i can run different scenarios in parallel. When i use system/shell/system2 commands, the model starts running inside the Rstudio environment itself, but i want to make it to run outside Rstudio environment, so that i can run multiple models at a time.
system("xyz.exe scenario1")
system("xyz.exe scenario2")
system("xyz.exe scenario3")
Looking at ?system you can see that there is an argument wait. Quoting from the help file:
[wait is] a logical (not NA) indicating whether the R interpreter should wait
for the command to finish, or run it asynchronously. This will be
ignored (and the interpreter will always wait) if intern = TRUE.
So using wait=TRUE would cause the behaviour that you require.
When I run a Julia Script that prints "Hello World" on HTCondor, I get the following error
fatal: error thrown and no exception handler available.
Base.InitError(mod=:Pkg, error=Base.KeyError(key="HOME"))
The code runs without a problem on my local Ubuntu machine. I can run
eval julia --version
in a bash script on condor and the output is
julia version 0.5.0
This problem has been discussed in two places on github: one, two.
ENV["HOME"] is used in a single file and the common recommendation is to modify that. However, I cannot change the julia installation on condor.
Is there a way to fix this on the fly before running a script without sudo?
As #sujeet suggested, it is possible to set environmental parameters in condor. The issue is resolved by adding the following line in the condor submit script
Environment = "HOME=""/tmp"""
, which sets the home directory to the tmp. Julia code runs fine then (as long one is careful not to write to home before resetting it in the script itself).
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.