radfordneal / pqr Goto Github PK
View Code? Open in Web Editor NEWpqR - a "pretty quick" version of R
License: GNU General Public License v2.0
pqR - a "pretty quick" version of R
License: GNU General Public License v2.0
Hi,
I would like to check out pqR but I already have R 3.3.1 installed with which I do all my work. It is easy enough to install pqR in my $HOME by changing the prefix. but I don't want to have pqR mixed up with my current default R work directory, .libPaths and other environmental variables. I would like to have a separate .Rprofile to customise pqR.
I can't find any info about having two separate .Rprofile but I think there must be a file somewhere which instructs R (and pqR) where to look for .RProfile (set up at compile time perhaps) The idea is to make a separate .RProfile in a different directory than ~/ and tell pqR to use that instead. Is there a way to do it?
OS is Ubuntu 16.04. pqR 2.15.1, it is installed in $HOME/opt/pqR
Thanks.
p.s I tried creating a file pqR/lib/R/etc/Rprofile.site where I only include the single line
setwd("~/pqR")
but when I start pqR I get an error
Error in eval(expr, envir, enclos) :
could not find function ".getNamespace"
Error: unable to load R code in package ‘neuralnet’
DEFS=-DHAVE_CONFIG_H -fopenmp
CSOURCES = helpers.c helpers-app.c
I discovered the following bug in pqR-2013-06-28 while making changes to get pqR to follow a consistent set of conventions regarding in-place modifications to objects and use of NAMEDCNT:
a <- list(x=c(1,2),y=c(3,4))
b <- as.pairlist(a)
b$x[1] <- 9
print(a)
The value printed for a has a$x[1] changed to 9, when it should still be 1.
This bug also exists in R-2.15.0 and R-3.0.1. It is now fixed in pqR development branch "14".
Typing news() at the command prompt gets an error, rather than the news, because news() doesn't like the version of pqR being a date rather than three numbers. One can instead use RShowDoc("NEWS","txt").
plot ( 1 : 10 , 1 : 10 , x = mean ( try ( plot ( lm ( try ( try ( body : body ( f ) <- body ( mean ) ) + id.n ( f ) ) ~ 1.000000 , 1.000000 , 1.000000 , log ( TRUE ) ) ) ) ) )
Error in try(body:body(f) <- body(mean)) : could not find function ":<-"
Error in try(try(body:body(f) <- body(mean)) + id.n(f)) :
could not find function "id.n"
[1] 7799 floating point exception ./bin/R
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 15.1
year 2020
month 07
day 23
svn rev 58871
language R
version.string R version 2.15.1 (2020-07-23)
nickname
pqR.base.version 2.15.0
pqR.base.date 2012-03-30
pqR.base.year 2012
First, I want to show my deep admiration to your great work. It is incredible that you are maintaining this project by one person. I was wondering if it is possible that your pqR code be merged to R core, since that will improve the performance.
While modifying how assignments with "[[<-" are implemented, I have found more bugs, which are present in R-2.15.0 and R-3.0.1 as well as pqR-2013-06-28.
They are illustrated by the code below:
v <- c(10,20,30)
v[[2]] <- NULL # wrong error message
x <- pairlist(list(1,2))
x[[c(1,2)]] <- NULL # wrongly gives an error, referring to misuse
# of the internal SET_VECTOR_ELT procedure
v<-list(1)
v[[quote(`abc`)]] <- 2 # another internal error, this time for SET_STRING_ELT
a <- pairlist(10,20,30,40,50,60)
dim(a) <- c(2,3)
dimnames(a) <- list(c("a","b"),c("x","y","z"))
print(a) # doesn't print names
a[["a","x"]] <- 0 # seg faults
Hi,
it looks like everything has not been installed correctly:
* installing to library ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library’
* installing *source* package ‘xts’ ...
** libs
x86_64-apple-darwin18-gcc-8.2.0 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include -I/usr/local/include -fPIC -march=haswell -pipe -s -O3 -march=native -mtune=native -ffp-contract=off -fno-stack-protector -DNDEBUG -c add_class.c -o add_class.o
In file included from add_class.c:2:
/Library/Frameworks/R.framework/Resources/include/Rinternals.h:85:10: fatal error: R_ext/sggc-app.h: No such file or directory
#include <R_ext/sggc-app.h>
^~~~~~~~~~~~~~~~~~
https://github.com/radfordneal/pqR/blob/Release-2019-01-25/src/include/Rinternals.h#L85
# find /Library/Frameworks/R.framework/ -name sggc-app.h
# find . -name sggc-app.h
./pqR/src/extra/sggc/test-sggc4/sggc-app.h
./pqR/src/extra/sggc/test-sggc3/sggc-app.h
./pqR/src/extra/sggc/interp/sggc-app.h
./pqR/src/extra/sggc/test-sggc2/sggc-app.h
./pqR/src/extra/sggc/test-sggc5/sggc-app.h
./pqR/src/extra/sggc/test-sggc7/sggc-app.h
./pqR/src/extra/sggc/test-sggc6/sggc-app.h
./pqR/src/extra/sggc/test-sggc1/sggc-app.h
./pqR/src/extra/sggc/sggc-app.h
./build/include/R_ext/sggc-app.h
./build/src/include/R_ext/sggc-app.h
Best regards,
Daniel
success build on win64,and set R_HELPERS=2, but when run following code
options(helpers_trace=TRUE)
A <- matrix(1.2,5000,5000)
B <- matrix(3.4,5000,5000)
C <- matrix(5.6,5000,5000)
f <- function () sum(A)
L <- list(A+B,A-C,f())
c (L[[1]][5000,5000], L[[2]][5000,5000], L[[3]])
seems task always done by master not helpers , why?
Bug 15374 at r-project.org does not occur in pqR, but a more elaborate version of it does, as seen below
> l = list(list(list(1)))
> l1 = l[[1]]
> l[[c(1,1,1)]] <- 2
> l1
[[1]]
[[1]][[1]]
[1] 2
Dear Prof Neal,
I've been trying to install your latest pqR-2020-07-23 stable version on my Slackware 14.2 (x86_64) Linux OS, but compilation fails at the 'make' stage with the following output to terminal:
make[4]: Leaving directory '/home/sc536/pqR-2020-07-23/src/library/tools'
Error in eval(do.call(substitute, list(template, list(FUN = quote(`+`))))) :
could not find function "do.call"
Execution halted
Below I append the outcome from running ./configure --prefix=/home/sc536/.pqR
from the source directory:
R is now configured for x86_64-unknown-linux-gnu, 8-byte pointers
Source directory: .
Installation directory: /home/sc536/.pqR
C compiler: gcc -ffp-contract=off -g -O2
Fortran 77 compiler: f95 -fno-optimize-sibling-calls -fallow-argument-mismatch -ffp-contract=off -g -O2
C++ compiler: g++ -ffp-contract=off -g -O2
Fortran 90/95 compiler: gfortran -fno-optimize-sibling-calls -fallow-argument-mismatch -ffp-contract=off -g -O2
Obj-C compiler: gcc -g -O2 -fobjc-exceptions
Compressed pointers: no
BLAS/LAPACK options: mat_mult_with_BLAS=FALSE, BLAS_in_helpers=TRUE
shared BLAS: built-in, LAPACK: built-in
External libraries: readline, ICU, lzma
Interfaces supported: X11, tcltk
Other capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU
Other options enabled: helper threads, task merging, R profiling, Java
Recommended packages: yes
I'm puzzled at the above error in that it appears to call on an R / pqR function (namely do.call()
) which, to my understanding, should form part of the base pqR system I'm installing. I believe that my system, which already has a working R installation (from source), already satisfies recommended package dependencies and development libraries; of course I could be wrong...
I'd be grateful for any assistance or pointer you can provide. Many thanks in advance for your time.
f <- structure ( f <- structure ( log10 , foo = 'x' ) , foo = f <- structure ( f <- structure ( log10 , foo = 'x' ) , structure = 'x' ) )
attributes ( f )
I get
*** buffer overflow detected ***: /home/yongheng/zfuzz/pqR/build/bin/exec/R terminated
[1] 11293 abort ./bin/R -f
> R.version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 15.1
year 2020
month 07
day 23
svn rev 58871
language R
version.string R version 2.15.1 (2020-07-23)
nickname
pqR.base.version 2.15.0
pqR.base.date 2012-03-30
pqR.base.year 2012
hello radford , following patch need apply to build pqR on windows .
diff --git a/src/gnuwin32/Makefile b/src/gnuwin32/Makefile
index d7563fa..2eab999 100644
--- a/src/gnuwin32/Makefile
+++ b/src/gnuwin32/Makefile
@@ -144,21 +144,31 @@ fixed/fixdesc:
dllversion.o: ../include/Rversion.h
+ifeq "$(WIN)" "64"
R.dll: $(OBJS) $(OBJS-EXTRA) $(MAINLIBS) $(EXTRALIBS) dllversion.o
@$(ECHO) EXPORTS > R.def
- @$(NM) $^ | $(SED) -n $(SYMPAT) | $(SORT) | uniq > R0.def
- @comm -23 R0.def Rdll.hide >> R.def
+ @$(NM) $^ | $(SED) -n $(SYMPAT) | LC_COLLATE=C $(SORT) | uniq > R0.def
+ @$(SED) -e's/@.*//' Rdll.hide | LC_COLLATE=C $(SORT) > R1.def
+ @LC_COLLATE=C comm -23 R0.def R1.def >> R.def
$(DLL) -shared $(DLLFLAGS) $($*-DLLFLAGS) -o $@ R.def $^ $($*-DLLLIBS) $(DLLLIBS)
- @$(RM) R.def R0.def
+ @$(RM) R.def R0.def R1.def
+else
+R.dll: $(OBJS) $(OBJS-EXTRA) $(MAINLIBS) $(EXTRALIBS) dllversion.o
+ @$(ECHO) EXPORTS > R.def
+ @$(NM) $^ | $(SED) -n $(SYMPAT) | LC_COLLATE=C $(SORT) | uniq > R0.def
+ @LC_COLLATE=C $(SORT) Rdll.hide > R1.def
+ @LC_COLLATE=C comm -23 R0.def R1.def >> R.def
+ $(DLL) -shared $(DLLFLAGS) $($*-DLLFLAGS) -o $@ R.def $^ $($*-DLLLIBS) $(DLLLIBS)
+ @$(RM) R.def R0.def R1.def
+endif
R.exp: $(OBJS) $(OBJS-EXTRA) $(MAINLIBS) $(EXTRALIBS) dllversion.o
@$(ECHO) LIBRARY R.dll > R.exp
@$(ECHO) EXPORTS >> R.exp
- @$(NM) $^ | $(SED) -n $(SYMPAT) | $(SORT) | uniq > R0.def
- @comm -23 R0.def Rdll.hide >> R.exp
+ @$(NM) $^ | $(SED) -n $(SYMPAT) | LC_COLLATE=C $(SORT) | uniq > R0.def
+ @LC_COLLATE=C comm -23 R0.def Rdll.hide >> R.exp
@$(RM) R0.def
-
Rdll: makeMakedeps libRblas.dll.a ../../$(BINDIR)/R.dll
../../$(BINDIR)/R.dll: FORCE
@@ -207,10 +217,10 @@ front-ends:
$(MK) -C ../extra/xz -f Makefile.win
../extra/helpers/libhelpers.a:
- $(MK) -C ../extra/helpers -f Makefile.win
+ $(MK) -C ../extra/helpers -f Makefile.win
../extra/matprod/libmatprod.a:
- $(MK) -C ../extra/matprod -f Makefile.win
+ $(MK) -C ../extra/matprod -f Makefile.win
NEWSdocs:
@$(MK) -C ../../doc -f Makefile.win
diff --git a/src/gnuwin32/fixed/h/config.h b/src/gnuwin32/fixed/h/config.h
index 16aa745..d5fd06d 100644:
--- a/src/gnuwin32/fixed/h/config.h
+++ b/src/gnuwin32/fixed/h/config.h
@@ -521,14 +521,15 @@
#define R_MAT_MULT_WITH_BLAS_IN_HELPERS_OK 1
/* Define this to make mat_mult_with_BLAS default to TRUE. */
-/* #undef R_MAT_MULT_WITH_BLAS_BY_DEFAULT */
+#define R_MAT_MULT_WITH_BLAS_BY_DEFAULT 1
+//#define R_INLINE 1
/* Define this to enable deferred evaluation / helpers. */
#define R_DEFERRED_EVAL 1
/* Define this to enable helper threads. */
#define R_HELPER_THREADS 1
-
+#define R_TASK_MERGING 1
/* Define to 1 if you have pangocairo. */
/* #undef HAVE_PANGOCAIRO */
diff --git a/src/main/platform.c b/src/main/platform.c
index b425c45..d252e5b 100644
--- a/src/main/platform.c
+++ b/src/main/platform.c
@@ -1336,6 +1336,9 @@ static SEXP do_filechoose(SEXP call, SEXP op, SEXP args, SEXP rho)
error(_("file name too long"));
return mkString(R_ExpandFileName(buf));
}
+#else
+extern SEXP do_filechoose(SEXP call, SEXP op, SEXP args, SEXP rho);
+
#endif
/* needed for access, and perhaps for realpath */
diff --git a/src/main/util.c b/src/main/util.c
index 732ff62..f8cae6f 100644
--- a/src/main/util.c
+++ b/src/main/util.c
@@ -1219,6 +1219,8 @@ static SEXP do_normalizepath(SEXP call, SEXP op, SEXP args, SEXP rho)
UNPROTECT(1);
return ans;
}
+#else
+extern SEXP do_normalizepath(SEXP call, SEXP op, SEXP args, SEXP rho);
#endif
I found a strange pqR and R behavior if the file is called time.R
.
# R --version | head -n1
pqR version 2.15.1 (2019-01-25), based on R 2.15.0 (2012-03-30)
# ls -lh xtime/R
total 32
-rw-r--r--@ 1 danice staff 4.5K Mar 31 11:19 date.R
-rw-r--r--@ 1 danice staff 1.1K Mar 31 11:20 time.R
-rw-r--r-- 1 danice staff 1.2K Mar 30 19:41 timestamp.R
# head -n4 xtime/R/time.R
as.time <- function(x, ...)
UseMethod('as.time')
# head -n4 xtime/NAMESPACE
useDynLib(xtime)
export(as.date)
export(as.time)
# R CMD INSTALL xtime
* installing to library ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library’
* installing *source* package ‘xtime’ ...
** libs
make: Nothing to be done for `all'.
installing to /Library/Frameworks/R.framework/Versions/2.15/Resources/library/xtime/libs
** R
** preparing package for lazy loading
** help
No man pages found in package ‘xtime’
*** installing help indices
** building package indices
** testing if installed package can be loaded
Error in namespaceExport(ns, exports) : undefined exports: as.time
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library/xtime’
* restoring previous ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library/xtime’
#
#
# mv xtime/R/time.R xtime/R/xtime.R
#
# R CMD INSTALL xtime
* installing to library ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library’
* installing *source* package ‘xtime’ ...
** libs
make: Nothing to be done for `all'.
installing to /Library/Frameworks/R.framework/Versions/2.15/Resources/library/xtime/libs
** R
** preparing package for lazy loading
** help
No man pages found in package ‘xtime’
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (xtime)
commit a0dac36 and after make windows build fail.
Rterm crash at start, seem R_NilValue to const affect it.
Hi,
It looks like pqR is strangely slower in loops:
R --version
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin17.0 (64-bit)
> f1 <- function() { n = 1000000; while(TRUE) { n = n - 1; if (n < 0) break }}
> f2 <- function() { n = 1000000; repeat { n = n - 1; if (n < 0) break }}
> microbenchmark(f1(), f2())
Unit: milliseconds
expr min lq mean median uq max neval
f1() 41.05380 41.11387 41.68804 41.15750 41.36439 65.65936 100
f2() 36.11894 36.17082 36.61408 36.23296 36.34383 56.73681 100
$ ./R --version
pqR version 2.15.1 (2019-01-25), based on R 2.15.0 (2012-03-30)
> require(microbenchmark)
Loading required package: microbenchmark
> f1 <- function() { n = 1000000; while(TRUE) { n = n - 1; if (n < 0) break }}
> f2 <- function() { n = 1000000; repeat { n = n - 1; if (n < 0) break }}
> microbenchmark(f1(), f2())
Loading required namespace: multcomp
Unit: milliseconds
expr min lq mean median uq max neval
f1() 97.11488 97.92926 99.01918 98.35280 98.84636 150.5703 100
f2() 93.32935 93.55776 94.35951 93.67318 94.34873 102.5124 100
As in title.
This link is broken: https://codeload.github.com/radfordneal/pqR/tar.gz/2013-07-22
On this page: http://radfordneal.github.io/pqR/
Best,
Thanks!
P.S.: Would be great to have installation notes (for installation from github) on the the github's README
RStudio can be used with pqR-2014-06-19 as long as it is compiled with --enable-R-shlib (which is on by default on Mac systems). It generally works, and one can put plots in the plot window. However, trying to debug a function (with "debug(f)" followed by running f) leads to it crashing, for reasons presently unknown.
I am following http://www.pqr-project.org/INSTALL.txt for Ubuntu. I have created a folder 'pqr-2020-07-23-myconfig' and run the command '~/pqr_source/pqr-2020-07-23-myconfig$ ../pqR-2020-07-23/configure --enable-R-shlib'. After a long list of checks I get the output
R is now configured for x86_64-unknown-linux-gnu, 8-byte pointers
Source directory: ../pqR-2020-07-23
Installation directory: /usr/local
C compiler: gcc -ffp-contract=off -g -O2
Fortran 77 compiler: f95 -fno-optimize-sibling-calls -ffp-contract=off -g -O2
C++ compiler: g++ -ffp-contract=off -g -O2
Fortran 90/95 compiler: gfortran -fno-optimize-sibling-calls -ffp-contract=off -g -O2
Obj-C compiler:
Compressed pointers: no
BLAS/LAPACK options: mat_mult_with_BLAS=FALSE, BLAS_in_helpers=TRUE
shared BLAS: built-in, LAPACK: built-in
External libraries: readline, ICU, lzma
Interfaces supported: X11, tcltk
Other capabilities: PNG, JPEG, NLS, ICU
Other options enabled: helper threads, task merging, shared R library, R profiling
Recommended packages: yes
However when I run the checks I get that bin
is not found. Meaning, I cannot open pqR using the /bin/R
from the configuration directory since it does not exist.
~/pqr_source/pqr-2020-07-23-myconfig$ make check
make[1]: Entering directory '/home/spinkney/pqr_source/pqr-2020-07-23-myconfig/tests'
make[2]: Entering directory '/home/spinkney/pqr_source/pqr-2020-07-23-myconfig/tests'
make[3]: Entering directory '/home/spinkney/pqr_source/pqr-2020-07-23-myconfig/tests/Examples'
/bin/bash: ../../bin/R: No such file or directory
make[3]: *** [Makefile:31: test-Examples-Base] Error 127
make[3]: Leaving directory '/home/spinkney/pqr_source/pqr-2020-07-23-myconfig/tests/Examples'
make[2]: *** [../../pqR-2020-07-23/tests/Makefile.common:175: test-Examples] Error 2
make[2]: Leaving directory '/home/spinkney/pqr_source/pqr-2020-07-23-myconfig/tests'
make[1]: *** [../../pqR-2020-07-23/tests/Makefile.common:165: test-all-basics] Error 1
make[1]: Leaving directory '/home/spinkney/pqr_source/pqr-2020-07-23-myconfig/tests'
make: *** [Makefile:217: check] Error 2
Just an idea, not sure if it works.
Is it possible to make pqR as an installable R package which overwrites R functions for fast computation?
If it is possible, it will encourage more people to try out pqR.
In Gnu-R 2.15 and 3.6 update(~1, ~. - y)
produces ~1
. pqR produces ~1 - 1
plot ( 1 ( 1 ) ~ 1 , c ( try ( plot ( 1 ( 1 ) ~ 1 , lm ( c ( c ( try ( 1 + 1 + try ( print ( c ( mean ( 'x' ) , foo ~ 'x' ) ) ) ) : 1 : 1 , foo = 'x' ) ) , print ) ) ) , foo = 'x' ) )
[[1]]
[1] NA
[[2]]
foo ~ "x"
[1] 759 abort (core dumped) ./bin/R
> R.version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 15.1
year 2020
month 07
day 23
svn rev 58871
language R
version.string R version 2.15.1 (2020-07-23)
nickname
pqR.base.version 2.15.0
pqR.base.date 2012-03-30
pqR.base.year 2012
When configuring to build pqR, the mat_mult_with_BLAS argument can be used to change the default setting of the mat_mult_with_BLAS option. It is documented that mat_mult_with_BLAS =T and mat_mult_with_BLAS=F can be used for this, but they don't work.
Until this is fixed, use mat_mult_with_BLAS =TRUE or mat_mult_with_BLAS=FALSE instead.
I benchmarked pqR with this piece of code:
n = 2000
A = matrix(rnorm(n*n), n, n)
t = system.time({ B = crossprod(A)})
and it runs really slow on my machine. On my standard R 3.0.1 it takes around 0.5 secs, with pqR it takes nearly 6 seconds! For different 'n' this looks like this (red: pqR):
Data is here:
structure(list(n = c(100, 200, 300, 400, 500, 600, 700, 800,
900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900,
2000), R = c(0.001, 0.001, 0.004, 0.004, 0.009, 0.015, 0.025,
0.035, 0.05, 0.065, 0.082, 0.106, 0.13, 0.162, 0.195, 0.236,
0.278, 0.328, 0.383, 0.445), pqR = c(0.001, 0.005, 0.016, 0.038,
0.076, 0.132, 0.219, 0.346, 0.49, 0.689, 0.955, 1.189, 1.523,
1.954, 2.383, 3.078, 3.515, 4.214, 4.988, 5.766)), .Names = c("n",
"R", "pqR"), row.names = c(NA, -20L), class = "data.frame")
PS: I am using OpenBLAS as BLAS and I also tried setting different options, such as mat_mult_with_BLAS and helpers_enabled.
The official Mac R GUI can be complied successfully for both the helper-enabled and disabled versions.
However only the helper-disabled R GUI can be run without errors.
For the helper-enabled R GUI, I got the following runtime error
I tracked down the problem, I found that the GUI crashes when running the function setup_Rmainloop()
.
The problem should be also related to libR.dylib
and function helpers_avail1
as indicated in the top-right corner of the above figure.
I am not good in objective C and the structure of R.
Hope this piece of information will help somebody to fix the problem.
Dear Radford,
Thank you for making public this very interesting project. I've built pqR successfully on Mac OS X (using gcc 4.8.1), but on running a set of my own tests using it, I noticed a lot of warnings which I hadn't seen before. This seems to be traceable to subset.data.frame
. A simple example is
> x <- data.frame(a=2,b=3:4)
> subset(x,b==3)
a b
1 2 3
Warning message:
In `[.data.frame`(x, r, vars, drop = drop) :
named arguments other than 'drop' are discouraged
The warning does not occur with R 2.15.0 or R 3.0.1. From a (very) quick look at the source code it seems that the warning itself is not new, so presumably some modification to subset.data.frame
, or something downstream from it, is triggering this where it did not before.
All the best,
Jon
The methods package is missing an error check (for 0-length string vector as a class name), which can cause a failure in make check-all, in the no-segfaults tests. The problem is illustrated by the call
getClassDef(character(0),.GlobalEnv,"")
which can crash rather than give an error message. The problem appears to exist in all recent versions of R and pqR, but for some reason usually avoids a crash. It showed up when testing pqR-2015-09-14 on Windows 10 (64-bit).
It can be fixed with the following patch to src/library/methods/src/methods_list_dispatch.c, which also fixes a related bug:
@@ -860,15 +860,15 @@ SEXP R_identC(SEXP e1, SEXP e2)
SEXP R_getClassFromCache(SEXP class, SEXP table)
{
SEXP value;
- if(TYPEOF(class) == STRSXP) {
+ if(TYPEOF(class) == STRSXP && LENGTH(class) > 0) {
SEXP package = PACKAGE_SLOT(class);
value = findVarInFrame(table, installChar(STRING_ELT(class, 0)));
if(value == R_UnboundValue)
return R_NilValue;
- else if(TYPEOF(package) == STRSXP) {
+ else if(TYPEOF(package) == STRSXP && LENGTH(package) == 1) {
SEXP defPkg = PACKAGE_SLOT(value);
/* check equality of package */
- if(TYPEOF(defPkg) == STRSXP && length(defPkg) ==1 &&
+ if(TYPEOF(defPkg) == STRSXP && LENGTH(defPkg) == 1 &&
STRING_ELT(defPkg,0) != STRING_ELT(package, 0))
return R_NilValue;
else
This fix will be incorporated into the next release of pqR.
Is there any executable to install pqR on my System. I would love to try it. and if it is as fast as it says will stick to it.
Hello,
I was trying to instal the development version of pqR and make thrown an error. I thought it was an issua with the development version and tried the 2019-02-19, but it throws the exact same error:
gcc -shared -fopenmp -L/usr/local/lib64 -o libR.so CommandLineArgs.o Rdynload.o Renviron.o RNG.o access.o agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o builtin.o bytecode.o character.o coerce.o colors.o complex.o connections.o const-objs.o context.o cov.o cum.o dcf.o datetime.o debug.o deparse.o deriv.o devices.o dotcode.o dounzip.o duplicate.o engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram-ex.o gramLatex.o gramRd.o graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o lapack.o list.o localecharset.o main.o mapply.o match.o memory.o merged-ops.o model.o names.o objects.o optim.o optimize.o options.o par.o parse.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o profile.o qsort.o radixsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o subset.o summary.o sysutils.o unique.o util.o version.o vfonts.o xxxpr.o ../unix/Rembedded.o ../unix/libunix.a ../appl/libappl.a ../nmath/libnmath.a ../extra/tre/libtre.a ../extra/matprod/libmatprod.a ../extra/helpers/libhelpers.a ../extra/sggc/libsggc.a ../extra/lphash/liblphash.a -L../../lib -lRblas -lgfortran -lm -lquadmath -lreadline -lpcre -llzma -lbz2 -lz -ltirpc -lrt -ldl -lm -licuuc -licui18n
/usr/bin/ld: gramRd.o:(.bss+0x28): multiple definition of "Rf_yylval"; gramLatex.o:(.bss+0x28): first defined here
/usr/bin/ld: gramRd.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/gramRd.c:1839: multiple definition of "Rf_yychar"; gramLatex.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/gramLatex.c:1235: first defined here
/usr/bin/ld: gramRd.o:(.bss+0x34): multiple definition of "yydebug"; gramLatex.o:(.bss+0x34): first defined here
/usr/bin/ld: gramRd.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/gramRd.c:1850: multiple definition of "Rf_yynerrs"; gramLatex.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/gramLatex.c:1246: first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1599: multiple definition of "R_NilValue_const"; const-objs.o:(.data.rel.ro+0x19a0): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1686: multiple definition of "R_scalar_stack_space"; const-objs.o:(.data.rel+0x10c0): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1606: multiple definition of "R_sym_consts"; const-objs.o:(.data.rel+0x1000): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1677: multiple definition of "R_ScalarString_consts"; const-objs.o:(.data.rel.ro+0x440): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1676: multiple definition of "R_ASCII_consts"; const-objs.o:(.data.rel+0x0): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1656: multiple definition of "R_ScalarMisc_consts"; const-objs.o:(.data.rel.ro+0x1440): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1655: multiple definition of "R_ScalarInteger_consts"; const-objs.o:(.data.rel.ro+0x1560): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1631: multiple definition of "R_MissingUnder"; const-objs.o:(.data.rel.ro+0x0): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1622: multiple definition of "R_MissingArg"; const-objs.o:(.data.rel.ro+0x8): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1611: multiple definition of "R_UnboundValue"; const-objs.o:(.data.rel.ro+0x10): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1594: multiple definition of "R_NilValue"; const-objs.o:(.data.rel.ro+0x20): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1580: multiple definition of "R_env_consts"; const-objs.o:(.data.rel.ro+0x1960): first defined here
/usr/bin/ld: main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/Rinternals.h:1574: multiple definition of "R_EmptyEnv"; const-objs.o:(.data.rel.ro+0x18): first defined here
/usr/bin/ld: memory.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:94: multiple definition of "sggc_data"; main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:94: first defined here
/usr/bin/ld: memory.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sbset-app.h:90: multiple definition of "sggc_segment"; main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sbset-app.h:90: first defined here
/usr/bin/ld: memory.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:243: multiple definition of "sggc_info"; main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:243: first defined here
/usr/bin/ld: memory.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:215: multiple definition of "sggc_kind_chunks"; main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:215: first defined here
/usr/bin/ld: memory.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:198: multiple definition of "sggc_type"; main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc.h:198: first defined here
/usr/bin/ld: ../extra/sggc/libsggc.a(sggc-app.o):(.rodata+0x80): multiple definition of "R_type_to_sggc_type"; main.o:/home/danielc/Downloads/pqR-2019-02-19/src/main/../../src/include/R_ext/sggc-app.h:150: first defined here
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:192: libR.so] Erro 1
make[3]: Exiting'/home/danielc/Downloads/pqR-2019-02-19/src/main'
make[2]: *** [Makefile:148: R] Erro 2
make[2]: Exiting '/home/danielc/Downloads/pqR-2019-02-19/src/main'
make[1]: *** [Makefile:28: R] Erro 1
make[1]: Exiting '/home/danielc/Downloads/pqR-2019-02-19/src'
make: *** [Makefile:59: R] Erro 1
I am running on arch linux.
I am not sure this is enough - I have not compiled a lot of packages before - so please let me know if you need anything else
Thanks in advance
Package igraph, version 0.6.5-2, fails to install with pqR-2013-12-29, though it installed OK with pqR-2013-07-22. Version 0.6-2 does install with pqR-2013-12-29.
The problem is that igraph_0.6.5-2 defines USE_RINTERNALS and then uses NAMED, which is a macro rather than a procedure when USE_RINTERNALS is defined. The NAMED macro uses a macro that is undefined in this context. This macro was introduced in pqR-2013-12-29, replacing direct access to a sxpinfo field. The problem should be fixable by just reverting to directly accessing the field. A fixed version will be released soon.
In pqR-2014-09-30, user-defined replacement functions can sometimes immediately modify their argument, which is fast, but not entirely safe. For example, after
> `f<-` <- function (x,value) { x[1] <- 1; stop("error") }
> a<-numeric(10); a[1] <- 3; f(a) <- 4
Error in `f<-`(a, value = 4) : error
> a
[1] 1 0 0 0 0 0 0 0 0 0
we see that a[1] has changed even though the replacement function exited with an error.
This is the result of a combination of a[1] <- 3 letting "a" get a NAMEDCNT of 0, which is generally unnoticeable since it is fixed up later, and invokation of user-defined replacement functions not doing the usual fixup. These problems are now corrected in development branch 30.
This is a user PSA that may be good to put on the installation wiki for mac Rstudio users.
I installed on a mac running catalina with R 4.0.3 on it. I have to cd into the lib
directory of pqr to run Rstudio or else the .dylib files are not recognized. I found this issue on Rstudio that someone had a similar problem. I'm running Rstudio version 1.3.1056. It's not a big deal since I have to start the terminal to run pqr in Rstudio anyway but want other users to know.
pinkney@Pinkneys-MBP lib % ls
libR.dylib libRblas.dylib libRlapack.dylib
pinkney@Pinkneys-MBP lib % RSTUDIO_WHICH_R=../../pqr-2020-07-23-myconfig/bin/R /Applications/Rstudio.app/Contents/MacOS/Rstudio
Feel free to close this issue.
I've come across more bugs/inconsistencies while changing the code for extracting subsets of vectors and assigning to subsets. These bugs all occur identically in pqR-2013-06-28, R-2.15.0, and R-3.0.1.
The following code illustrates the problems:
v <- list(1,2)
v[""] # list with NULL (incorrect?)
v[[""]] # NULL (incorrect?)
v$"" # NULL (incorrect?)
v$a <- 3
v[""] # list with NULL having name of <NA> (incorrect)
v[[""]] # NULL (incorrect?)
v$"" # returns first element (incorrect)
v[""] <- 9; v # adds element (incorrect)
v[[""]] <- 9; v # adds element (incorrect)
v$"" <- 9; v # refuses to add element (correct)
pqR doesn't make if the system has no omp.h include file, even when helper threads are disabled (so it isn't needed). Seems like it's fixable by just moving one statement, so will probably be fixed in next release.
The --enable-R-shlib option to configure leads to errors when pqR is made unless helper threads are disabled with --disable-helper-threads. Configuring with --enable-R-shlib is needed to use pqR with Rstudio. (Fixing this should not be too difficult.)
Hi,
I was trying to configure pqR using gcc4.9 (I've been running into the OpenMP issue with the most recent Mac update), but I end up getting the following error
dyld: Library not loaded: /usr/local/opt/r/lib/R/lib/libR.dylib Referenced from: /Users/.../Library/R/3.4/library/pqR/pqr_config/bin/exec/R Reason: Incompatible library version: R requires version 3.4.0 or later, but libR.dylib provides version 2.15.0
Would you happen to know how to fix this? It seems like it's an issue with libR.dylib, but since I haven't had great luck with enabling OpenMP on my Mac, it may be related to that (.log file attached). Thanks!
I want to thank you for your work and development of pqR
. Around 2012, you published a dozen or so patches on R-devel. I remember it! :) Your patches have not been accepted for the most part. However, I copied them and used them in my subsequent versions of R. I thank you again, for your work.
I wonder if it would be good to add native support for int64
in pqR
. There is bit64
, of course, but unfortunately this will never be a fast solution (eg. support for SMID).
The second problem is that where it is necessary to use larger numbers (eg POSIXct
), double
type is used, which unfortunately causes many problems. See my conversation.
My proposal was very similar to how it works in bit64
. Unfortunately, such a solution would cause many problems (as indicated in the discussion).
I'm currently wondering if it would be better to simply define a new type in TypeTable[], eg.:
{ "integer64", INT64SXP },
In order not to break compatibility with other packages, it should probably be implemented a new version of POSIXct
, eg nanotime
, which would be capable of handling time with nanosecond precision.
What do you think about this proposal? In my opinion, the lack of support for integer64
is one of the biggest drawbacks of R.
I'm trying to compile pqR release 2014-09-06 on OS X 10.9 ("Mavericks") using gcc 4.9.1. Following my standard flags for compiling R-Core releases, I configure with
./configure --with-blas="-framework Accelerate" --with-lapack --with-system-zlib --with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh --with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh CC=gcc-4.9 CXX=g++-4.9 OBJC=clang F77=gfortran-4.9 FC=gfortran-4.9 CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2" CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2" FCFLAGS="-mtune=native -g -O2"
The error begins
[...]
making Lapack.d from Lapack.c
making vecLibg95c.d from vecLibg95c.c
make[4]: `Makedeps' is up to date.
gcc-4.9 -std=gnu99 -I. -I../../../src/include -I../../../src/include -D__ACCELERATE__ -DHAVE_CONFIG_H -fopenmp -fPIC -mtune=native -g -O2 -c Lapack.c -o Lapack.o
gcc-4.9 -std=gnu99 -I. -I../../../src/include -I../../../src/include -D__ACCELERATE__ -DHAVE_CONFIG_H -fopenmp -fPIC -mtune=native -g -O2 -c vecLibg95c.c -o vecLibg95c.o
In file included from /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:31:0,
from vecLibg95c.c:5:
/System/Library/Frameworks/vecLib.framework/Headers/vBasicOps.h: In function 'vU16HalfMultiply':
/System/Library/Frameworks/vecLib.framework/Headers/vBasicOps.h:352:3: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts
vUInt16 __vbasicops_vB) { return _mm_mullo_epi16(__vbasicops_vA, __vbasicops_vB); }
^
/System/Library/Frameworks/vecLib.framework/Headers/vBasicOps.h:352:38: error: incompatible type for argument 1 of '_mm_mullo_epi16'
vUInt16 __vbasicops_vB) { return _mm_mullo_epi16(__vbasicops_vA, __vbasicops_vB); }
^
In file included from /usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include/xmmintrin.h:1258:0,
from /System/Library/Frameworks/vecLib.framework/Headers/vecLibTypes.h:90,
from /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:27,
from vecLibg95c.c:5:
/usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include/emmintrin.h:1115:1: note: expected '__m128i' but argument is of type 'vUInt16'
_mm_mullo_epi16 (__m128i __A, __m128i __B)
^
[...]
I raised this on R-SIG-Mac when I first saw it, in R 3.0.2, but since then the solution has been to include CPPFLAGS="-D__ACCELERATE__"
. As you can see that option is already included above, so I don't know why this is reappearing.
I know this is a very Mac-specific problem, and rather esoteric, but if there's anything specific to pqR that might be influencing it then I'd be glad to hear about it. Adding -flax-vector-conversions
to CFLAGS
does suppress the error, but doesn't deal with the underlying issue.
I'm not sure if this is specific to the latest release, as I haven't been trying every pqR version.
I've created a Docker image for pqR: https://hub.docker.com/r/nuest/pqr/
I would love your feedback on this!
Note that I've listed pqR and this image in a blog post on "Docker vs. R" here: http://bit.ly/docker-r
I successfully installed pqR (with --disable-helper-threads ) on Mac
In test.r, two random 1000x1000 matrices are multiplied together 10 times. The improvement is encouraging.
However, when I tried to install it with the helper threads, the follows happened. I have no idea what it is. Hope this piece of information will help you.
make[4]: `liblzma.a' is up to date.
gcc -std=gnu99 -I. -I./../helpers -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -fopenmp -fPIC -g -O2 -c piped-matprod.c -o piped-matprod.o
rm -f libmatprod.a
ar cr libmatprod.a matprod.o piped-matprod.o
ranlib libmatprod.a
gcc -std=gnu99 -I. -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -fopenmp -fPIC -g -O2 -c helpers.c -o helpers.o
helpers.c:313: sorry, unimplemented: threadprivate variables not supported in this target
make[4]: *** [helpers.o] Error 1
make[3]: *** [R] Error 2
make[2]: *** [make.helpers] Error 2
make[1]: *** [R] Error 1
make: *** [R] Error 1
Hi Radford.
Thank you for your brilliant work on pqR.
Today I compiled pqR on windows 64 use mingw-w64 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/)
after modify some files(the patch file already sent to your gmail ),Now pqR seems work on windows x64,Rgui can success started,but When start RGUI.exe it show following message in console (please see the attachment picture
)
Could help me find the error?
thank you very much
There are some reliability problems when pqR is built using gcc 4.8 (and possibly other versions of gcc after gcc 4.6). I had originallly thought (before editing this message) that another problem relates to gcc 4.8 and originates in R-2.15.0, but this problem actually can show up in R-2.15.0 with gcc 4.6 too.
These problems are now fixed in pqR development branch 35. A new version of pqR with these and other fixes, as well as additional performance improvements, will hopefully be released soon.
The following output demonstrates the bug:
> e <- expression(x=1+2); print(e)
expression(x = 1 + 2)
> e$y <- quote(3+4); print(e)
$x
1 + 2
$y
3 + 4
The extension of the "expression" vector with $ has converted it to a list.
This bug is also present in R-2.15.0 and R-3.0.1. It is now fixed in pqR development branch "14".
a <- structure ( c , b = c )
attributes ( a )
I get
*** caught segfault ***
address 0x29226231a439, cause 'memory not mapped'
aborting ...
> R.version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 15.1
year 2020
month 07
day 23
svn rev 58871
language R
version.string R version 2.15.1 (2020-07-23)
nickname
pqR.base.version 2.15.0
pqR.base.date 2012-03-30
pqR.base.year 2012
You've got some speed tests for R at:
http://www.cs.utoronto.ca/~radford/R-speed.html
You may want to include them in pqR so people can use them to compare in their own environment.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.