My IDL installation (currently v.8.7.2, but the same problem occurred in v.8.5) does not recognize hash, list, dictionary and orderedhash. For example, typing
h = HASH('Id', 1234)
results in the error "Variable is undefined: HASH.". I am at my wits end. All kinds of other things are working with no problems, I don't seem to have issues with my path or with external libraries. What's going on??
My guess is that your path is not correct, that it is pointing at the IDL lib directory of an older (pre-hash, list, etc) IDL's lib directory. Could you print !path?
Related
When looking at files like this: https://github.com/simon-lc/Silico.jl/blob/main/examples/demo/peg_in_hole_planning.jl
The author does not call "using Silico" or "using Mehrotra" anywhere, yet calls it many times throughout the file. As someone coming from Python, I don't understand this. How does Julia know where to look for Silico without a statement like "using Silico"?
For this, you can customize the configuration file of Julia.
For example, in Windows OS, you can go to the following path:
C://Users//.julia/config/startup.jl
Open the file and write the importing command(s) you want. E.g., using Term or using OhMyREPL and using Statistics: mean, std (then those functions will be available by default). Then every time you run the Julia, those packages will be imported automatically.
*Note that if this file doesn't exist in the path, you can create a file with the same name.
You can also compile the preferred packages into the Julia system image, and the Julia REPL will start a bit quicker since it does not have to parse and compile the package when loaded. The way to do this is by using PackageCompiler.jl. [1]
I tried to find some already existing solutions - no success so far.
The problem
There are some projects, all run in R, by a group of people, where each team member uses Windows as the main operating system.
Nearly each script file uses the following command at the very beginning
setwd("Z://00-00-00/path/to/project")
What is used here is some common disc space under the path Z://00-00-00/. Since I work on MAC OS my paths are /common-drive/path/to/project the question is:
Is there a way to include a command/script in some sort of file like ~/.bashrc or maybe some R-related settings that will convert Windows-like absolute file paths to paths that are MAC OS-like when they detect it?
What I think should run is:
path.to.be.used <- "Z://00-00-00/path/to/project"
str_replace(path.to.be.used, "Z://00-00-00/", "/common-drive/")
however, all scripts have the path hard-coded directly in setwd, so I cannot change each file by hand. That is why I am trying to find out some workaround that will convert these paths in a "silent mode".
Does anyone have an idea how to do this? Any way to make a control on system or R-studio level if the path should be converted?
Thank you for you time and help!
As others said in the comments, you should convince your co-workers not to do that. However, that's often difficult, so here's a hack solution (mentioned by #MrFlick):
setwd <- function(dir) {
newdir <- sub("Z://00-00-00/", "/common-drive/", dir)
cat("Requested ", dir, ", using ", newdir, "\n")
base::setwd(newdir)
}
So I was trying to install Rcpp using the checkpoint package (with a March 1st 2020 date).
Most of my packages were fine, but Rcpp specifically makes a lot of temporary directories that it then deletes, for example:
00LOCK-Rcpp/00new/Rcpp/include/Rcpp/generated/InternalFunctionWithStdFunction_call.h
This is 84 characters long and I belive some are longer.
Checkpoint creates numerous directories as well, for example with a custom library here:
"custom_library/.checkpoint/2020-03-01/lib/x86_64-w64-mingw32/3.6.0/"
This is 67 characters, of which 52 are only necessary when managing multiple checkpoint dates or versions.
This means that for a file path such as:
"C:/Users/USER/OneDrive - COMPANY/Documents/LargeDirectory/SubDirectory1/SubDirectory2/custom_library/.checkpoint/2020-03-01/lib/x86_64-w64-mingw32/3.6.0/Rcpp"
Assuming even temporary files can't exceed 255 chars then I have definitely < 60 characters left available for all of the Rcpp temporary objects.
I tested with the following code:
setwd("C:/Users/USERNAME/OneDrive - COMPANY/Documents/LargeDirectory/SubDirectory1/SubDirectory2/")
dir.create("custom_library)
checkpoint(as.Date("2020-03-01"),
checkpointLocation = paste0(
"SubDirectory2","/custom_library")
)
y
install.packages("Rcpp")
It fails because of numerous "no file or directory found" which I believe actually fails because 00LOCK-Rcpp/00new/Rcpp/include/Rcpp/ can't be created to then unzip all the .h files to it. I was curious so I ran the following:
setwd("~") # up to Documents
dir.create("Rcpptest")
.libPaths("Rcpptest")
install.packages("Rcpp")
And it installed fine.
Any ideas on how to make checkpoint either not create so many nested directories OR ignore the file_path 255 limit until the whole package installs?
For now, I will likely move the directory up a few levels but any insight into whether my guess is actually correct or if I'm missing something would be appreciated!
I believe you are correct -- this is, to the best of my knowledge, a limitation of the internal unzip implementation used by R, which is ultimately a limitation of the Windows APIs used by R. See https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file for some more discussion.
There are a couple options for mitigating the issue that may be worth trying.
Use utils::shortPathName() to construct a so-called Windows 'short path'. This will help trim longer path components and bring the full path down in size.
Create a junction to your project using Sys.junction() to a local path with a shorter length, and move to that directory. See ?Sys.junction for more information -- a junction is basically like a Windows shortcut, or a symlink to a directory.
In each case, you should hopefully be able to construct a path that is "identical" to your current project directory, but short enough that things can function as expected.
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.
I'm trying to get package references resolved during a build, using GNAT Programming Suite (hosted on Win XP). In the Builder Results, I get errors like this one:
file "ac_configuration_s.ada" not found
Clicking on the error takes me to a line like this:
with
Ac_Configuration,
Dispense_Timer,
...
The first item (Ac_Configuration) isn't resolved, but the second item (Dispense_Time) is resolved. I have several others that do or don't resolve. All of the files in question (spec and body) are identified as source files.
When I hover my mouse over the line with the error, a popup shows up that offers this:
(Cross-references info not up to date. This is a guess.)
Ac_Configuration
local package declared at D_Ac_Config_S.Ada:85
The guess is correct, but I don't know how to use this. How do I get this to correctly build?
Update
Here is teh call to gcc
gcc -c "-gnatec=C:\Source\build\GNAT-TEMP-000001.TMP" -I- -gnatA
-x ada "-gnatem=C:\Source\build\GNAT-TEMP-000002.TMP" "C:\Source\C_Cbt_Main_B.Ada"
I don't see a reference to teh "miimal" switch.
In this case, there is no corresponding body file file D_Ac_Config_S.Ada. So the is no body file to compile separately.
When I right click on the package reference inside the with, I can goto the declaration of Ac_Configuration and every other package name that is the source of an error. So these lreferences are being resolved somehow.
By the way, I have not used ADA before, so I'm still trying to understand everything.
It looks as though you're using _s.ada as the suffix for specs, and I'm guessing _b.ada for bodies?
GNAT may have difficulty with this naming convention. It's possible, using a GNAT Project file (.gpr), to alter GNAT's default convention ({unit-name}.ads for specs, {unit-name}.adb for bodies) but the rules (see "Spec_Suffix") say "It cannot start with an underscore followed by an alphanumeric character" (I haven't tried this, but you can see that it would confuse the issue if you had a package Foo_S, for example).
LATER: It turns out that GNAT (GPL, 4.7, 4.8) is quite happy with your suffixes!
If the package Ac_Configuration is really a local package declared at line 85 of D_Ac_Config_S.Ada, then there's your problem; you can only with a library unit, which in this case would be D_Ac_Config.
with D_Ac_Config;
...
package Foo is
...
Bar : D_Ac_Config.Ac_Configuration.Baz;
I wonder whether D_Ac_Config_S.Ada (for example) actually contains multiple Ada units? (if so, compiling that file should result in a compilation error such as end of file expected, file can have only one compilation unit). GNAT doesn't support this at compile time, providing instead a utility gnatchop.
Would it be possible to just gnatchop all the source and be done with it?
Hm, I think it sounds like the compiler's got a bad set of objects/ALIs it's working with, hence the cross-reference not up to date error. (Usually the compiler's good about keeping things up to date; but you may want to check to see if the "minimal recompilation" switch is set for the project.)
Have you tried compiling just the ["owning"] file D_Ac_Config_S.Ada? (i.e. if it were a spec, go to the corresponding body and compile that.) That should force its ALI/object files to be updated.
Then try building as normal.
-- PS: you might have to clean first.