Re: [Rd] Trying to compile R 3.5.2 - 32 bit R - on Windows 10 64 bit - with ICU support

2019-02-18 Thread Tomas Kalibera



On 2/16/19 11:12 AM, Andre Mikulec wrote:

Hi,

I am trying to compile R with ICU support.

I am following
https://cran.r-project.org/doc/manuals/R-admin.html#Building-from-source

I have downloaded and extracted
https://www.stats.ox.ac.uk/pub/Rtools/goodies/ICU_531.zip
to
W:\R-3.5._\App\R-Portable\ICU

I have modified MkRules.local

# set to use ICU
USE_ICU = YES
# path to parent of ICU headers
ICU_PATH = w:/R-3.5._/App/R-Portable/ICU


I also build recent versions of R following the documentation, with ICU, 
but have not run into these problems. Normally I use RTools 3.4 but now 
I tested just the build using RTools 3.5 and the linking went fine.


According to the error messages, the linking problems _may_ be due to 
incompatible exception handling in compilers used (e.g. when linking a 
library that has been built by an older version of the compiler than the 
one you are using to link via / build other parts of the application).


Best
Tomas



I have done

export R_ICU_LOCALE=en_US

When I try to compile ( 32 bit compile ), I am getting these errors.

w:/Rtools35/mingw_32/bin/gcc -std=gnu99 -m32 -shared -s -mwindows -o R.dll 
R.def console.o dynload.o editor.o embeddedR.o extra.o malloc.o opt.o pager.o pr
eferences.o psignal.o rhome.o rt_complete.o rui.o run.o shext.o sys-win32.o 
system.o dos_wglob.o dllversion.o e_pow.o ../main/libmain.a ../appl/libappl.a .
./nmath/libnmath.a getline/gl.a ../extra/xdr/libxdr.a ../extra/intl/libintl.a 
../extra/trio/libtrio.a ../extra/tzone/libtz.a ../extra/tre/libtre.a -fopenmp
  -L. -lgfortran -lquadmath -lRblas -L../../bin/i386 -lRgraphapp -lRiconv -lcomctl32 
-lwinmm -lversion -L"../../extsoft"/lib/i386 -lpcre -lz -lbz2 -llzma -L
"w:/R-3.5._/App/R-Portable/ICU"/lib/i386 -lsicuin -lsicuuc -lsicudt -lstdc++
w:/R-3.5._/App/R-Portable/ICU/lib/i386/libsicuin.a(ucol.ao):ucol.cpp:(.text+0x15):
 undefined reference to `__gxx_personality_sj0'
w:/R-3.5._/App/R-Portable/ICU/lib/i386/libsicuin.a(ucol.ao):ucol.cpp:(.text+0x2b):
 undefined reference to `_Unwind_SjLj_Register'
w:/R-3.5._/App/R-Portable/ICU/lib/i386/libsicuin.a(ucol.ao):ucol.cpp:(.text+0xde):
 undefined reference to `_Unwind_SjLj_Unregister'
w:/R-3.5._/App/R-Portable/ICU/lib/i386/libsicuin.a(ucol.ao):ucol.cpp:(.text+0xf5):
 undefined reference to `_Unwind_SjLj_Unregister'
w:/R-3.5._/App/R-Portable/ICU/lib/i386/libsicuin.a(ucol.ao):ucol.cpp:(.text+0x13e):
 undefined reference to `_Unwind_SjLj_Resume'

Thanks
Andre



[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png]
 Virus-free. 
www.avg.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] code for sum function

2019-02-18 Thread Rampal Etienne

Hello,

I am trying to write FORTRAN code to do the same as some R code I have. 
I get (small) differences when using the sum function in R. I know there 
are numerical routines to improve precision, but I have not been able to 
figure out what algorithm R is using. Does anyone know this? Or where 
can I find the code for the sum function?


Regards,

Rampal Etienne

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Proposed speedup of spec.pgram from spectrum.R

2019-02-18 Thread Jonathan Kennel
Hello,

I propose two small changes to spec.pgram to get modest speedup when
dealing with input (x) having multiple columns.  With plot = FALSE, I
commonly see ~10-20% speedup, for a two column input matrix and the speedup
increases for more columns with a maximum close to 45%.  In the function as
it currently exists, only the upper right triangle of pgram is necessary
and pgram is not returned by the function, therefore, calculating the lower
left portion (ie when j < i) is not required.  We change two nested loops
to index from i:ncol(x) instead of 1L:ncol(x) :

newspec.pgram <-
function (x, spans = NULL, kernel = NULL, taper = 0.1,
  pad = 0, fast = TRUE,
  demean = FALSE, detrend = TRUE,
  plot = TRUE, na.action = na.fail, ...)
{
## Estimate spectral density from (smoothed) periodogram.
series <- deparse(substitute(x))
x <- na.action(as.ts(x))
xfreq <- frequency(x)
x <- as.matrix(x)
N <- N0 <- nrow(x)
nser <- ncol(x)
if(!is.null(spans)) # allow user to mistake order of args
kernel <- {
if(is.tskernel(spans)) spans else
kernel("modified.daniell", spans %/% 2)
}
if(!is.null(kernel) && !is.tskernel(kernel))
stop("must specify 'spans' or a valid kernel")
if (detrend) {
t <- 1L:N - (N + 1)/2
sumt2 <- N * (N^2 - 1)/12
for (i in 1L:ncol(x))
x[, i] <- x[, i] - mean(x[, i]) - sum(x[, i] * t) * t/sumt2
}
else if (demean) {
x <- sweep(x, 2, colMeans(x), check.margin=FALSE)
}
## apply taper:
x <- spec.taper(x, taper)
## to correct for tapering: Bloomfield (1976, p. 194)
## Total taper is taper*2
u2 <- (1 - (5/8)*taper*2)
u4 <- (1 - (93/128)*taper*2)
if (pad > 0) {
x <- rbind(x, matrix(0, nrow = N * pad, ncol = ncol(x)))
N <- nrow(x)
}
NewN <- if(fast) nextn(N) else N
x <- rbind(x, matrix(0, nrow = (NewN - N), ncol = ncol(x)))
N <- nrow(x)
Nspec <- floor(N/2)
freq <- seq.int(from = xfreq/N, by = xfreq/N, length.out = Nspec)
xfft <- mvfft(x)
pgram <- array(NA, dim = c(N, ncol(x), ncol(x)))
for (i in 1L:ncol(x)) {
for (j in i:ncol(x)) { # N0 = #{non-0-padded}
pgram[, i, j] <- xfft[, i] * Conj(xfft[, j])/(N0*xfreq)
## value at zero is invalid as mean has been removed, so
interpolate:
pgram[1, i, j] <- 0.5*(pgram[2, i, j] + pgram[N, i, j])
}
}
if(!is.null(kernel)) {
for (i in 1L:ncol(x)) for (j in i:ncol(x))
pgram[, i, j] <- kernapply(pgram[, i, j], kernel, circular = TRUE)
df <- df.kernel(kernel)
bandwidth <- bandwidth.kernel(kernel)
} else { # raw periodogram
df <- 2
bandwidth <- sqrt(1/12)
}
df <- df/(u4/u2^2)
df <- df  * (N0 / N) ## << since R 1.9.0
bandwidth <- bandwidth * xfreq/N
pgram <- pgram[2:(Nspec+1),,, drop=FALSE]
spec <- matrix(NA, nrow = Nspec, ncol = nser)
for (i in 1L:nser) spec[, i] <- Re(pgram[1L:Nspec, i, i])
if (nser == 1) {
coh <- phase <- NULL
} else {
coh <- phase <- matrix(NA, nrow = Nspec, ncol = nser * (nser - 1)/2)
for (i in 1L:(nser - 1)) {
for (j in (i + 1):nser) {
coh[, i + (j - 1) * (j - 2)/2] <-
Mod(pgram[, i, j])^2/(spec[, i] * spec[, j])
phase[, i + (j - 1) * (j - 2)/2] <- Arg(pgram[, i, j])
}
}
}
## correct for tapering
for (i in 1L:nser) spec[, i] <- spec[, i]/u2
spec <- drop(spec)
spg.out <-
list(freq = freq, spec = spec, coh = coh, phase = phase,
 kernel = kernel, df = df,
 bandwidth = bandwidth, n.used = N, orig.n = N0,# "n.orig" =
"n..."
 series = series, snames = colnames(x),
 method = ifelse(!is.null(kernel), "Smoothed Periodogram",
 "Raw Periodogram"),
 taper = taper, pad = pad, detrend = detrend, demean = demean)
class(spg.out) <- "spec"
if(plot) {
plot(spg.out, ...)
return(invisible(spg.out))
} else return(spg.out)
}



If for some reason the entire pgram array is desired (for future changes to
spec.pgram) we can minimize calls to kernapply by calculating the lower
left portion as the complex conjugate:

for (i in 1L:ncol(x)) {
for (j in 1L:ncol(x)) {
if(i <= j) {
pgram[, i, j] <- kernapply(pgram[, i, j], kernel, circular =
TRUE)
} else {
pgram[, i, j] <- Conj(pgram[, j, i])
}
}
}


Cheers,
Jonathan

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Encoding issues

2019-02-18 Thread Iñaki Ucar
Hi,

We found a (to our eyes) strange behaviour that might be a bug. First
a little bit of context. The 'units' package allows us to set the unit
using both SE or NSE. E.g., these both work in the same way:

units::set_units(1:10, "μm")
#> Units: [μm]
#> [1]  1  2  3  4  5  6  7  8  9 10

units::set_units(1:10, μm)
#> Units: [μm]
#> [1]  1  2  3  4  5  6  7  8  9 10

That's micrometers, and works fine if the session charset is UTF-8.
Now the funny part comes with Windows. The first version, with quotes,
works fine, but the second one fails. This is easy to demonstrate from
Linux:

LC_CTYPE=en_US.iso88591 Rscript -e 'units::set_units(1:10, "μm")'
#> Units: [μm]
#> [1]  1  2  3  4  5  6  7  8  9 10

LC_CTYPE=en_US.iso88591 Rscript -e 'units::set_units(1:10, μm)'
#> Error: unexpected input in "units::set_units(1:10, μ"
#> Execution halted

However, if you use the first version, with quotes, in an example, and
the package is checked on Windows, it fails too (see
https://ci.appveyor.com/project/edzer/units/builds/22440023#L747). The
package declares UTF-8 encoding, so none of these errors should, in
principle, happen. Am I wrong?

Thanks in advance, regards,
Iñaki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] code for sum function

2019-02-18 Thread Tomas Kalibera
See do_summary() in summary.c, rsum() for doubles. R uses long double 
type as accumulator on systems where available.


Best,
Tomas

On 2/14/19 2:08 PM, Rampal Etienne wrote:

Hello,

I am trying to write FORTRAN code to do the same as some R code I 
have. I get (small) differences when using the sum function in R. I 
know there are numerical routines to improve precision, but I have not 
been able to figure out what algorithm R is using. Does anyone know 
this? Or where can I find the code for the sum function?


Regards,

Rampal Etienne

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Encoding issues

2019-02-18 Thread Gábor Csárdi
>From "Writing R Extensions":

"Only ASCII characters (and the control characters tab, formfeed, LF
and CR) should be used in code files."

So I am afraid you cannot use μm.

Gabor

On Mon, Feb 18, 2019 at 3:36 PM Iñaki Ucar  wrote:
>
> Hi,
>
> We found a (to our eyes) strange behaviour that might be a bug. First
> a little bit of context. The 'units' package allows us to set the unit
> using both SE or NSE. E.g., these both work in the same way:
>
> units::set_units(1:10, "μm")
> #> Units: [μm]
> #> [1]  1  2  3  4  5  6  7  8  9 10
>
> units::set_units(1:10, μm)
> #> Units: [μm]
> #> [1]  1  2  3  4  5  6  7  8  9 10
>
> That's micrometers, and works fine if the session charset is UTF-8.
> Now the funny part comes with Windows. The first version, with quotes,
> works fine, but the second one fails. This is easy to demonstrate from
> Linux:
>
> LC_CTYPE=en_US.iso88591 Rscript -e 'units::set_units(1:10, "μm")'
> #> Units: [μm]
> #> [1]  1  2  3  4  5  6  7  8  9 10
>
> LC_CTYPE=en_US.iso88591 Rscript -e 'units::set_units(1:10, μm)'
> #> Error: unexpected input in "units::set_units(1:10, μ"
> #> Execution halted
>
> However, if you use the first version, with quotes, in an example, and
> the package is checked on Windows, it fails too (see
> https://ci.appveyor.com/project/edzer/units/builds/22440023#L747). The
> package declares UTF-8 encoding, so none of these errors should, in
> principle, happen. Am I wrong?
>
> Thanks in advance, regards,
> Iñaki
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Extract.data.frame.Rd about $.data.frame

2019-02-18 Thread Suharto Anggono Suharto Anggono via R-devel
The statement in R devel:
  There is no \code{data.frame} method for \code{$}, so \code{x$name}
  uses the default method which treats \code{x} as a list (with no partial
  matching of column names).  The replacement method (for \code{$}) checks
  \code{value} for the correct number of rows, and replicates it if necessary.

The added "(with no partial matching of column names)" is wrong. The default 
method of '$' (for extraction) allows partial matching for list; partial 
matching gives warning if option warnPartialMatchDollar is TRUE.


On Fri, 15/2/19, Martin Maechler  wrote:

 Subject: Re: [Rd] Extract.data.frame.Rd about $.data.frame

 Cc: r-devel@r-project.org
 Date: Friday, 15 February, 2019, 4:15 PM
 
> Suharto Anggono Suharto Anggono via R-devel

>on Sun, 10 Feb 2019 16:33:25 + writes:

> In R devel, data.frame method of '$' has been removed, but this part of 
"Details" section of Extract.data.frame.Rd still implies existence of the 
method.
> The \code{data.frame} method for \code{$}, treats \code{x} as a
> list, except that (as of R-3.1.0) partial matching of \code{name} to
> the names of \code{x} will generate a warning; this may become an
> error in future versions.  The replacement method checks
> \code{value} for the correct number of rows, and replicates it if
> necessary.


> Statement from before R 3.1.0 could be used again:

> There is no \code{data.frame} method for \code{$}, so \code{x$name}
> uses the default method which treats \code{x} as a list.  There is a
> replacement method which checks \code{value} for the correct number
> of rows, and replicates it if necessary.


[[elided Yahoo spam]]
I've added a 2 x 2 words of explanation to make it easier to understand.

Now changed.
Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Encoding issues

2019-02-18 Thread Iñaki Ucar
On Mon, 18 Feb 2019 at 17:27, Gábor Csárdi  wrote:
>
> From "Writing R Extensions":
>
> "Only ASCII characters (and the control characters tab, formfeed, LF
> and CR) should be used in code files."
>
> So I am afraid you cannot use μm.

Thanks, Gábor, I missed that bit. Then, is an .Rd file considered a
"code file"? Our surprise comes from the fact that the quoted version
works fine in a test file, but not in an example. Anyway, if they
cause such a documented trouble, it seems that the safest option is to
avoid its use in the first place.

Iñaki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Encoding issues

2019-02-18 Thread Tomas Kalibera
On 2/18/19 4:36 PM, Iñaki Ucar wrote:
> Hi,
>
> We found a (to our eyes) strange behaviour that might be a bug. First
> a little bit of context. The 'units' package allows us to set the unit
> using both SE or NSE. E.g., these both work in the same way:
>
> units::set_units(1:10, "μm")
> #> Units: [μm]
> #> [1]  1  2  3  4  5  6  7  8  9 10
>
> units::set_units(1:10, μm)
> #> Units: [μm]
> #> [1]  1  2  3  4  5  6  7  8  9 10
>
> That's micrometers, and works fine if the session charset is UTF-8.
> Now the funny part comes with Windows. The first version, with quotes,
> works fine, but the second one fails. This is easy to demonstrate from
> Linux:
>
> LC_CTYPE=en_US.iso88591 Rscript -e 'units::set_units(1:10, "μm")'
> #> Units: [μm]
> #> [1]  1  2  3  4  5  6  7  8  9 10
>
> LC_CTYPE=en_US.iso88591 Rscript -e 'units::set_units(1:10, μm)'
> #> Error: unexpected input in "units::set_units(1:10, μ"
> #> Execution halted
>
> However, if you use the first version, with quotes, in an example, and
> the package is checked on Windows, it fails too (see
> https://ci.appveyor.com/project/edzer/units/builds/22440023#L747). The
> package declares UTF-8 encoding, so none of these errors should, in
> principle, happen. Am I wrong?

Hi Iñaki,

if you want to report a bug against R, please try to provide a minimum 
reproducible example that only uses base packages (not units) and please 
also see WRE sections 1.3, 1.6.3, including:

"There is a portable way to have arbitrary text in character strings 
(only) in your R code, which is to supply them in Unicode as ‘\u’ 
escapes."

"If your package specifies an encoding in its DESCRIPTION file, you 
should run these tools in a locale which makes use of that encoding" 
(includes R CMD check)

Even though there are portable ways to have a string constant literal in 
source code in UTF-8, not representable in the current native encoding 
(e.g. using \u escapes), it does not mean that such a string can be 
freely used in R. Many operations require conversion to the current 
native encoding, which will cause an error or unexpected result. Such 
conversions can happen any time (except when they are documented not to 
happen).

Implementing an API that will work with such strings in a package would 
be hard to get right, but not impossible. NSE will not work 
(non-representable strings, which are not string constant literals, are 
not supported). One can save a lot of headaches by using only ASCII in 
function APIs.

Best
Tomas

>
> Thanks in advance, regards,
> Iñaki
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Encoding issues

2019-02-18 Thread Gábor Csárdi
On Mon, Feb 18, 2019 at 4:42 PM Iñaki Ucar  wrote:
>
> On Mon, 18 Feb 2019 at 17:27, Gábor Csárdi  wrote:
> >
> > From "Writing R Extensions":
> >
> > "Only ASCII characters (and the control characters tab, formfeed, LF
> > and CR) should be used in code files."
> >
> > So I am afraid you cannot use μm.
>
> Thanks, Gábor, I missed that bit. Then, is an .Rd file considered a
> "code file"? Our surprise comes from the fact that the quoted version
> works fine in a test file, but not in an example. Anyway, if they
> cause such a documented trouble, it seems that the safest option is to
> avoid its use in the first place.

I don't think an Rd file is considered a code file, but you might have
problems there as well, as I believe that Rd files are manipulated in
the local encoding.

Gabor

>
> Iñaki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Extract.data.frame.Rd about $.data.frame

2019-02-18 Thread Martin Maechler
> Suharto Anggono Suharto Anggono via R-devel 
> on Mon, 18 Feb 2019 16:37:01 + writes:

> The statement in R devel: There is no \code{data.frame}
> method for \code{$}, so \code{x$name} uses the default
> method which treats \code{x} as a list (with no partial
> matching of column names).  The replacement method (for
> \code{$}) checks \code{value} for the correct number of
> rows, and replicates it if necessary.

> The added "(with no partial matching of column names)" is
> wrong. The default method of '$' (for extraction) allows
> partial matching for list; partial matching gives warning
> if option warnPartialMatchDollar is TRUE.

Yes, thank you!
Indeed, of course it *is* matched when it can be matched uniquely;
otherwise it's silently not matched, returning NULL;
all as it has always been and well documented in ?Extract.

Martin

> 
> On Fri, 15/2/19, Martin Maechler
>  wrote:

>  Subject: Re: [Rd] Extract.data.frame.Rd about
> $.data.frame

>  Cc: r-devel@r-project.org Date: Friday, 15 February,
> 2019, 4:15 PM
 
> Suharto Anggono Suharto Anggono via R-devel

>on Sun, 10 Feb 2019 16:33:25 + writes:

>> In R devel, data.frame method of '$' has been removed,
>> but this part of "Details" section of
>> Extract.data.frame.Rd still implies existence of the
>> method.  The \code{data.frame} method for \code{$},
>> treats \code{x} as a list, except that (as of R-3.1.0)
>> partial matching of \code{name} to the names of \code{x}
>> will generate a warning; this may become an error in
>> future versions.  The replacement method checks
>> \code{value} for the correct number of rows, and
>> replicates it if necessary.


>> Statement from before R 3.1.0 could be used again:

>> There is no \code{data.frame} method for \code{$}, so
>> \code{x$name} uses the default method which treats
>> \code{x} as a list.  There is a replacement method which
>> checks \code{value} for the correct number of rows, and
>> replicates it if necessary.


> [[elided Yahoo spam]] I've added a 2 x 2 words of
> explanation to make it easier to understand.

> Now changed.  Martin

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Error in rbind(info, getNamespaceInfo(env, "S3methods"))

2019-02-18 Thread Matt Dowle
Dear all,

I'm experiencing an unusual installation error for one package. Could
anyone suggest how I can best investigate this from here please?  I'm sorry
this isn't very much to go on. Hopefully someone can point me in the right
direction.

The problem seems to be my library.  It is large (3,418 packages) and I'd
like to avoid rebuilding it, if possible.  All packages are up to date
according to update.packages().

The error is :
** byte-compile and prepare package for lazy loading
Error in rbind(info, getNamespaceInfo(env, "S3methods")) :
  number of columns of matrices must match (see arg 2)
ERROR: lazy loading failed for package ‘staRdom’
* removing ‘/home/mdowle/build/revdeplib/staRdom’

This package (staRdom) has had a recent update but CRAN checks page is
showing OK, mostly:
https://cran.r-project.org/web/checks/check_results_staRdom.html.   The two
errors there don't seem to be related.

The package installs no problem when I don't include my revdeplib.  But
when I do include my revdeplib it fails with the error above.

I can reproduce as follows :

$ export R_LIBS=~/build/revdeplib/
$ R
> .libPaths()
[1] "/home/mdowle/build/revdeplib" "/usr/lib/R/library"
> install.packages("staRdom")
Installing package into ‘/home/mdowle/build/revdeplib’
(as ‘lib’ is unspecified)
trying URL 'http://cloud.r-project.org/src/contrib/staRdom_1.0.12.tar.gz'
Content type 'application/x-gzip' length 2669832 bytes (2.5 MB)
==
downloaded 2.5 MB
* installing *source* package ‘staRdom’ ...
** package ‘staRdom’ successfully unpacked and MD5 sums checked
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error in rbind(info, getNamespaceInfo(env, "S3methods")) :
  number of columns of matrices must match (see arg 2)
ERROR: lazy loading failed for package ‘staRdom’
* removing ‘/home/mdowle/build/revdeplib/staRdom’
The downloaded source packages are in
‘/tmp/RtmprvTDCg/downloaded_packages’
Warning message:
In install.packages("staRdom") :
  installation of package ‘staRdom’ had non-zero exit status
>
> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
 [8] LC_NAME=C  LC_ADDRESS=C   LC_TELEPHONE=C
   LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2
>


If I don't include my revdeplib library,  it works fine :

$ R
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
 "/usr/lib/R/library"
> install.packages("staRdom")
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
trying URL 'http://cloud.r-project.org/src/contrib/staRdom_1.0.12.tar.gz'
Content type 'application/x-gzip' length 2669832 bytes (2.5 MB)
==
downloaded 2.5 MB

* installing *source* package ‘staRdom’ ...
** package ‘staRdom’ successfully unpacked and MD5 sums checked
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (staRdom)

The downloaded source packages are in
‘/tmp/RtmpmSiZLa/downloaded_packages’
>
> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
 [8] LC_NAME=C  LC_ADDRESS=C   LC_TELEPHONE=C
   LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2
>

I'm not sure how to debug this because both install.packages() and `R CMD
check` start a new instance of R. How do a get debugger() prompt at the
point of the error? All I can think of is inserting a browser() in my own
compile of R-devel. But that seems a big step. I thought I'd post here
first to see if anyone had any suggestions in how to proceed.

Thanks in advance,
Matt

[[alternative HTML version deleted]]

___

Re: [Rd] Error in rbind(info, getNamespaceInfo(env, "S3methods"))

2019-02-18 Thread Duncan Murdoch

On 18/02/2019 4:08 p.m., Matt Dowle wrote:

Dear all,

I'm experiencing an unusual installation error for one package. Could
anyone suggest how I can best investigate this from here please?  I'm sorry
this isn't very much to go on. Hopefully someone can point me in the right
direction.


When packages are installed, a hidden environment is created called 
".__NAMESPACE__.".  It contains a number of objects; it looks as though 
one of yours called "S3methods" is corrupted.  I can't guess whether it 
is one coming from staRdom or one already in your library, but it 
appears yours doesn't have the usual number of columns (which I think is 3).


So you could get a list of all packages in your library, and run

sapply(allpackages, function(x) 
ncol(asNamespace(x)$.__NAMESPACE__.$S3methods))


to see which of them don't return 3 as the number of columns.  (This 
will load all of them, so might need to be broken up into batches.)


Duncan Murdoch



The problem seems to be my library.  It is large (3,418 packages) and I'd
like to avoid rebuilding it, if possible.  All packages are up to date
according to update.packages().

The error is :
** byte-compile and prepare package for lazy loading
Error in rbind(info, getNamespaceInfo(env, "S3methods")) :
   number of columns of matrices must match (see arg 2)
ERROR: lazy loading failed for package ‘staRdom’
* removing ‘/home/mdowle/build/revdeplib/staRdom’

This package (staRdom) has had a recent update but CRAN checks page is
showing OK, mostly:
https://cran.r-project.org/web/checks/check_results_staRdom.html.   The two
errors there don't seem to be related.

The package installs no problem when I don't include my revdeplib.  But
when I do include my revdeplib it fails with the error above.

I can reproduce as follows :

$ export R_LIBS=~/build/revdeplib/
$ R

.libPaths()

[1] "/home/mdowle/build/revdeplib" "/usr/lib/R/library"

install.packages("staRdom")

Installing package into ‘/home/mdowle/build/revdeplib’
(as ‘lib’ is unspecified)
trying URL 'http://cloud.r-project.org/src/contrib/staRdom_1.0.12.tar.gz'
Content type 'application/x-gzip' length 2669832 bytes (2.5 MB)
==
downloaded 2.5 MB
* installing *source* package ‘staRdom’ ...
** package ‘staRdom’ successfully unpacked and MD5 sums checked
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error in rbind(info, getNamespaceInfo(env, "S3methods")) :
   number of columns of matrices must match (see arg 2)
ERROR: lazy loading failed for package ‘staRdom’
* removing ‘/home/mdowle/build/revdeplib/staRdom’
The downloaded source packages are in
 ‘/tmp/RtmprvTDCg/downloaded_packages’
Warning message:
In install.packages("staRdom") :
   installation of package ‘staRdom’ had non-zero exit status


sessionInfo()

R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
  [8] LC_NAME=C  LC_ADDRESS=C   LC_TELEPHONE=C
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2





If I don't include my revdeplib library,  it works fine :

$ R

.libPaths()

[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
  "/usr/lib/R/library"

install.packages("staRdom")

Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
trying URL 'http://cloud.r-project.org/src/contrib/staRdom_1.0.12.tar.gz'
Content type 'application/x-gzip' length 2669832 bytes (2.5 MB)
==
downloaded 2.5 MB

* installing *source* package ‘staRdom’ ...
** package ‘staRdom’ successfully unpacked and MD5 sums checked
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (staRdom)

The downloaded source packages are in
 ‘/tmp/RtmpmSiZLa/downloaded_packages’


sessionInfo()

R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
  [8] LC_NAME=C  

Re: [Rd] Error in rbind(info, getNamespaceInfo(env, "S3methods"))

2019-02-18 Thread Matt Dowle
Thanks, Duncan.
I took the approach you suggested and eventually found it was due to
R.matlab (staRdom imports R.matlab).

> require(R.matlab)
Loading required package: R.matlab
Error: package or namespace load failed for ‘R.matlab’ in rbind(info,
getNamespaceInfo(env, "S3methods")):
 number of columns of matrices must match (see arg 2)
Warning message:
package ‘R.matlab’ was built under R version 3.6.0
> R.version.string
[1] "R version 3.5.2 (2018-12-20)"

At some point in the past I guess I used R-devel with this library and it
installed R.matlab using R-devel.

Reinstalling R.matlab did the trick and staRdom works fine now.
I checked that none of the other 2,643 packages in this library were built
using R>3.5.2.  It was just R.matlab.

Thanks for your help!
Best, Matt

On Mon, Feb 18, 2019 at 1:28 PM Duncan Murdoch 
wrote:

> On 18/02/2019 4:08 p.m., Matt Dowle wrote:
> > Dear all,
> >
> > I'm experiencing an unusual installation error for one package. Could
> > anyone suggest how I can best investigate this from here please?  I'm
> sorry
> > this isn't very much to go on. Hopefully someone can point me in the
> right
> > direction.
>
> When packages are installed, a hidden environment is created called
> ".__NAMESPACE__.".  It contains a number of objects; it looks as though
> one of yours called "S3methods" is corrupted.  I can't guess whether it
> is one coming from staRdom or one already in your library, but it
> appears yours doesn't have the usual number of columns (which I think is
> 3).
>
> So you could get a list of all packages in your library, and run
>
> sapply(allpackages, function(x)
> ncol(asNamespace(x)$.__NAMESPACE__.$S3methods))
>
> to see which of them don't return 3 as the number of columns.  (This
> will load all of them, so might need to be broken up into batches.)
>
> Duncan Murdoch
>
> >
> > The problem seems to be my library.  It is large (3,418 packages) and I'd
> > like to avoid rebuilding it, if possible.  All packages are up to date
> > according to update.packages().
> >
> > The error is :
> > ** byte-compile and prepare package for lazy loading
> > Error in rbind(info, getNamespaceInfo(env, "S3methods")) :
> >number of columns of matrices must match (see arg 2)
> > ERROR: lazy loading failed for package ‘staRdom’
> > * removing ‘/home/mdowle/build/revdeplib/staRdom’
> >
> > This package (staRdom) has had a recent update but CRAN checks page is
> > showing OK, mostly:
> > https://cran.r-project.org/web/checks/check_results_staRdom.html.   The
> two
> > errors there don't seem to be related.
> >
> > The package installs no problem when I don't include my revdeplib.  But
> > when I do include my revdeplib it fails with the error above.
> >
> > I can reproduce as follows :
> >
> > $ export R_LIBS=~/build/revdeplib/
> > $ R
> >> .libPaths()
> > [1] "/home/mdowle/build/revdeplib" "/usr/lib/R/library"
> >> install.packages("staRdom")
> > Installing package into ‘/home/mdowle/build/revdeplib’
> > (as ‘lib’ is unspecified)
> > trying URL 'http://cloud.r-project.org/src/contrib/staRdom_1.0.12.tar.gz
> '
> > Content type 'application/x-gzip' length 2669832 bytes (2.5 MB)
> > ==
> > downloaded 2.5 MB
> > * installing *source* package ‘staRdom’ ...
> > ** package ‘staRdom’ successfully unpacked and MD5 sums checked
> > ** R
> > ** data
> > *** moving datasets to lazyload DB
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > Error in rbind(info, getNamespaceInfo(env, "S3methods")) :
> >number of columns of matrices must match (see arg 2)
> > ERROR: lazy loading failed for package ‘staRdom’
> > * removing ‘/home/mdowle/build/revdeplib/staRdom’
> > The downloaded source packages are in
> >  ‘/tmp/RtmprvTDCg/downloaded_packages’
> > Warning message:
> > In install.packages("staRdom") :
> >installation of package ‘staRdom’ had non-zero exit status
> >>
> >> sessionInfo()
> > R version 3.5.2 (2018-12-20)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.2 LTS
> >
> > Matrix products: default
> > BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
> > LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so
> >
> > locale:
> >   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >   LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >   LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> > LC_PAPER=en_US.UTF-8
> >   [8] LC_NAME=C  LC_ADDRESS=C
>  LC_TELEPHONE=C
> > LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.5.2 tools_3.5.2
> >>
> >
> >
> > If I don't include my revdeplib library,  it works fine :
> >
> > $ R
> >> .libPaths()
> > [1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
> >   "/usr/lib/R/library"
> >> install.packages("staRdom")
> > Installing package into