I had a code that used to work using Julia 0.6, and I have been recently trying to use it again, however I am having different troubles using JLD.
I tried to use the most recent Julia version and it still does not work.
In 0.6 version, here is what I have :
using JLD
INFO: Precompiling module JLD. WARNING: could not import
Base.lastindex into HDF5 WARNING: could not import Base.iterate into
HDF5 ERROR: LoadError: ArgumentError: Module Libdl not found in
current path. Run Pkg.add("Libdl") to install the Libdl package.
Pkg.add("Libdl")
ERROR: unknown package Libdl
I don't really understand what is going on, I saw similar problems on the Julia blog and also in stackoverflow but no proposed solutions seem to work in my case.. I would be ok to modidify my code si it could work with a newer version of Julia but I still can't make JLD work in any version.
Any advice?
Thanks !
For Julia 1.0.0 use the package JLD2.jl.
Press ] to go to the package manager:
add JLD2
Sample code:
using JLD2
obja = (a=5, b=[1,2,3]);
objb = "hello world";
save("dat.jld2","obja",obja,"objb",objb);
Now running
load("dat.jld2")
yields
Dict{String,Any} with 2 entries:
"obja" => (a = 5, b = [1, 2, 3])
"objb" => "hello world"
Related
In Python, you can do:
print(gurobipy.gurobi.version())
What is the equivalent for Julia and JuMP?
I tried
using Gurobi
Gurobi.version()
Without success. I am not trying to get Gurobi.jl package version which can be obtained with ] status Gurobi.
There are three integer variables for this you need to combine them to get the full version number:
julia> println("Grurobi version: $(Gurobi.GRB_VERSION_MAJOR).$(Gurobi.GRB_VERSION_MINOR).$(Gurobi.GRB_VERSION_TECHNICAL)")
Grurobi version: 9.5.0
#przemyslaw-szufel's answer is mostly correct, but it can be wrong with the minor version. The constants he refers to are actually the ones we copy from the gurobi.h file, not from the Gurobi library itself, so you might get v9.5.0 returned when the actual library is v9.5.1.
You can get the exact version using:
julia> using Gurobi
julia> const MOI = Gurobi.MOI
MathOptInterface
julia> v = MOI.get(Gurobi.Optimizer(), MOI.SolverVersion())
"9.1.0"
julia> VersionNumber(v)
v"9.1.0"
this is mostly solver-independent, although not all packages support MOI.SolverVersion.
On a new computer I was trying to run Unfold and UnfoldMakie. See this error in both cases.
Like something wrong with the MutableArithmetics library.
Any idea how to manage it?
Also get this after update of MakieCore package:
Versions:
Julia 1.8.0.
Unfold v0.3.11
UnfoldMakie v0.1.4
It seems as a solution:
These packages work in the julia envv1.7, but do not work in v1.8.
In VScode you can change it here:
Finally figured out the problem:
First, I created a new environment/project.
https://pkgdocs.julialang.org/v1/environments/
Second, activated it in the notebook.
Third, installed problematic libraries through this code:
import Pkg
p = "Unfold"
Pkg.add(p)
Pkg.build(p)
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.
I am using R 3.1.0, along with the tm.plugin.webmining package (within RStudio). Packages are installed fine (along with all dependencies) and I can load the library.
When I try to run a basic test however:
yahoocorpus<-WebCorpus(YahooNewsSource("Microsoft"))
I get:
Error in get(name, envir = asNamespace(pkg), inherits = FALSE) :
object '.Source' not found
This does not occur if I point RStudio to R 2.1.5
I have looked online but not found any resolution of the issue (though somebody did suggest a hack of the source code). It would be great to understand exactly what is causing the problem (and what has changed between versions to make this happen (I also tried 3.0.1, and that also does not work)
Thanks again,
Alan
I think that function WebCorpus does not exist in last version of TM package. Check the doc here!
You have 3 possibilities : DirSource, VectorSource, or DataframeSource.
You can check the source on R with:
{r}
library(tm)
getSources()
Which should give you :
[1] "DataframeSource" "DirSource" "URISource" "VectorSource" "XMLSource"
Cyrille
I want to write a simple R script using the seewave library.
When I call this from the normal R GUI, I get:
> library(seewave)
Loading Tcl/Tk interface ...
It seemingly works, but whenever I try to run a command from this package, it crashes. In the following screenshot, I was trying to run readWave and upon pressing (, the following happened:
Similarly, when I try to run a simple Rscript like this …
#!/usr/bin/env Rscript
library(seewave)
I get the error:
Warning message:
In fun(...) : Can't find a usable tk.tcl in the following directories:
/System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts/tk8.5 /System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts/tk8.5/Resources/Scripts /System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/tk8.5 /System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/tk8.5/Resources/Scripts ./lib/tk8.5 ./lib/tk8.5/Resources/Scripts ~/Library/Tcl/tk8.5 ~/Library/Tcl/tk8.5/Resources/Scripts /Library/Tcl/tk8.5 /Library/Tcl/tk8.5/Resources/Scripts /System/Library/Tcl/tk8.5 /System/Library/Tcl/tk8.5/Resources/Scripts /System/Library/Tcl/8.5/tk8.5 /System/Library/Tcl/8.5/tk8.5/Resources/Scripts ~/Library/Frameworks/tk8.5 ~/Library/Frameworks/tk8.5/Resources/Scripts /Library/Frameworks/tk8.5 /Library/Frameworks/tk8.5/Resources/Scripts /System/Library/Frameworks/tk8.5 /System/Library/Frameworks/tk8.5/Resources/Scripts ./library
This probably means that tk wasn't installed properly.
I'm using the latest version of R (2.14.0) on OS X 10.6.8. Seewave is 1.6.1.
See http://rug.mnhn.fr/seewave/inst.html, the section about tcl/tk and OSX. Make sure you also install tcl/tk 8.5.*