I am building a documentation with documenter.jl. Everything was working fine, until I pulled a new version of the repo from GitHub (and pushed my current repo onto GitHub). I don't think there was anything in the pull that should affect documenter at all. Yet, ever since the pull the build is hanging at [ Info: ExpandTemplates: expanding markdown templates.. The entire build looks like this:
[ Info: SetupBuildDirectory: setting up build directory.
[ Info: Doctest: running doctests.
[ Info: ExpandTemplates: expanding markdown templates.
Does anyone have any idea what the reason for this could be?
Related
I'm trying to customize the linter settings in VSCode for R but I'm a little confused.
I've checked just about every source available, from SO questions to the lintr package vingette, but I'm stumbling on an issue. It could be that since I'm not a programmer I'm just not understanding something basic but essential.
A question about line length linter 80 characters
Disable R-linting in VScode
How to change the line length preference for warnings in Diagnostics? #3
Specify linters in lintr::lint
lintr github page
Lint R code in Visual Studio
lintr v2.0.0
Using lintr
It seems like I need to create a .lintr file in the folder that my script is in. Or possibly make changes in the .lintr file in the lintr package ~lintr/R/ folder?
I guess I'm just confused on the .lintr file. I tried creating files called "lintr", ".lintr" and "ScriptName.lintr", then added the following line to it, as described in the above sources:
linters: with_defaults(line_length_linter=line_length_linter(120L))
Then I reopened the script but whatever I do, lintr continues to default to 80 spaces. I think I'm doing something wrong with the .lintr file but I'm not sure what. I also tried changing file called "lintr" in the lintr package directory, but I can't save the file because it has no extension type (though it appears to be in the Debian Control Field Format, whatever that is). Windows keeps giving me a prompt to save as "txt".
I'd appreciate any step-by-step instructions to get past this issue.
I am having some sort of communication issue with my RStudio project and GitHub, potentially related to updating R and RStudio.
I recently updated my R to version 4.0.3 on my windows machine:
R version 4.0.3 (2020-10-10); Platform: x86_64-w64-mingw32/x64 (64-bit)
I also updated my RStudio to Version 1.3.1093, and finally, as a result of the issues below, I updated my git version to 2.30.0.windows.1
I have two existing R Packages hosted on GitHub, and recently created a third. To create my new Repo and link it to my local project I followed the instructions on:
https://aberdeenstudygroup.github.io/studyGroup/lessons/SG-T1-GitHubVersionControl/VersionControl/
I have interacted with GitHub to update my current packages, but it's been years since I created a new repository. It wasn't easy but eventually everything seemed to be working properly. I made some edits, performed a commit, went to push (using the shell or RStudio's GUI) and got this error:
To github.com:user/repo.git
! [rejected] HEAD -> main (non-fast-forward)
error: failed to push some refs to 'github.com:user/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
I am the only person using this repo, and when I perform a pull, I'm told everything is up to date. I also found a post suggesting I first fetch, then rebase (Git push rejected "non-fast-forward"). When I tried these steps I got an error:
$ git rebase tmp
error: could not apply 4fc4d3e... Conflict test
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 4fc4d3e... Conflict test
CONFLICT (add/add): Merge conflict in R/conflict test.R
Auto-merging R/conflict test.R
How do I have a conflict? How can my local copy be behind if I am the only one working on this project?
To work around this I've started performing commits, then forcing the push via git push -f origin main. Since I am the only person who will ever work on this project, perhaps this is safe; however, it's obviously not recommended and shouldn't be needed.
Also, I went back to my previous packages and performed some test commits. Sure enough, I now have this same error when I try to push new commits to GitHub for packages that were communicating perfectly previously.
I have spent some time trying to figure this out, but my efforts are limited to trying to create the repo and local package in different ways and connecting them with SSH vs URL, etc. I'm not well versed in GitHub; once my previous projects were set up I just used the same protocol to commit and push (again, I am the only user editing any of these packages). My guess is that somehow my updates to R, RStudio, or git seem to have created some sort of communication issue that I can't figure out.
I have created a virtual environment with rvenv, so that I now have rvenv/ in my project root. I have also installed styler, and would like to have a pre-commit hook that will apply it to R code.
From here: https://github.com/lorenzwalthert/precommit/blob/master/.pre-commit-hooks.yaml is the following:
- id: style-files
name: style-files
description: style files with styler
args: [--style_pkg=styler, '--style_transformers=tidyverse_style(scope = "tokens")']
entry: inst/bin/style-files
language: script
files: '(\.R|\.Rmd|\.Rnw|\.r|\.rmd|\.rnw)$'
I'm confused about the path that should be given to entry:, in this snip it's a path to a global version of styler (or at least, I'm assuming so). But I would like to be able to use the version that I have installed in the virtual environment I assume.
My question is - how to go about doing this. If I shouldn't be using the version installed in renv/ then I'm happy to hear (and use) whatever the best practice is around creating a pre-commit hook to style R files that will work on mine and others systems.
Edit
Following the answer below worked, I had to install docopt as well (as outlined here).
Usually you rely on the remote repository to provide the configuration (such that you don't need all of the args / entry / etc. setup
for example if you want to use style-files from the repository you've listed you'd set this in your .pre-commit-config.yaml:
repos:
- repo: https://github.com/lorenzwalthert/precommit
rev: v0.1.2
hooks:
- id: style-files
from there you can customize args / etc.
I was trying to update my julia packages, and I'm running into issues. First, I ran Pkg.update() as always...
julia> Pkg.update()
INFO: Updating METADATA...
INFO: Updating Bio...
INFO: Computing changes...
INFO: Upgrading Atom: v0.2.0 => v0.2.1
It hung on that last line (I finally did a keyboard interrupt after about an hour). So I thought I'd just remove and reinstall Atom.
julia> Pkg.rm("Atom")
INFO: Upgrading Colors: v0.6.1 => v0.6.2
Same problem here. It just hangs. Keyboard interrupt again. Next:
julia> Pkg.rm("Colors")
INFO: Removing Colors (unregistered)
This went fine.
julia> Pkg.rm("Atom")
INFO: Installing Colors v0.6.2
Hangs. If I try to add Colors by itself, the first thing that happens is it tries to upgrade Atom, and it hangs. So my main question is how to fix this, but I'm also confused why trying to remove a package is trying to install other packages.
I can't say for certain why these commands are hanging in your case, however, there's an issue on Pkg.update() hanging that some users have tracked back to Git itself rather than Julia. If you experience another Pkg.update() hang, check the processes running on your system and see if you can determine whether it's a Julia issue or a Git issue. The v0.5 release of Julia will be using a different Pkg implementation that may have fixed this, and in the meantime, you might be able to use a fix like this. If you need further assistance, post to that issue and see if you can get more detailed help.
In addition to the Pkg.rm("PKG"); Pkg.add("PKG"); workaround used by datafig, if you find yourself continuing to have trouble with this, or having to manually remove and add back multiple packages, you could try keeping a running list of your favorite packages so you can quickly blast away and then rebuild your package library
rm(homedir() * "/.julia", recursive=true);Pkg.init()
pkgs = [
"Colors",
"Atom"
]
for p in pkgs
Pkg.add(p)
end
Just put whatever packages you use most in the pkgs array, and if you get stuck again that should serve as a reliable workaround until a more permanent fix is found.
On windows after running the grunt build command for creating brackets shell it gives done without errors but i dont see any .exe file generated..
What might be the problem???
Here are some possible solutions:
Are you following the full brackets-shell build instructions, including all prerequisites?
Make sure Brackets isn't running at the same time. The build will fail silently if the .exe file is currently in use (see bug).
Try with a fresh git clone of the repo. If your brackets-shell local copy has been around for a while, sometimes the build & deps folders can get in a bad state. (I'm assuming you haven't modified the source at all. If you have, try with an unmodified copy of the source first to make sure it builds correctly without any of your changes).
Check that python --version shows 2.7.x
Verbose build output would also be helpful in diagnosing issues like this, but unfortunately there's not yet an easy way to get that...
If you follow the instructions on bracket-shell's wiki page, the Windows executable should be created in the Release directory.