How can I set custom version of IExpress output file. I found this article http://www.mdgx.com/INF_web/custver.htm and everything except File version is working fine. Whatever I try I can't seem to set custom file version. It looks like IExpress is ignoring FileVersion setting in SED file and always uses the version of wextract.exe. I have a IExpress version 9 installed.
There are actually two different file version numbers: the binary version number (stored as FILEVERSION in the resource) and the string version (stored in the StringFileInfo block as FileVersion). It seems that IExpress only changes the string version, not the binary version.
(As usual, MSDN has all the gory details on the VERSIONINFO resource if you're interested.)
You might have some luck with a version-changing utility. There are several good answers on this question about changing version numbers.
I tried one called StampVer and it seemed to do the trick.
Related
I'm trying to make the my code portable to Windows and realized that even though I use file.path to create paths still the readRDS function won't work, for example:
file.exists('C:/temp/HarvardX-Skillability/data/rds/Users.rds')
> TRUE
readRDS('C:/temp/HarvardX-Skillability/data/rds/Users.rds')
> Error in readRDS("C:/temp/HarvardX-Skillability/data/rds/Users.rds") :
error reading from connection
I also tried:
file.exists('data/rds/Users.rds')
> TRUE
readRDS('data/rds/Users.rds')
> Error in readRDS("data/rds/Users.rds") : error reading from connection
Why is that? and how can I fix it? In Ubuntu 18.04 works perfectly ...
The problem seems to be with downloading/cloning the files from GitHub. After running git clone on your repository, when I open my local copy of Tags.rds in a text editor I see this:
version https://git-lfs.github.com/spec/v1
oid sha256:b4a2cb3775126a3895e9533ef9ef4ad786b2021cfd1660b07028fbef85b025bb
size 641098
(this is the entire contents of the file). Furthermore, running file Tags.rds (in a Terminal on MacOS) reports Tags.rds: ASCII text. (All of the .rds files are like this.)
The GitHub web interface confirms that your files are OK on the repo:
This question looks related. After installing Git LFS and running git lfs pull, I get the full file downloaded (and readRDS() seems to work fine).
The culprit to the OP was something really unexpected, I also didn't provide the information for it because I couldn't suspect this was the issue.
The problem was those files were being downloaded automatically using download.file(url, filePath, extra="L") and in Windows this is known to cause issues with binary files that are not the expected ones. This is why the rds files were unrecognizable.
I found out while building exception handling recovery code that was looking to download the same files from a Dropbox folder and then came to the same issue, therefore it wasn't because of Git LFS.
The OP solution was to add the argument download.file(..., mode="wb").
See the question R trouble unzipping file under Windows
First of all, I am working on a Mac. I am trying to install Blotter from GitHub. I found several descriptions of how to do that but my RStudio tells me that I am missing Building tools and gives me a link (https://www.cnet.com/how-to/install-command-line-developer-tools-in-os-x/) where it is described to do that. So far so good. I downloaded Xcode and the command line tools for Mac and installed those. Nothing changed even after restarting R. Then I found this https://cran.r-project.org/bin/macosx/tools/. I installed it and during that, it told me that I had to do the following
"This package will install clang 6.0.0 for OS X 10.11 (El Capitan) or higher with OpenMP support in /usr/local/clang6
In order to use this compiler you have to add /usr/local/clang6/bin to the PATH environment variable such as
export PATH=/usr/local/clang6/bin:$PATH"
So I changed the environmental variable path as follows http://blog.tonytsai.name/blog/2018-05-07-setting-path-variable-for-gs-command-in-rstudio/.
How I changed the PATH variable.
Again I restarted R but still, nothing changed. I still get the notice that the building tool is missing.
Somehow it seems to me that I installed everything correctly but R doesn't recognize the Programmes. Does anyone have an idea? I tried to search for settings to tell R that I installed the command line tool but couldn't really find anything helpful.
Ok, a bit of an update.
Best I can see it that Blotter is built and stored on R-Forge packages under a package called RStrategist
In R console type/cut & paste this.
install.packages('RStrategist',repos='http://R-Forge.r-project.org')
See R forR-Forge for more details. Once this has been installed run instead.
library(RStrategist)
Unfortunately, I am not willing to install this package and see if it works mainly because 1) don't need it nor know how to use it, 2) not sure how good packages are from R-forge, though it seems legit, but, this brings me back to point one.
So before i read the updated answer of Conrad Thiele i was trying around bit. Basically i deleted R, R Studio, Xcode and Command Line tools. Then i installed Xcode, Command Line tools, R and RStudio. Then i followed the notice on https://cran.r-project.org about the tools and installed both stated tools. As mentioned in the original question the Clang package tells you to change the Environmental Variable. And there was the mistake i believe. I originally simply pasted "PATH=/usr/local/clang6/bin:$PATH" into the the ".Renviron" file. With reading up online i noticed that "export PATH=/usr/local/clang6/bin:$PATH" is actually a Command for the Mac Terminal. After executing it, it sill didn't work but then i remembered that i still had the Path "PATH=/usr/local/clang6/bin:$PATH" in the the ".Renviron" file. Once i deleted that it worked. So i guess the key was that with changing the Environmental Variable correctly R found the connection with the right tool. Patients paid off.
When running the checks for my R-package (via devtools::check()) I face the warning ''qpdf' is needed for checks on size reduction of PDFs. I found this question were it was suggested (if I understood the answer correctly) to run Sys.which(Sys.getenv("R_QPDF", "qpdf")) and see whether qpdf is found or not. In my case this just returns
qpdf
""
so, I think I didn't install qpdf correctly. Unfortunately it seems to be quite complicated to install qpdf on Windows. My first side question is: does it really is so painful and complicated to install qpdf for Windows or is there an easy solution?
I've followed the instructions until it is said to add C:\MinGW-w64\bin and C:\MinGW-w64\lib\mingw to the PATH variable. But then I don't find further specific instructions to install qpdf, only about how to build qpdf with different other programs. The second side question is: is my assumption correct that after I've build qpdf it is installed? But the real question is: What is the best way to build qpdf? I tried the ./config-mingw32 and ./config-mingw64 commands from the section "Building with MinGW" in my C:\MinGW\msys\1.0\bin\bash.exe but got the error messages ./config-mingw32: No such file or directory and have no idea how to fix this issue.
I'm using Windows 10, R version 3.3.2 Patched (2017-01-07 r71934) -- "Sincere Pumpkin Patch" and RStudio 1.0.136.
You basically do not need to build the file on windows. Please follow three steps below:
Download qpdf for windows from https://sourceforge.net/projects/qpdf/?source=typ_redirect
Extract files in a temp folder
Copy the contents of the bin folder to %SystemRoot%\System32
job done!
Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"C:\\WINDOWS\\SYSTEM32\\qpdf.exe"
To flesh out an answer provided elsewhere:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 10.0.1 is listed here).
Rather than copying files to C:/Windows/System32, a potentially safer option is to extracted the zipped qpdf directory to C:\Program Files. If you do this, you'll need to add C:\Program Files\qpdf-version_number\bin to your system PATH under the environment variables.
To do this within R, run Sys.setenv('PATH' = paste0('C:\Program Files\qpdf-version_numer\bin;', Sys.getenv('PATH')))
To do this in Windows, open the start menu, type "edit the system environment variables" to open the System Properties, and at the bottom of the "Advanced" tab click "Environment variables". Find the "Path" entry under "System variables" and click "Edit". Then, re-start R so it picks up the modified PATH.
One further step may be required to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning, as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. This done, Windows will recognize the file as safe to run and allow other software, including R, to use it.
I'm getting this error in VS Code:
Could not start the julia language server. Make sure the configuration setting julia.executablePath points to the julia binary.
In user settings I put
"julia.executablePath": "c:\\Program Files\\Julia\\Julia-0.5.0\\bin\\julia.exe"
which is a correct executable path.
Julia works without a problem in console and VS Code worked fine with older extension 0.4.2. I've tried reinstalling both the extension and VS Code, but it didn't help.
What am I doing wrong?
I had the same problem, just run Julia REPL and switch to pkg mode with ] and add LanguageServer package with add LanguageServer and restart vs code.
VS Code settings don't seem to always play nice with backslashes. Try instead single slashes, even on Windows:
"julia.executablePath": "c:/Program Files/Julia/Julia-0.5.0/bin/julia.exe"
It may, however, also be a problem with the blank in 'Program Files', in which case the legacy 8.3 filename convention could work:
"julia.executablePath": "c:/PROGRA~1/Julia/Julia-0.5.0/bin/julia.exe"
Note that you would typically have both 'C:\PROGRA~1' and 'C:\PROGRA~2' pointing to 'C:\Program Files' and 'C:\Program Files (x86)', respectively. Find the correct one from the console.
Have a look if the 'LanguageServer' package is actually installed/somehow uninstalled, this happened to me. After manually installing it, it was all fine and dandy again.
Indexing all the packages still takes ages, though.
https://github.com/JuliaEditorSupport/julia-vscode/issues/405
This can happen if the VS Code extension doesn't support the current version of Julia.
Also check that the path is pointing to the julia.exe executable inside the bin folder.
C:\Users\yourname\AppData\Local\Julia-0.5.0\bin\julia.exe
because there is also another one that doesn't work.
C:\Users\yourname\AppData\Local\Julia-0.5.0\julia.exe
Reinstalling Julia solved this for me, I tried the previous answers
It is probably due to a SysImage you have compiled and replaced the original sys.dll file with that. Try to check the path C:\Users\User\AppData\Local\Programs\Julia-1.7.3\lib\julia or any other path you have installed Julia and see if a sys.dll.backup exists there, together with a sys.dll file. Rename the sys.dll to sys.dll.old and rename the sys.dll.backup to sys.dll. Then restart julia or VS Code.
I have tried a lots of advice to help to set up the CDB debugger in Qt Creator but when using it that thing still takes ages to load up local variables.
My setup:
Windows 10 64-bit
Qt 5.6 (installed with sources)
Qt Creator 3.6.1
Microsoft Visual Studio 14 (2015) (both 32-bit and 64-bit compilers)
Windows SDK (for debugging tools = CDB)
The General tab in Options->Debugging lists auto-detected sources:
Source: Q:/qt5_workdir/w/s
Target: C:\Qt\5.6\Src
My symbols server and cache are set up in CDB Paths like this:
srv*http://msdl.microsoft.com/download/symbols
cache*C:\Qt\CDB-symbols-cache
On first run of the debugger it populates this directory with 70mb of (presumably downloaded) data but it does not seem to change afterwards on subsequent runs.
I suspect either the sources being loaded takes a long time (although I have a SSD) or that the CDB is re-downloading the symbols instead of using the cache. Any advice?
EDIT: As per request, result of .sympath command on my system:
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred
srv*
I had the same problem with QtCreator 4.12 which was solved by removing AppData\Roaming\QtProject\default.qws as suggested by Abstraction in the comments above.
I had the same issue with QtCreator 4.0.2 and VS 2015. Here is what I did.
Downloaded the microsoft symbol package from symbol packages
Copied it to a local folder(D:\Symbols)
In QtCreator , Tools->Options->Debugger->CDB Paths select "Insert Symbol Server" and select the local folder. Will look like the below screen.
I tried all the above and did not worked, however one thing worked: renaming the file default.qws
Usually it would take 10 seconds to load the debugger and it went to 10 minutes. Analyzing deeper I found out that the problem is with the breakpoints: if a breakpoint is on a file which is not part of the project, the debugger attempts to resolve the breakpoint for each loaded module/DLL, making the process incredibly slow.
The solution is to edit the file default.qws and remove those breakpoints which are set to files that don't exists anymore and you will get the speed as before.