I'm trying to use koRpus in R to do lemmatization on a Linux server running RHEL6. Last week when I had MRO (Microsoft R Open) 3.2.3 installed the code below worked great:
library(koRpus)
lw = c("dancing","flying","flew")
res = treetag(lw,treetagger="manual",format="obj",TT.tknz = F, lang="en",
TT.options=list(path="/usr/local/bin/TreeTagger",preset="en"))
Now that I'm running MRO 3.3.0 though I get the following error:
Error in grepl("(^\\p{P}*\\p{L}\\p{M}*\\.)", tkn, perl = TRUE) :
invalid regular expression '(^\p{P}*\p{L}\p{M}*\.)'
In addition: Warning message:
In grepl("(^\\p{P}*\\p{L}\\p{M}*\\.)", tkn, perl = TRUE) :
PCRE pattern compilation error
'support for \P, \p, and \X has not been compiled'
at 'p{P}*\p{L}\p{M}*\.)'
OK, so that means my PCRE needs to be recompiled with unicode support. In fact when I run the code below I see that's the exact issue. I also see that I'm running version 8.37.
pcre_config()
#> UTF-8 Unicode properties JIT
#> TRUE FALSE FALSE
extSoftVersion()
#> zlib bzlib xz
#> "1.2.8" "1.0.6, 6-Sept-2010" "5.2.2"
#> PCRE ICU TRE
#> "8.37 2015-04-28" "57.1" "TRE 0.8.0 R_fixes (BSD)"
#> iconv
#> "glibc 2.12"
Now, I went ahead and installed 8.39 and with (hopefully) the right flags set.
./configure --enable-utf8 --enable-unicode-properties
make
make install
So now when I run pcretest -C I get
PCRE version 8.39 2016-06-14
Compiled with
8-bit support
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Parentheses nest limit = 250
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
But when I launch R again my pcre_config() yields identical results, the treetag call fails identically and extSoftVersion() still reports 8.37.
What do I need to do for R to start using the new PCRE version?
Deeper and deeper...
R apparently no longer ships with PCRE (per https://mran.microsoft.com/news/#r330) as of 3.3.0 so it (supposedly) relies on the system PCRE installation. I went through the server and removed every PCRE file identifiable (complete uninstallation) and R still reports PCRE 8.37 2015-04-28 which suggests the MRO 3.3.0 for RHEL 6 includes PCRE despite claiming otherwise. Additionally, the grepl command still fails with the error too, so it's not just an issue with extSoftVersion.
Related
I am building Qt6 for STM32MP157
Qt sources downloaded v6.1.2
Platform: Ubuntu 18.04.5 LTS
STM32 SDK version: v2.0.0
The same build succeed for host machine (to generate qt host tools)
But when I run it with toolchain file for stm32mp157, it fails with error by perl on syncqt.pl line 55:
use English qw(-no_match_vars );
The error message is as follows:
-- Running syncqt for module: 'QtCore'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_MEASUREMENT = "ur_PK",
LC_PAPER = "ur_PK",
LC_MONETARY = "ur_PK",
LC_NAME = "ur_PK",
LC_ADDRESS = "ur_PK",
LC_NUMERIC = "ur_PK",
LC_TELEPHONE = "ur_PK",
LC_IDENTIFICATION = "ur_PK",
LC_TIME = "ur_PK",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Can't locate English.pm in #INC (you may need to install the English module) (#INC contains: //usr/lib/perl5/site_perl/5.30.1 //usr/lib/perl5/vendor_perl/5.30.1 //usr/lib/perl5/5.30.1 /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/site_perl/5.30.1/x86_64-linux /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/site_perl/5.30.1 /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/vendor_perl/5.30.1/x86_64-linux /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/vendor_perl/5.30.1 /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/5.30.1/x86_64-linux /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/5.30.1 .) at /home/dyasin/repos/qt6/qtbase/libexec/syncqt.pl line 55.
BEGIN failed--compilation aborted at /home/dyasin/repos/qt6/qtbase/libexec/syncqt.pl line 55.
CMake Error at qtbase/cmake/QtModuleHelpers.cmake:206 (message):
Failed to run syncqt, return code: 2
Call Stack (most recent call first):
qtbase/src/corelib/CMakeLists.txt:29 (qt_internal_add_module)
-- Configuring incomplete, errors occurred!
See also "/home/dyasin/repos/qt6/build/CMakeFiles/CMakeOutput.log".
See also "/home/dyasin/repos/qt6/build/CMakeFiles/CMakeError.log".
Where it fails to load English.pm
I have noticed a pecularity that perl uses a different version when compiling for stm. So the build system is using perl from stm SDK. And STM SDK has no English.pm
my question is how we can use perl from host system?
My mistake. In my toolchain file, I had overridden the "CMAKE_PROGRAM_PATH" to find SDK compiler and other programs, I had to adjust it so that it could find perl from host system.
R 4.0.3 GUI 1.73 Catalina build (7892) for mac
Error in load("/Users/***/Desktop/R2019.r d a") :
bad restore file magic number (file may be corrupted) -- no data loaded
In addition: Warning message:
file ‘R2019. r d a’ has magic number 'PK-'
Use of save versions prior to 2 is deprecated
When I call Rscript.exe for Version 3.5 of R, it is unable to open the file if the file name or path has a space in it. I saved 2 files with the code:
cat("What do you get when you multiply 6 * 9?")
as C:\foo bar.R and as C:\foo_bar.R
When I in a DOS command window try to run these using version 3.4.3 and 3.5:
C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo bar.R"
What do you get when you multiply 6 * 9?
C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo_bar.R"
What do you get when you multiply 6 * 9?
C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo bar.R"
Fatal error: cannot open file 'C:\foo': No such file or directory
C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo_bar.R"
What do you get when you multiply 6 * 9?
C:\>
When I try to run the file with a space in the name in version 3.5.0 of R, there is a fatal error saying there is no such file.
Thanks Edward Carney, I emailed the address you listed, and got a response from Tomas confirming it is a bug, and providing a workaround until it is fixed:
A quick workaround before this gets fixed is to add an extra first argument that has no space in it, e.g.
Rscript --vanilla "foo bar.R"
The problem exists on all systems, not just Windows.
This has now been corrected in the Development version, and there is a binary build for Windows at:
https://cran.r-project.org/bin/windows/base/rdevel.html
It has also been corrected in the patched version, and there is a binary build for Windows at:
https://cran.r-project.org/bin/windows/base/rpatched.html
I can't get the h2o to work in my R. It shows the following error. Have no clue what it means. Previously it gave me an error because I didn't have Java 64 bit version. I downloaded the 64bit - restarted my pc - and started the process again and now it gives me this error.
Any suggestions?
library(h2o)
----------------------------------------------------------------------
Your next step is to start H2O:
> h2o.init()
For H2O package documentation, ask for help:
> ??h2o
After starting H2O, you can use the Web UI at http://localhost:54321
For more information visit http://docs.h2o.ai
----------------------------------------------------------------------
Attaching package: ‘h2o’
The following objects are masked from ‘package:stats’:
cor, sd, var
The following objects are masked from ‘package:base’:
%*%, %in%, &&, ||, apply, as.factor, as.numeric, colnames, colnames<-, ifelse,
is.character, is.factor, is.numeric, log, log10, log1p, log2, round, signif, trunc
> h2o.init(nthreads = -1)
H2O is not running yet, starting it now...
Note: In case of errors look at the following log files:
C:\Users\ADM_MA~1\AppData\Local\Temp\RtmpygK1EJ/h2o_Adm_Mayur_started_from_r.out
C:\Users\ADM_MA~1\AppData\Local\Temp\RtmpygK1EJ/h2o_Adm_Mayur_started_from_r.err
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
Starting H2O JVM and connecting: ............................................................
[1] "localhost"
[1] 54321
[1] TRUE
[1] -1
[1] "Failed to connect to localhost port 54321: Connection refused"
[1] 127
Error in h2o.init(nthreads = -1) :
H2O failed to start, stopping execution.
In addition: Warning message:
running command 'curl 'http://localhost:54321'' had status 127
Screenshot for h2o error in R
Based on the error message and the troubleshooting we carried out in the comments, it seems that you are using a version of Java (Java 1.9) which is too new for your version of H2O.
Your 2 options seem to be:
Verify that your version of H2O is up to date. If not, update it.
Download a compatible version of Java, i.e. Java 1.8 (you can just use it for this 1 task rather than for everything, if you prefer)
Note that on the main documentation page of H2O v3 it says:
Java 7 or later. Note: Java 9 is not yet released and is not currently
supported.
But at the same time they usually have several Beta and Alpha development branches going, so you might find one of those that works with Java 9.
So if anyone else is facing the same issue.
My recommendation (after spending about over 10 hours trying to figure this out (worth mentioning)) is check your version of java.
If it's higher than 8 then either keep it remove it.
I removed it because I didn't want to deal with setting the JAVA Home function in R and to reduce work.
Make sure you install Java 7 or 8 but a 64 bit version. h2o doesn't work if you have 32 bit.
Then voila! Just go ahead and type install.package('h2o') in your rstudio.
I wanted to be extra careful in my final attempt of this so unloaded and uninstalled the library because I had installed it before and then installed it again and then loaded it using library(h2o) and then h20.init() worked just fine.
When I submit my package to CRAN, it does not pass the automatic incoming checks with a following warning:
* checking whether package 'EpiILM' can be installed ... WARNING
Found the following significant warnings:
Warning: GNU Extension: Different type kinds at (1)
and corresponding log file says
Epimcmc.f95:440.25:
psi= min(1.0,exp(ratio))
1
Warning: GNU Extension: Different type kinds at (1)
When I tested my package using R CMD CHECK and R CMD CHECK --as-cran, both result no warnings or notes. I am using an R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch" on my MacOS and codes are written in Fortran 95.
Any suggestions?
Your code is too short to diagnose exactly, but it can be probably inferred safely what the not-shown part of the code is.
Your ratio is of different kind than default one, probably `double precision.
But 1.0 is the default kind (aka. single precision).
Mixing different kinds in min() is not allowed in Fortran, but you do this in:
min(1.0,exp(ratio))
To fix the problem, use literals of the same kind as ratio is. So if it is a double precision, you can use:
min(1.0d0, exp(ratio))
and if it is some real(rk) you can use
min(1.0_rk, exp(ratio))
The real(.., kind=rk) function can also be used.
The warning says that the GNU Fortran compiler recognizes it is not allowed in Fortran, but allows it as a non-standard extension. Whether using this extension is allowed by the CRAN coding standards is a different question. Probably no, if it got rejected.