radfordneal/pqr

pqR - a "pretty quick" version of R

pqr's Issues

Will pqR code be merged to R?

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.

More bugs from testing subset and subassign

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)

--enable-R-shlib doesn't work when helper threads are enabled

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.)

Debugging in RStudio doesn't work

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.

Missing error check, causing fail in make check-all

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.

Problems with installation ubuntu 20.04

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

No window version available

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.

Problem with package igraph

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.

Missing <R_ext/sggc-app.h>

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

Speed tests

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.

news() doesn't work

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").

User-defined replacement function can sometimes immediately modify arg

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.

Incompatible library version

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!

config.log

problem about pqR on windows

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

extending an "expression" vector with $ converts it to a regular list

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".

Update formula does not work as expected

In Gnu-R 2.15 and 3.6 update(~1, ~. - y) produces ~1. pqR produces ~1 - 1

Bug similar to PR 15374 at r-project.org

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

patch about windows build

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

Broken Link to tar.gz in home page

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

Slow pqR loops vs R (CRAN)

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

Installation fails on Slackware 15.0

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.

VecLib/Accelerate framework error when compiling release 2014-09-06 on OS X 10.9

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.

make error: multiple definitions

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

pqR aborted when using plot

poc

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' ) )

result

[[1]]
[1] NA

[[2]]
foo ~ "x"

[1]    759 abort (core dumped)  ./bin/R

setup

> 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

What is preventing the merge of pqR into R?

As in title.

commit a0dac3644bc7ce7ca7f4ce6952a09979829f22be and after make windows build fail.

commit a0dac36 and after make windows build fail.
Rterm crash at start, seem R_NilValue to const affect it.

floating point exception

poc

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 ) ) ) ) ) )

result

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

setup

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

segfault when using attributes

poc

a <- structure ( c , b = c )
attributes ( a )

result

I get

 *** caught segfault ***
address 0x29226231a439, cause 'memory not mapped'
aborting ...

background

> 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

unable to run Mac GUI with 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.

Proposal of new feature: native 64 bit integers support

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.

T and F don't work with mat_mult_with_BLAS configuration argument

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.

pqR side by side with GNU-R

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’

Pqr and running Rstudio on mac

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.

More bugs from looking in subassign.c

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

extra/helpers/Makefile.win have some problem,need change

here need add -fopenmp, otherwise there will not have helpers function on windows

DEFS=-DHAVE_CONFIG_H -fopenmp

here typo helpers--app.c need change to helpers-app.c

CSOURCES = helpers.c helpers-app.c

crossprod() incredible slow on large matrices

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.

helpers seems not work on windows

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?

an idea: making a package

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.

R/time.R - filename restricted?

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)

helpers.c cannot be compiled on Mac OSX

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

Won't make if no omp.h include file

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.

as.pairlist doesn't duplicate or set NAMEDCNT properly

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".

Spurious warning from subset.data.frame

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

buffer overflow when using attributes on a recursive function

poc

f <- structure ( f <- structure ( log10 , foo = 'x' ) , foo = f <- structure ( f <- structure ( log10 , foo = 'x' ) , structure = 'x' ) )
attributes ( f )

result

I get

*** buffer overflow detected ***: /home/yongheng/zfuzz/pqR/build/bin/exec/R terminated
[1]  11293 abort   ./bin/R -f

background

> 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

Docker image for pqR

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

Reliability problems using gcc4.8

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.