I downloaded the binary release of Restcomm smsc from the link [1] mentioned in installation guide. When i unzipped it, I couldn't find hlr-simulator in it. It is supposed to be there as per the binary structure explained in the guide.
Should i build it separately?
[1] https://github.com/RestComm/smscgateway/releases/latest
Related
I work in a corporate environment that uses Microsoft Windows Defender Application Control (WDAC) to provide security. This blocks unsigned EXE and DLL files from being installed on devices. R packages which use DLLs fail to install. The workaround to this is provide an R installation from an approved central source which also copies over a default set of packages, such as tidyverse, data.table etc. to the R library. Users can continue to install additional packages which are built with native R, but run into issues if they try to install, build from source, or update packages with DLL files in.
Is there a way to check whether a package uses DLL files in advance of installation?
Output something like:-
check_dll(foo)
result: "This package and its dependencies have no DLL files. You can install this package"
check_dll(bar)
result: "bar does not have any DLL files, but one dependency, OOF, uses DLL files.
You have already have a version of OOF installed so it should be safe to install bar"
check_dll(foobar)
result: "foobar has a DLL. Do not attempt to install foobar".
check_dll(RABOOF)
result: "RABOOF does not have any DLL files, but one of it's dependencies,
foobar, does have a DLL file. Do not attempt to install RABOOF".
tools::package_dependencies() will list the package dependencies, but nothing else.
Downloading the zip file from CRAN and inspecting it for a libs/x64 folder with contents will work, but seems a heavyweight approach. Theoretically if a package has lots of dependencies this could result in downloading a lot of files unnecessarily.
Look for the NeedsCompilation field in the DESCRIPTION file. If it is "yes", there will be a DLL. If it is "no", there probably won't be. (If it is not there, the package wasn't built properly, so all bets are off.)
The test is not perfect, because packages can put DLLs into the inst folder to get them installed without compiling them, though CRAN isn't supposed to allow that: "Source packages may not contain any form of binary executable code." But packages like pak (mentioned in the comments) may be allowed to get around this rule, e.g. by downloading binaries, so the test isn't perfect. You will also need to put together a blacklist of packages that will fail your WDAC tests even though they claim not to need compilation, containing pak and others like it.
The NeedsCompilation field is included as a column of the result of available.packages(), so it is very easy to access without trying to install the package.
I have accepted the answer from user2554330 as the best solution. It makes use of the normal set of commands used for package management; and the matrix generated by available.packages() can be passed to tools::package_dependencies(), removing the need for multiple internet queries.
For completeness I am documenting another possible solution. A script could query the unofficial CRAN Github mirror https://docs.r-hub.io/#cranatgh and look for a /src directory in each package project.
I'm trying to add sample metadata to a very small BIOM file (658 Bytes, 2 samples) using the command biom add-metadata (the metadata file is 206 Bytes). However, I found that using biom version 2.1.8 resulted in a much bigger file (36.17 KB) than when I used biom version 2.1.7 (615 Bytes). Furthermore, the file created with v2.1.8 does not seem to be a plain text file, as there are many illegible characters when I tried opening it using "more" on terminal or using text editor, while the file created with v2.1.7 is a normal text file.
The machine that I used already has biom v2.1.7, but when I tried to install both v2.1.7 and 2.1.8 using conda, I saw the same behavior. Then I tried to install v2.1.8 using pip (in a conda environment), and still, the difference that I mentioned above is there.
I wonder if this is normal or expected.
Thanks in advance for your input!
would it be possible to copy/paste the commands used? The changelog entries for 2.1.7 - 2.1.8 can be found here, although I'm not aware of changes that would have modified the output behavior of add-metadata. Is it possible that the h5py package was not installed in the environment with 2.1.7?
How to get the UUID of the third-party package without installing it on my computer?
Now I can only open the project.toml file to view after installing the third-party package locally on my computer?
import Pkg
Pkg.METADATA_compatible_uuid("JuliaAstro")
Credit goes to Stefan K.
https://discourse.julialang.org/t/a-quick-and-dirty-tool-for-generating-project-toml/11375/22
The first thing that comes to my mind would be to just find the package on Github and look into its Project.toml.
However, if you have an updated Pkg system set up for the default package repository, there should also be a folder like ~/.julia/registries/General, containing in the file Registry.toml a list of all packages of that repo sorted by UUID, and subdirectories for each letter from A to Z with folders for all packages, containing the metadata of every package.
(This is in my 1.0 installation -- it could have change a bit since then, but probably not much. Have a look at Pkgs documentation for details.)
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 am including a binary executable with a package that I am creating. I have specified its path in the /inst/ package subfolder using a file named BinaryFiles located in the root of the package installation.
Is it necessary to note elsewhere that it will only run under Windows (both 32 and 64 bit architectures) e.g. in the DESCRIPTION file? (In addition to the documentation where this will be stated repeatedly!)
e.g. as:
SystemRequirements: Windows
or something to that effect?
There is a optional entry in DESCRIPTION specifying the operating system that is meant for this. So please see Section 1.1.1 of 'Writing R Extensions' for full details -- but in short, you want to use
OS_type=windows
here.