I have a problem with using packages in Julia. It has worked before, and I'm not really sure why this has changed or how to troubleshoot.
I have a folder
/my_path/julia/packages
with Julia packages. For example, there is a folder
/my_path/julia/packages/FFTW/
with the FFTW package.
Further, I have changed the depot path to point at this directory by assigning JULIA_DEPOT_PATH before starting julia, so that
Base.DEPOT_PATH = ["/my_path/julia/"]
However, if I run
julia> using FFTW
I get the following error message:
ERROR: ArgumentError: Package FFTW not found in current path:
- Run `import Pkg; Pkg.add("FFTW")` to install the FFTW package.
Any idea how I can troubleshoot or fix this?
Manipulating Base.DEPOT_PATH does not seem like a good idea.
The code proposed by #cmc will does not work (at least on Julia 1.3.1):
julia> Base.DEPOT_PATH = ["/some/path"]
ERROR: cannot assign variables in other modules
There is a workaround:
Base.DEPOT_PATH[1] = "/some/path"
However, the correct way is to assign the JULIA_DEPOT_PATH system variable before starting Julia, Windows:
set JULIA_DEPOT_PATH=c:\some\path
or
set JULIA_DEPOT_PATH=c:\some\path1;c:\some\path2
Linux/OSX:
export JULIA_DEPOT_PATH=/some/path
or
export JULIA_DEPOT_PATH=/some/path1:/some/path2
Unless you have a specific reason to do so (and if this is the case I'd be interested to hear it!), you don't need to fiddle with the DEPOT_PATH or LOAD_PATH variables: using Julia's package manager should be enough to cover your needs most of the time.
In this specific instance, have you tried to do what the error message suggests?
julia> import Pkg
julia> Pkg.add("FFTW")
LOAD_PATH, not DEPOT_PATH, will modify code loading.
You want to do something like push!(LOAD_PATH, /my_path/julia/packages).
I will echo #ffevotte and strongly suggest to not modify LOAD_PATH unless necessary. The benefits of organizing dependencies into Pkg environments far outweigh the small overhead of declaring them explicitly through Pkg.add.
Related
My goal is to analyse simple point patterns on linear networks with respect to Euclidean distance instead of shortest-path distance implemented in linearK and related functions of spatstat and its sub packages. Browsing through the web I found the promising named function linearKEuclid() and related functions here.
Unfortunately, I could not bring those functions to live on my Win machine, e.g. I run in errors like this
Error in xysegMcircle(Y$x, Y$y, D, df$x0, df$y0, df$x1, df$y1) :
object 'C_circMseg' not found
or
Error in tapply(stuff$sinalpha, list(ii, jj), harmonicsum) :
object 'harmonicsum' not found
There is always something missing. For me, this means simply copying missing functions from the web, if available, does not help.
Probably, a reason for this is that the functions are merely written for internal purposes and under internal development, see, for instance, here under "Details".
However, I am hoping for some recommendation making the fascinating code around linearKEuclid() runnable on my machine. Maybe, there are some chances that someone draws my attention to a downloadable developer version or something comparable. Many thanks in advance!
I understand your confusion and it is unnecessarily complicated to get this to work at the moment since problems with another package on CRAN prevents spatstat and subpackages to be updated at the moment. Indeed you need to install a development version of spatstat.linnet and its dependencies. This is most easily done if you have the package remotes installed (and necessary tools to compile packages from source which would be RTools on Windows):
First run (in sequence):
remotes::install_github("spatstat/spatstat.random")
remotes::install_github("spatstat/spatstat.sparse")
remotes::install_github("baddstats/spatstat.explore")
remotes::install_github("baddstats/spatstat.model")
remotes::install_github("spatstat/spatstat.linnet")
Now the function should work (you may have to restart R if an old version of spatstat.linnet was already loaded when you updated). Try e.g. the example from the help file:
library(spatstat.linnet)
X <- rpoislpp(5, simplenet)
K <- linearKEuclid(X)
I have already made a simple R package (pure R) to solve a problem with brute force then I tried to faster the code by writing the Rcpp script. I wrote a script to compare the running time with the "bench" library. now, how can I add this script to my package? I tried to add
#'#importFrom Rcpp cppFunction
on top of my R script and inserting the Rcpp file in the scr folder but didn't work. Is there a way to add it to my r package without creating the package from scratch? sorry if it has already been asked but I am new to all this and completely lost.
That conversion is actually (still) surprisingly difficult (in the sense of requiring more than just one file). It is easy to overlook details. Let me walk you through why.
Let us assume for a second that you started a working package using the R package package.skeleton(). That is the simplest and most general case. The package will work (yet have warning, see my pkgKitten package for a wrapper than cleans up, and a dozen other package helping functions and packages on CRAN). Note in particular that I have said nothing about roxygen2 which at this point is a just an added complication so let's focus on just .Rd files.
You can now contrast your simplest package with one built by and for Rcpp, namely by using Rcpp.package.skeleton(). You will see at least these differences in
DESCRIPTION for LinkingTo: and Imports
NAMESPACE for importFrom as well as the useDynLib line
a new src directory and a possible need for src/Makevars
All of which make it easier to (basically) start a new package via Rcpp.package.skeleton() and copy your existing package code into that package. We simply do not have a conversion helper. I still do the "manual conversion" you tried every now and then, and even I need a try or two and I have seen all the error messages a few times over...
So even if you don't want to "copy everything over" I think the simplest way is to
create two packages with and without Rcpp
do a recursive diff
ensure the difference is applied in your original package.
PS And remember that when you use roxygen2 and have documentation in the src/ directory to always first run Rcpp::compileAttributes() before running roxygen2::roxygenize(). RStudio and other helpers do that for you but it is still easy to forget...
Let's say we have a symbol array of packages packages::Vector{Symbol} = [...] and we want to create a sys image using PackageCompiler.jl. We could simply use
using PackageCompiler
create_sysimage(packages; incremental = false, sysimage_path = "custom_sys.dll"
but without a precompile_execution_file, this isn't going to be worth it.
Note: sysimage_path = "custom_sys.so" on Linux and "custom_sys.dylib" on macOS...
For the precompile_execution_file, I thought running the test for each package might do it so I did something like this:
precompilation.jl
packages = [...]
#assert typeof(packages) == Vector{Symbol}
import Pkg
m = Module()
try Pkg.test.(Base.require.(m, packages)) catch ; end
The try catch is for when some tests give an error and we don't want it to fail.
Then, executing the following in a shell,
using PackageCompiler
packages = [...]
Pkg.add.(String.(packages))
Pkg.update()
Pkg.build.(String.(packages))
create_sysimage(packages; incremental = false,
sysimage_path = "custom_sys.dll",
precompile_execution_file = "precompilation.jl")
produced a sys image dynamic library which loaded without a problem. When I did using Makie, there was no delay so that part's fine but when I did some plotting with Makie, there still was the first time plot delay so I am guessing the precompilation script didn't do what I thought it would do.
Also when using tab to get suggestions in the repl, it would freeze the first time but I am guessing this is an expected side effect.
There are a few problems with your precompilation.jl script, that make tests throw errors which you don't see because of the try...catch.
But, although running the tests for each package might be a good idea to exercise precompilation, there are deeper reasons why I don't think it can work so simply:
Pkg.test spawns a new process in which tests actually run. I don't think that PackageCompiler can see what happens in this separate process.
To circumvent that, you might want to simply include() every package's test/runtests.jl file. But this is likely to fail too, because of missing test-specific dependencies.
So I would say that, for this to work reliably and systematically for all packages, you'd have to re-implement (or re-use, if you can) some of the internal logic of Pkg.test in order to add all test-specific dependencies to the current environment.
That being said, some packages have ready-to-use precompilation scripts helping to do just this. This is the case for Makie, which suggests in its documentation to use the following file to build system images:
joinpath(pkgdir(Makie), "test", "test_for_precompile.jl")
Looked around and still not sure what is the difference between library()/require() and source() in r? According to this SO question: What is the difference between require() and library()? it looks like library() and require() are the same thing, maybe one is legacy. Is source() for lazy developers that don't want to create a library? When do you use each of these constructs?
The differences between library and require are already well documented in What is the difference between require() and library()?.
So, I will focus on how source differs from these. In fact they are fundamentally quite different commands. Neither library nor require actually execute any code. They simply attach a namespace, in a lazy fashion, meaning that individual functions in the package are not run unless they are actually called later. Source on the other hand does something quite different which is to execute all of the code in the file at that time.
A small caveat: packages can be made to actually run some code at the time of package loading or attaching, via the .onLoad and .onAttach functions. Have a look here: https://stat.ethz.ch/R-manual/R-devel/library/base/html/ns-hooks.html
source runs the code in a .R file, line by line.
library and require load and attach R packages.
Is source() for lazy developers that don't want to create a library?
You're correct that source is for the cases when you don't have a package. Laziness is not the only reason, sometimes packages are not appropriate---packages provide functionality, but don't do things. Perhaps I have a script that pulls data from a database, fits a model, and makes some predictions. A package may provide functions to help me do that, but it does not actually do it. A script saved in a .R file and run with source() could run the commands and complete the task.
I do want to address this:
it looks like library() and require() are the same thing, maybe one is legacy.
They both do the same thing (load and attach a package). The main difference is that library() will throw an error and stop the script if the package is not available, whereas require() will return TRUE or FALSE depending on its success. The general consensus is that library is better so that your script stops with a nice clear error and you can install the missing package before proceeeding. The question linked has a more thorough discussion which I won't try to replicate here.
Since in http://julia.readthedocs.org/en/latest/manual/modules/ there's no much info about modules, I would like to ask the following.
I want to try two modules via ijulia. Both modules are in my working directory as
name-of-files.jul. I will call them generically module_1.jul and module_2.jul.
module_1.jul uses module_2.jul and I load it with
using module_2
On ijulia session, if I try
using module_1
gives an error. I also tried
include("module_1.jul")
This last sentence, when executed, rises an error because the module_1.jul cannot find
variable "x" that I know is contained in module_1.jul (in this case I "loaded" the module
using include("module2.jul") inside module_1.jul
Julias module system assumes some things that aren't necessarily obvious from the documenation at first.
Julia files should end with .jl extensions.
Julia looks for module files in directories defined in the LOAD_PATH variable.
Julia looks for files in those directories in the form ModuleName/src/file.jl
If using module_1 fails then I'm guessing it's because it's source files fail one of the above criteria.
Some time has passed since this question. Recently, Noah_S wrote the solution in the comments of the previous answer; this means that it is a recurrent doubt for people starting to learn the language. For their sake, I will re-write it here Noah_S' answer along with my most novel solution.
I am a mess with the julia versions and which commands work with the specific ones, so for older julia versions we have to look for the \path and then include in the julia module
push!(LOAD_PATH, "/path")
In newer versions this can be improved. Forget about looking by hand the path and just do
path = readstring(`pwd`)
push!(LOAD_PATH, chomp(path))
I hope this can be useful to many julians newcomers.