Is it normal that the result of biom add-metadata using v2.1.8 is different from v2.1.7? - biom

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?

Related

Customize R linters in VSCode

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.

Can I change the location of Homebrew FFTW install? R can't seem to read FFTW3.h file located in Cellar folder

I'm trying to install wholebrain by Daniel Fürth, following the instructions on the macosX install page (available here). I am running MacOS Big Sur 11.5.2, R 4.1.2, and RStudio 2021.09.1.
Unfortunately, the program is not straight-forward to install and requires significant developer tools to work correctly. I'm not a programmer and have almost no experience with coding, so I've been mucking through the instructions for two days now trying to get the install to work correctly and I'm firmly stuck on the final step.
In RS, when I run, devtools::install_github("tractatus/wholebrain", INSTALL_opts=c("--no-multiarch")) I get the following error message:
/bin/sh: pkg-config: command not found filter.cpp:9:10: fatal error: 'fftw3.h' file not found #include "fftw3.h" ^~~~~~~~~ 1 error generated. make: *** [filter.o] Error 1 ERROR: compilation failed for package ‘wholebrain’
I have been trying to figure out what this means for quite awhile now and I think I've narrowed it down to R is not reading the location of the fftw header file from where it was installed by Homebrew. (I could be totally wrong, again- not a programmer)
From what I understand, Homebrew always installs under opt/homebrew/cellar. And, in fact, in there is the compiled fftw program with the needed "fftw3.h" file. But for some reason, RStudio is not able to find and read the file in that location.
From random googling and reading of other posted issues, I think that RStudio may expect the file to be under usr/local/include. Can I just copy and paste the header file into that folder? Or will I be screwing something up if I do that? I am totally intimidated by fftw's description of manual compilation so I don't really want to attempt that. Is there a way to change where R is looking for that header file? I already set my wd to "/" so shouldn't R be able to access any folder on my computer?
I want to post an answer here for anyone who comes after me with the same issue. It came down to RStudio not recognizing the programs Homebrew had installed because it wasn't reading the file location where Homebrew saves them. Homebrew always installs programs in /opt/homebrew/... Here is what I had to do:
In RStudio, open your Renviron file using this command: usethis::edit_r_environ()
In the file that opens (which for me was totally blank), type: PATH=/opt/homebrew/bin:${PATH}, or whatever your particular path you want prepended to the Renviron path is.
Quit RStudio and, when prompted, save. Re-open RStudio and run Sys.getenv("PATH") to check. Your new path (in the example above, '/opt/homebrew/bin') should now be prepended to the list of paths that RStudio will use when looking for programs/files. For me this now looks like /opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Applications/RStudio.app/Contents/MacOS/postback
Finally, I want to say thank you very much to Mark Setchell who really helped point me in the correct direction!

Older version of R in mac OS X 10.10.5

I have a problem downloading R in my mac which I have been dealing with for many hours now.
My purpose is to use propensity score matching in SPSS (from source forge). I am using SPSS version 22 on my mac OS X yosemite 10.10.5.
After reading a lot on the different sites I need to use R.2.15 for SPSS 22 in order to use the psmatching 3.03 on source forge.
However, I cannot seem to install R 2.15 when I run the installation package. When I am going to select destination on the macintosh HD, it says that R2.15.0 for Mac OS X 10.5 or higher can’t be installed on this disk. How is this possible? My OS X version is higher than the demanded version for R 2.15.
Any ideas how to make the installation?
I've run into this problem myself: SPSS versions require very specific versions of R to be installed for the R Integration plug-in to work. An older or newer version of R will not suffice.
I think the installation error is due to the old R installer's attempt to verify a sufficiently high OS X system version. But it doesn't recognize 10.10+ as being higher than 10.9 (or 10.5 for that matter).
The link below has information about disabling OS X El Capitan's System Integrity Protection, in order to change the OS X file /System/Library/CoreServices/SystemVersion.plist, so that a false system version can be reported to the installer.
https://forums.developer.apple.com/thread/4138
A safer method might be to manually place the files from R's 2.15 installer. There's an apparent complication with my attempt at that, though. I opened the R 2.15.pkg installer file, found a file 'payload' inside, used 'tar -xzvf Payload' to extract contents, and moved those contents into /Library/Frameworks/R.framework/Versions/2.15. In retrospect, it may be most useful to temporarily re-alias "Current" in the R.frameworks folder so that it points to 2.15 version while the installer completes. Instead, I did the following to get around installer error messages I found in the installer log file, which worked for me:
The SPSS Essentials for R installer reported that the install location does not contain R 2.15. Examining the error log files led me to believe that the installer's attempt to verify the R version inappropriately navigated to the "Current" version (aliased to a specific version, likely not R 2.15 if 2.15 was installed manually), even if the directory for 2.15 was specifically entered into the installer. It then seeks a couple of i386 subdirectories that no longer exist as of R 3.2.2. So (for my case) I manually created "/Library/Frameworks/R.framework/Versions/3.2/Resources/bin/exec/i386" and copied version 2.15 of the R unix executable, and did similarly for "/Library/Frameworks/R.framework/Versions/3.2/Resources/etc/i386", copying in the ldpaths file that the installer seeks. Doing so finally allowed the SPSS Essentials for R installer to complete. In retrospect, temporarily re-aliasing "Current" in the R.frameworks folder might have been a more direct approach, but I haven't tried that as of right now.
For what it's worth, I was able to install an older version of R (for a different purpose, but I found this page while trying to figure it out), without having to temporarily change the version of OS X (or macOS) on my system. That seemed dangerous to me, and I wanted a simpler fix.
What worked for me was extracting the installer pkg, modifying the version check in there, and then packaging it up again.
Downloading the pkg installer from CRAN
open Terminal and cd to the directory where the installer is: e.g.,
cd ~/Downloads
use pkgutil to expand the pkg file you downloaded
pkgutil --expand R-2.15.0.pkg R-2.15.0
This creates a folder named R-2.15.0 (You can name it whatever you want in the command above). In that folder is a text file called Distribution.
Open the Distribution file in a text editor (e.g., TextEdit), and
modify the function at the beginning that checks the version of OS
X. for example, if it requires Leopard, there will be a line that
looks like this:
if(!(my.target.systemVersion.ProductVersion >= '10.5.0')) {
...
}
Notice that version string for comparison is a string (not a number!), so any version past 10.9 (10.10 and up) will fail that check ('10.10' sorts between '10.1' and '10.2', which is less than '10.5').
All I did was change the minimum version here ('10.5.0') to '10.1'. So the same line reads:
if(!(my.target.systemVersion.ProductVersion >= '10.1')) {
Save the Distribution file.
Go back to terminal and re-package the directory you created in step 3:
pkgutil --flatten R-2.15.0 R-2.15.0-HACKED.pkg
You can call the new pkg whatever you want, as long as you will recognize it.
The resulting package (R-2.15.0-HACKED.pkg, in this example) will now run on any version of OS X higher than or equal to the version you specified (in this case, 10.1 and up).
Disclaimer: I actually tested this with R-2.12.0 (and it worked), but I provided example code for R-2.15.0 to answer the original question. It should be similar with any R installer pkg for OS X that uses a similar version string to check for compatibility before installation.

After running R CMD Check, the mypackage.Rcheck directory with PDF manual disappeared

I have installed Rtools v.31 and MKTeX2.9 on my laptop before building my R package. After I ran R CMD check, a directory called mypackage.Rcheck and the source file mypackage_1.x.tar.gz appeared, and while RStudio build package function is checking everything, there is no warning or error message, but at the end when it said (as follows), the corresponding mypackage.Rcheck directory which is supposed to contain the PDF manual disappeared:
checking PDF version of manual ... OK
DONE
NOTE: There were 3 notes.
See
'C:/.../package/mypackage.Rcheck/00check.log'
for details.
R CMD check succeeded
I thought it might be a version conflict between Rtools and R because I'm using R13.1.2 and Rtools v.31, where on the http://cran.r-project.org/bin/windows/Rtools/ website, it said the image isn't frozen (which I don't understand what it means). But I tried all the suggested compatible version pairs between Rtools and R, and still couldn't get it working. So I think this disappearing of mypackage.RCheck is not due to version conflict.
I don't think it's MiKTeX problem because apparently pdf is generated, but was consequently removed. I also tried using --options in R CMD check, but there is no way to force generation of pdf manual, plus pdf was generated at one point. I also read one post on this website, suggesting the use of Rutils function Rd2pdf: "R CMD Rd2pdf mypackage", but I can't run in on windows, and Rutils package is not available for R13.1.2.
can someone suggest the source of the problem or if they have seen this problem before and was able to fix it?
In RStudio: Tools -> Global Options -> Packages. There is a setting "Cleanup output after successful R CMD Check". If this is checked it removes the package.Rcheck folder after a successful check. If you uncheck this setting, the package.Rcheck folder is not removed and you will find the reference manual pdf there.
A common problem for mysterious disappearances of files from R tarballs is to accidentally specify that they should be ignored in the .Rbuildignore file. The lines in that file are regular expressions, so leaving off the anchors ^ and $ can cause them to match more files than you intended. For example,
vig.e
matches vignette.pdf (because there are no anchors to the start and end of the name, and the
dot means "any character".

IExpress output file version

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.

Resources