I have test configuration files and such that I'd like to run tests on, but the other ways I've used to get the current directory (e.g. process.cwd()) fail with 'process not defined' errors.
The Assets set only allows text and binary read (not access to full path name).
Anyone have a good solution to this issue?
Thanks,
ssteinerX
Related
Disclaimer: I am very new here.
I am trying to learn R via RStudio through a tutorial and very early have encountered an extremely frustrating issue: when I am trying to use the read.table function, the program consistently reads my files (written as "~/Desktop/R/FILENAME") as going through the path "C:/Users/Chris/Documents/Desktop/R/FILENAME". Note that the program is considering my Desktop folder to be through my documents folder, which is preventing me from reading any files. I have already set and re-set my working directory multiple times and even re-downloaded R and RStudio and I still encounter this error.
When I enter the entire file path instead of using the "~" shortcut, the program is successfully able to access the files, but I don't want to have to type out the full file path every single time I need to access a file.
Does anyone know how to fix this issue? Is there any further internal issue with how my computer is viewing the desktop in relation to my other files?
I've attached a pic.
Best,
Chris L.
The ~ will tell R to look in your default directory, which in Windows is your Documents folder, this is why you are getting this error. You can change the default directory in the RStudio settings or your R profile. It just depends on how you want to set up your project. For example:
Put all the files in the working directory (getwd() will tell you the working directory for the project). Then you can just call the files with the filename, and you will get tab completion (awesome!). You can change the working directory with setwd(), but remember to use the full path not just ~/XX. This might be the easiest for you if you want to minimise typing.
If you use a lot of scripts, or work on multiple computers or cross-platform, the above solution isn't quite as good. In this situation, you can keep all your files in a base directory, and then in your script use the file.path function to construct the paths:
base_dir <- 'C:/Desktop/R/'
read.table(file.path(base_dir, "FILENAME"))
I actually keep the base_dir assignemnt as a code snippet in RStudio, so I can easily insert it into scripts and know explicitly what is going on, as opposed to configuring it in RStudio or R profile. There is a conditional in the code snippet which detects the platform and assigns the directory correctly.
When R reports "cannot open the connection" it means either of two things:
The file does not exist at that location - you can verify whether the file is there by pasting the full path echoed back in the error message into windows file manager. Sometimes the error is as simple as an extra subdirectory. (This seems to be the problem with your current code - Windows Desktop is never nested in Documents).
If the file exists at the location, then R does not have permission to access the folder. This requires changing Windows folder permissions to grant R read and write permission to the folder.
In windows, if you launch RStudio from the folder you consider the "project workspace home", then all path references can use the dot as "relative to workspace home", e.g. "./data/inputfile.csv"
I'm very excited on the newly released Azure Machine Learning service (preview), which is a great step up from the previous (and deprecated) Machine Learning Workbench.
However, I am thinking a lot about the best practice on structuring the folders and files in my project(s). I'll try to explain my thoughts.
Looking at the documentation for the training of a model (e.g. Tutorial #1), there seems to be good-practice to put all training scripts and necessary additional scripts inside a subfolder, so that it can be passed into the Estimator object without also passing all other files in the project. This is fine.
But when working with the deployment of the service, specifically the deployment of the image, the documentation (e.g. Tutorial #2) seems to indicate that the scoring script need to be located in the root folder. If I try to refer to a script located in a subfolder, I get an error message saying
WebserviceException: Unable to use a driver file not in current directory. Please navigate to the location of the driver file and try again.
This may not be a big deal. Except, I have some additional scripts that I import both in the training script and in the scoring script, and I don't want to duplicate those additional scripts to be able to import them in both the training and the scoring scripts.
I am working mainly in Jupyter Notebooks when executing the training and the deployment, and I could of course use some tricks to read the particular scripts from some other folder, save them to disk as a copy, execute the training or deployment while referring to the copies and finally delete the copies. This would be a decent workaround, but it seems to me that there should be a better way than just decent.
What do you think?
Currently, the score.py needs to be in current working directory, but dependency scripts - the dependencies argument to ContainerImage.image_configuration - can be in a subfolder.
Therefore, you should be able to use folder structure like this:
./score.py
./myscripts/train.py
./myscripts/common.py
Note that the relative folder structure is preserved during web service deployment; if you reference the common file in subfolder from your score.py, that reference should be valid within deployed image.
I am using scalapact for CDC test.
My tests are running fine and the pact file is generated under target>pacts folder.
I have another folder "files" where I want those pact files to be generated after running the pact tests.
Is there any way I configure the default path for pact files?
This is an area that needs some attention in Scala-Pact, however, someone kindly did a PR for us a while ago that lets you set an environment variable called pact.rootDir.
In practice, on linux/mac that variable is a bit tricky to set because of the ., so exporting it or just using -Dpact.rootDir="<my desired path>" in the command arguments doesn't seem to work. Instead, you need to do this:
env "pact.rootDir=<my desired path>" bash. I haven't tried this on Windows so I don't know if you'd have the same issue.
I've just raised an issue to try and make this easier in the future:
https://github.com/ITV/scala-pact/issues/101
As an alternative, note that the pact directory is really kind of a scratch/tmp area to allow Scala-Pact to compile it's output. If you're running this as part of a build script, you may just want to add a step to copy the assets to a new location once they've been generated.
Also, for some reason we made reading from a directory way easier than writing to one. If you need to read from a dir such as during verification, you can just add --source <my desired path> on the command line.
Hope that helps.
I am trying to execute a command from a different directory but I keep getting a "No such file or directory" response. I have been stuck for about 6 hours now and cannot figure it out. I am very new so please take it easy.
I created a directory (Learning) with a subdirectory (fileAsst), and two subdirectories (Earth, Galaxy) within "fileAsst." I am trying to execute a separate file to check to see if I have built the desired directory correctly.
I type in ~unix/bin/fileAsst-1 to try and execute to my directory. But it just is not working. Please help.
Learning/fileAsst/Earth/zaphod.txt
Learning/fileAsst/Galaxy/trillian.txt
~unix/bin/fileAsst-1 (what I'm trying to execute to check my Learning directory)
My guess, based upon your usage of the phrase "execute to my directory", you need to read something like this.
I cannot be sure but it appears as though you want to change your current directory to some other directory using the cd command. Having set your current working directory appropriately you wish to execute some command.
But a guess is only a guess and it's somewhat dangerous to give an answer when unfamiliar nouns and verbs are used in the question.
Error: ENOTEMPTY, directory not empty '/path/disk/folder/.meteor/local/build-garbage- qb4wp0/programs/ctl/packages'
I already looked over this website for this problem and known what are maybe the causes of this error and also tried them. I also tried their solutions and I can manage to always reset the project.
The problem is, whenever the project is reset, on the first run of the project,it will run smoothly and no errors will occur but after some moment or changes to my project like error checking, adding packages or changing some stuff... that error will occur.
I have no idea on how to fix this problem and my temporary solution is to always create another meteor project and put all my project files and also install all packages I used.
Badly need help.
I had this error when running Meteor.js on a Vagrant machine. For additional background, I had created a symbolic link for the MongoDB's db folder, since I had faced a locking issue (solution I used for that was described elsewhere).
Following that, my setup was as follows:
/vagrant/.meteor/local/db -> /home/vagrant/my_project_db (symbolic link)
That solved the problem I had with MongoDB's lock, but everytime any source file changed, meteor would crash with the same exception that you faced. Deleting files didn't help, neither did meteor reset.
Fortunately enough it was remedied by changing the folder structure to this:
/vagrant/.meteor/local -> /home/vagrant/my_project_local (symbolic link)
What I did was as simple as moving the Meteor.js's local folder out from the shared folder and only referencing to that with a symbolic link:
cd /vagrant/.meteor
mv local /home/vagrant/my_project_local
ln -s /home/vagrant/my_project_local local
In the end all is good. The error is long gone and feedback cycle is much shorter.
Try deleting the folder it tells you are issues. I think its trying to clean them but there's an unhandled type of situation (it has files in it and its using rm instead of a recursive one)
Remove
/media/Meteor/hash/.meteor/local/build-garbage-**
(Anything with build-garbade in the name). Also you might want to check whether your permissions are right this might have been caused initially with something to do with incorrectly set permissions, maybe you ran as sudo once? If you're on a Mac you could use repair disk permissions.