[Rd] CRAN testing
Is the mechanism by which packages are tested on CRAN described anywhere? Is it by any chance written in R? The FastR <https://bitbucket.org/allr/fastr/wiki/Home> team is interested in running a virtual CRAN where we can test all the CRAN packages on FastR. Thanks Mick Jordan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [ on call
I'm rather puzzled by this behavior:
e
export("caption<-", "caption", "label", "label<-", "align<-",
"align", "digits<-", "digits", "display<-", "display", "xtable",
"print.xtable", "toLatex.xtable")
> e[[1L]]
e[[1L]]
export
> e[-1L]
e[-1L]
"caption<-"("caption", "label", "label<-", "align<-", "align",
"digits<-", "digits", "display<-", "display", "xtable",
"print.xtable",
"toLatex.xtable")
I'm not at all clear what should result from removing the first element,
i.e. the 'export', but I would not expect the first argument to be
promoted into the function position. I guess I would expect a coercion
to list or pairlist first, after which the [-1L] would produce a
meaningful result on that coercion. In any event I do observe that
as.character(e[-1L]) produces the expected result:
as.character(e[-1L])
[1] "caption<-" "caption""label" "label<-"
[5] "align<-""align" "digits<-" "digits"
[9] "display<-" "display""xtable" "print.xtable"
[13] "toLatex.xtable"
This code is from parseNamespaceFile (on the xtable package).
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem building R-3.2.4
I am trying to build R-3.2.4 on an Oracle Enterprise Linux system, where I have previously built R-3.1.3 and predecessors without problems. I ran "./configure --with-x=no" ok. The make fails in src/extra/xz with what looks like a Makefile problem: liblzma.a: $(liblzma_a_OBJECTS) $rm -f $@ $(AR) -cr $@ $(liblzma_a_OBJECTS) $(RANLIB) $@ What I see in the make log is: gcc -std=gnu99 -I./api -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -fopenmp -g -O2 -c x86.c -o x86.o m -f liblzma.a make[4]: m: Command not found make[4]: *** [liblzma.a] Error 127 make[4]: Leaving directory `/tmp/R-3.2.4/src/extra/xz' make[3]: *** [R] Error 2 make[3]: Leaving directory `/tmp/R-3.2.4/src/extra/xz' make[2]: *** [make.xz] Error 2 make[2]: Leaving directory `/tmp/R-3.2.4/src/extra' make[1]: *** [R] Error 1 make[1]: Leaving directory `/tmp/R-3.2.4/src' make: *** [R] Error 1 I'm very suspicious of the "$rm -f @a" line, which also appears in the Makefile.in. Seems like $r has resolved to empty leading to the command "m -f liblzma.a" Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R-3.2.4
On 3/10/16 9:22 AM, Dirk Eddelbuettel wrote: The same issue was already reported (and resolved) in the bug tracker earlier today. All this is due to 'most systems' using their system lzma (so the issue was not tickled in eg all the Debian and Ubuntu builds we do) but you here do not -- and hence got bitten by a Makefile typo. Just fix it locally to @rm -f $@ or use a system lzma. More details at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16755 Thx. I made that change optimistically and it worked. Aren't thsee multiple Linux platforms a pain. BTW, Firefox claimed that the bugzilla URL was insecure: The owner of bugs.r-project.org has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Regression in strptime
This is definitely obscure but we had a unit test that called .Internal(strptime, "1942/01/01", %Y/%m/%d") with timezone (TZ) set to CET. In R-3.1.3 that returned "1942-01-01 CEST" which, paradoxically, is correct as they evidently did strange things in Germany during the war period. Java also returns the same. However, R-3.2.4 returns "1942-01-01 CET". Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-3.2.4 Mac/Linux different in < on characters
Linux:
> x<-c("0","1");y<-c("a","-1"); xIn Java,FWIW, I get the Mac answer if I use String.compareTo and the
Linux answer if I use Collator.compareTo, but the result is consistent
on Mac and Linux.
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.2.4 Mac/Linux different in < on characters
On 3/11/16 6:52 PM, Mick Jordan wrote:
Linux:
> x<-c("0","1");y<-c("a","-1"); xIn Java,FWIW, I get the Mac answer if I use String.compareTo and the
Linux answer if I use Collator.compareTo, but the result is consistent
on Mac and Linux.
So this is probably related to the fact that the Linux system in
question answers "ICU not in use" whereas the Mac answers "root"?
Mick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Regression in strptime
On 3/12/16 12:33 AM, peter dalgaard wrote:
On 12 Mar 2016, at 00:05 , Mick Jordan wrote:
This is definitely obscure but we had a unit test that called .Internal(strptime,
"1942/01/01", %Y/%m/%d") with timezone (TZ) set to CET.
Umm, that doesn't even parse. And fixing the typo, it doesn't run:
.Internal(strptime, "1942/01/01", %Y/%m/%d")
Error: unexpected SPECIAL in ".Internal(strptime, "1942/01/01", %Y/%"
.Internal(strptime, "1942/01/01", "%Y/%m/%d")
Error in .Internal(strptime, "1942/01/01", "%Y/%m/%d") :
3 arguments passed to '.Internal' which requires 1
In R-3.1.3 that returned "1942-01-01 CEST" which, paradoxically, is correct as they
evidently did strange things in Germany during the war period. Java also returns the same. However,
R-3.2.4 returns "1942-01-01 CET".
Did you mean:
pd$ r-release-branch/BUILD-dist/bin/R
R version 3.2.4 Patched (2016-03-10 r70319) -- "Very Secure Dishes"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin13.4.0/x86_64 (64-bit)
[...]
strptime("1942/01/01", "%Y/%m/%d", tz="CET")
[1] "1942-01-01 CEST"
But then as you see, it does have DST on New Years Day.
All in all, there is something you are not telling us.
Notice that all DST information is OS dependent as it depends on which version of the
"Olson database" is installed.
You are correct that I was sloppy with syntax for the example. We are,
for better or worse, calling the .Internal, but actually with a large
vector of arguments, of which the 1942 entry is element 82. I can
confirm that for the vector of length 1 example that I didn't test but
just assumed would also fail, the answer is correct. However, it is not
for the full vector:
> .Internal(strptime(argv[[1]], argv[[2]], "CET"))
[1] "1937-01-01 CET" "1916-01-01 CET" "1913-01-01 CET" "1927-01-01 CET"
[5] "1947-01-01 CET" "1913-01-01 CET" "1917-01-01 CET" "1923-01-01 CET"
[9] "1921-01-01 CET" "1926-01-01 CET" "1920-01-01 CET" "1915-01-01 CET"
[13] "1914-01-01 CET" "1914-01-01 CET" "1914-01-01 CET" "1919-01-01 CET"
[17] "1948-01-01 CET" "1911-01-01 CET" "1909-01-01 CET" "1913-01-01 CET"
[21] "1925-01-01 CET" "1926-01-01 CET" "1910-01-01 CET" "1917-01-01 CET"
[25] "1936-01-01 CET" "1938-01-01 CET" "1960-01-01 CET" "1915-01-01 CET"
[29] "1919-01-01 CET" "1924-01-01 CET" "1914-01-01 CET" "1905-01-01 CET"
[33] "1921-01-01 CET" "1929-01-01 CET" "1926-01-01 CET" "1921-01-01 CET"
[37] "1908-01-01 CET" "1928-01-01 CET" "1919-01-01 CET" "1921-01-01 CET"
[41] "1925-01-01 CET" "1934-01-01 CET" "1927-01-01 CET" "1928-01-01 CET"
[45] "1934-01-01 CET" "1922-01-01 CET" "1923-01-01 CET" "1915-01-01 CET"
[49] "1934-01-01 CET" "1925-01-01 CET" "1922-01-01 CET" "1930-01-01 CET"
[53] "1924-01-01 CET" "1923-01-01 CET" "1919-01-01 CET" "1932-01-01 CET"
[57] "1930-01-01 CET" "1923-01-01 CET" "1930-01-01 CET" "1922-01-01 CET"
[61] "1919-01-01 CET" "1932-01-01 CET" "1939-01-01 CET" "1923-01-01 CET"
[65] "1920-01-01 CET" "1919-01-01 CET" "1952-01-01 CET" "1927-01-01 CET"
[69] "1924-01-01 CET" "1919-01-01 CET" "1925-01-01 CET" "1945-01-01 CET"
[73] "1916-01-01 CET" "1943-01-01 CET" "1920-01-01 CET" "1920-01-01 CET"
[77] "1931-01-01 CET" "1924-01-01 CET" "1919-01-01 CET" "1926-01-01 CET"
[81] "1920-01-01 CET" "1942-01-01 CET" "1919-01-01 CET" "1930-01-01 CET"
[85] "1925-01-01 CET" "1924-01-01 CET" "1926-01-01 CET" "1918-01-01 CET"
[89] "1922-01-01 CET" "1921-01-01 CET" "1925-01-01 CET" "1928-01-01 CET"
[93] "1925-01-01 CET" "1929-01-01 CET" "1933-01-01 CET" "1947-01-01 CET"
[97] "1950-01-01 CET" "1945-01-01 CET" "1924-01-01 CET" "1939-01-01 CET"
[101] "1924-01-01 CET" "1933-01-01 CET" "1928-01-01 CET"
> .Internal( strptime("1942/01/01", "%Y/%m/%d", '
[Rd] Help with libiconv problem
A couple of my colleagues are having problems building R-3.2.4 on Mac OS X El Capitan somehow related to libiconv. I personally don't have any problems on either of my Macs. I'm hoping thie make log might trigger something in the readers of this list: gcc -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L../../../../lib -L/usr/local/lib -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -L../../../../lib -lR -Wl,-framework -Wl,CoreFoundation mkdir ../../../../library/tools/libs installing 'sysdata.rda' Warning messages: 1: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") : unknown timezone 'America/Los_Angeles' 2: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") : unknown timezone 'GMT' 3: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") : unknown timezone 'America/New_York' dyld: lazy symbol binding failed: Symbol not found: _libiconv_open Referenced from: /Users/someone/work/abc/fastr/com.oracle.truffle.r.native/gnur/R-3.2.4/lib/libR.dylib Expected in: flat namespace dyld: Symbol not found: _libiconv_open Referenced from: /Users/someone/work/abc/fastr/com.oracle.truffle.r.native/gnur/R-3.2.4/lib/libR.dylib Expected in: flat namespace /bin/sh: line 1: 16127 Doneecho "tools:::sysdata2LazyLoadDB(\"./R/sysdata.rda\",\"../../../library/tools/R\")" 16128 Trace/BPT trap: 5 | R_DEFAULT_PACKAGES=NULL LC_ALL=C ../../../bin/R --vanilla --slave make[7]: *** [sysdata] Error 133 make[6]: *** [all] Error 2 make[5]: *** [R] Error 1 make[4]: *** [R] Error 1 make[3]: *** [R] Error 1 We always get the unknown timezone messages which I think are unrelated but I'm curious about those. Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help with libiconv problem
On 3/14/16 1:49 PM, Mick Jordan wrote: A couple of my colleagues are having problems building R-3.2.4 on Mac OS X El Capitan somehow related to libiconv. I personally don't have any problems on either of my Macs. I'm hoping thie make log might trigger something in the readers of this list: gcc -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L../../../../lib -L/usr/local/lib -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -L../../../../lib -lR -Wl,-framework -Wl,CoreFoundation mkdir ../../../../library/tools/libs installing 'sysdata.rda' Warning messages: 1: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") : unknown timezone 'America/Los_Angeles' 2: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") : unknown timezone 'GMT' 3: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") : unknown timezone 'America/New_York' dyld: lazy symbol binding failed: Symbol not found: _libiconv_open Referenced from: /Users/someone/work/abc/fastr/com.oracle.truffle.r.native/gnur/R-3.2.4/lib/libR.dylib Expected in: flat namespace dyld: Symbol not found: _libiconv_open Referenced from: /Users/someone/work/abc/fastr/com.oracle.truffle.r.native/gnur/R-3.2.4/lib/libR.dylib Expected in: flat namespace /bin/sh: line 1: 16127 Doneecho "tools:::sysdata2LazyLoadDB(\"./R/sysdata.rda\",\"../../../library/tools/R\")" 16128 Trace/BPT trap: 5 | R_DEFAULT_PACKAGES=NULL LC_ALL=C ../../../bin/R --vanilla --slave make[7]: *** [sysdata] Error 133 make[6]: *** [all] Error 2 make[5]: *** [R] Error 1 make[4]: *** [R] Error 1 make[3]: *** [R] Error 1 This seems to be related to having a macports install of libiconv. The compile step for sysutils.c puts the macport include header before /usr/local/include but the link step for libR doesn't - in fact it doesn't include a -L for the macport directory at all. So there is an an inconsistency in the expected symbols. (Why the macport version defines libiconv_open instead of iconv_open I have no idea). ick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Regression in strptime
On 3/15/16 3:52 AM, Martin Maechler wrote:
peter dalgaard
on Sat, 12 Mar 2016 19:11:40 +0100 writes:
> OK, .Internal is not necessary to reproduce oddity in this area. I also
see things like (notice 1980)
>> strptime(paste0(sample(1900:1999,80,replace=TRUE),"/01/01"), "%Y/%m/%d",
tz="CET")
...
> The issue seems to be present in R-devel but not in (CRAN) 3.2.0
nor in R 3.2.3 (and earlier), but indeed unfortunately in 3.2.4.
This has been fixed now in "R 3.2.4 patched" (and R-devel of course).
Thank you Mick, for the report...
...
...
though I "must" add: If you do have your own tests / checks (as
you said in the OP) and are company as big as Oracle using the
free (in the full sense of "speech" *and* "beer") software R,
it would be *really* *really* courteous if you did run your test
suite when we announce and release betas or release candidates
("RC") (and in the case of the upcoming yearly release in April,
even "alphas" before them) so we, the R community and the R core
developers could find bugs *before* release.
Following up on Lukas's explanatory message, we will try to sync up with
R releases on a more regular schedule from now on, even if we don't
actually push FastR based on that version. So we should discover test
regressions earlier.
Mick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sys.function(0)
As I understand https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html sys.function(n) returns the function associated with stack frame n. Since frame 0 is defined as .GlobalEnv which is not associated with a function, I would expect this to always return NULL. However, it does not: > sys.function() NULL > f <- function(x) sys.function(x) > f(0) function(x) sys.function(x) > f(1) function(x) sys.function(x) > f(2) Error in sys.function(x) : not that many frames on the stack Why the different behavior when sys.function(0) is called inside another function? Mick Jordan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.function(0)
On 3/27/16 2:46 PM, peter dalgaard wrote: On 27 Mar 2016, at 22:05 , Mick Jordan wrote: As I understand https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html sys.function(n) returns the function associated with stack frame n. Since frame 0 is defined as .GlobalEnv which is not associated with a function, I would expect this to always return NULL. However, it does not: sys.function() NULL f <- function(x) sys.function(x) f(0) function(x) sys.function(x) f(1) function(x) sys.function(x) f(2) Error in sys.function(x) : not that many frames on the stack Why the different behavior when sys.function(0) is called inside another function? This is a documentation bug. The case "which = 0" differs between sys.frame() and sys.call()/sys.function(). For the latter, it means the current call/function, whereas sys.frame(0) is always the global envir. It is pretty clear from the underlying C code that the three functions treat their argument differently: R_sysframe has if (n == 0) return(R_GlobalEnv); if (n > 0) n = framedepth(cptr) - n; else n = -n; whereas the other two (R_syscall and R_sysfunction) omit the special treatment for n==0. Without this, n==0, comes out unchanged from the if-construct, indicating that one should go 0 frames up the stack (same as n==framedepth(cptr)). Obviously, it won't work to document the "which" argument identically for all three functions... Thanks. I didn't look at the C code this time trusting the documentation ;-) A related question is why are sys.parent/parent.frame so permissive in their error checking? E.g: > sys.parent(-1) [1] 0 > sys.parent(-2) [1] 0 > sys.parent(1) [1] 0 > sys.parent(2) [1] 0 > parent.frame(4) > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] debug/recover/.Internal
I was surprised by difference between using options(error=browser) and
options(error=recover) when handling an error from sys.frame that I
assume is related to the fact that the error is thrown from the
.Internal and the 'which' parameter to the closure isn't available.
> options(error=browser)
> f <- function() sys.frame(-3)
> f()
Error in sys.frame(-3) : not that many frames on the stack
Called from: sys.frame(-3)
Browse[1]> where
where 1 at #1: sys.frame(-3)
where 2: f()
Browse[1]> print(which)
function (x, arr.ind = FALSE, useNames = TRUE)
{
wh <- .Internal(which(x))
if (arr.ind && !is.null(d <- dim(x)))
arrayInd(wh, d, dimnames(x), useNames = useNames)
else wh
}
Whereas:
> options(error=recover)
> f()
Error in sys.frame(-3) : not that many frames on the stack
Enter a frame number, or 0 to exit
1: f()
2: #1: sys.frame(-3)
Selection: 2
Called from: top level
Browse[1]> print(which)
[1] -3
Browse[1]>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Note: no visible definition
Can someone explain a message of this form from an rscript execution: Note: no visible global function definition for 'foo' This happens right at the start of execution. 'foo' is only executed in a branch of an 'if' that is not reached with the particular arguments passed to the script. If I source the script in a shell and run it I do not get the message. Mick Jordan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Note: no visible definition
On 4/9/16 10:54 AM, Dirk Eddelbuettel wrote: On 9 April 2016 at 10:28, Mick Jordan wrote: | Can someone explain a message of this form from an rscript execution: | | Note: no visible global function definition for 'foo' | | | This happens right at the start of execution. 'foo' is only executed in | a branch of an 'if' that is not reached with the particular arguments | passed to the script. If I source the script in a shell and run it I do | not get the message. Guess: your shell session has an object foo. It will be referenced. Your Rscript, running from 'empty' never defines foo. And codetools tells you that because more often than not it is error. Sometimes codetools gets it wrong too, ie with you peek into data structure via evaluation tricks or with simple with(mydataframe, columnOne). No, the symbol is acytually defined in a package that is not loaded when running under GnuR. But I still don't understand what is even trying to find the symbol in an execution path that doesn't reference it. I'm not sure what you mean by codetools, but is it examining my source code somehow before it is executed? That would be unexpected at best. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Note: no visible definition
On 4/9/16 12:13 PM, Duncan Murdoch wrote: On 09/04/2016 2:55 PM, Mick Jordan wrote: On 4/9/16 10:54 AM, Dirk Eddelbuettel wrote: On 9 April 2016 at 10:28, Mick Jordan wrote: | Can someone explain a message of this form from an rscript execution: | | Note: no visible global function definition for 'foo' | | | This happens right at the start of execution. 'foo' is only executed in | a branch of an 'if' that is not reached with the particular arguments | passed to the script. If I source the script in a shell and run it I do | not get the message. Guess: your shell session has an object foo. It will be referenced. Your Rscript, running from 'empty' never defines foo. And codetools tells you that because more often than not it is error. Sometimes codetools gets it wrong too, ie with you peek into data structure via evaluation tricks or with simple with(mydataframe, columnOne). No, the symbol is acytually defined in a package that is not loaded when running under GnuR. But I still don't understand what is even trying to find the symbol in an execution path that doesn't reference it. I'm not sure what you mean by codetools, but is it examining my source code somehow before it is executed? That would be unexpected at best. That message comes from the compiler package, so presumbly you (or Rscript) are trying to compile something. You can't have undefined references in compiled code. Duncan Murdoch Ah, so if the jit is enabled that would do it? we are no explicitly compiling anything but it turns out I was setting R_ENABLE_JIT (accidently). Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-3.2.5 Mac OS X package
When is the R-3.2.5 binary for Mac OS X likely to show up? Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.2.5 Mac OS X package
On 5/2/16 4:25 PM, David Winsemius wrote: On May 2, 2016, at 3:45 PM, Mick Jordan wrote: When is the R-3.2.5 binary for Mac OS X likely to show up? Where did you look? I see both Mavericks and SnowLeopard fork binaries with or without r.app GUI at http://r.research.att.com/ I've been using the 3.3.0 RC for a while with only relative minor and mostly expected difficulties relating to packages that have external dependencies. I was looking at https://cran.r-project.org/ which only shows a 3.2.4 pkg. Anyway as 3.3.0 is release this is probably moot. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] vignette/knitr help
I need some help understanding a problem running the tests on the
'digest' package. Initially, I got the message that the 'knitr' package
was needed to run vignettes:
Running vignettes for package ‘digest’
Error in loadVignetteBuilder(vigns$pkgdir) :
vignette builder 'knitr' not found
So I installed the knitr package and all its dependents (‘mime’,
‘stringi’, ‘magrittr’, ‘evaluate’, ‘formatR’, ‘highr’, ‘markdown’,
‘stringr’, ‘yaml’) . Now I get some different warnings:
Running vignettes for package ‘digest’
Running ‘sha1.Rmd’
Warning messages:
1: In readLines(if (is.character(input2)) { :
cannot open file 'sha1.Rmd': No such file or directory
2: In engine$weave(file, quiet = TRUE, encoding = enc) :
The vignette engine knitr::rmarkdown is not available, because the
rmarkdown package is not installed. Please install it.
3: In readLines(con) :
cannot open file 'sha1.Rmd': No such file or directory
So why is sha1.Rmd missing? And why is it complaining about rmarkdown?
Or more precisely why did it not install it as a dependent? It installed
plain markdown.
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette/knitr help
On 5/3/16 11:29 AM, Thierry Onkelinx wrote: Dear Mick, Note that both knitr and rmarkdown are listed under Suggests: both are required to compile the vignette. Installing rmarkdown should solve the problem. If not, please provide more information. OS, R version, digest version, ... This is occurring in the context of an automated testing environment that compares the output of GnuR and FastR. I'm using tools::testInstalledPackage with the default values for 'types'. I guess the problem is that there is no connection between this step and the previous package install step (that did use --install-tests) but didn't install the "Suggests" dependencies because in general these are not needed. But I still am not clear why knitr doesn't list rmarkdown as a dependency when it clearly will try to use it. To me that is is not "Suggests" dependency. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette/knitr help
On 5/3/16 12:19 PM, Thierry Onkelinx wrote:
Dear Mick,
knitr doesn't depends on rmarkdown. It's the vignette that depends on
both knitr (for handle the R chunks) and rmarkdown (for the output
format rmarkdown::html_vignette).
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
states: "The ‘Suggests’ field ...snip... lists packages that are not
necessarily needed. This includes packages used only in examples,
tests or vignettes ...snip... Then it is not necessary to have bar
use foo unless one wants to execute all the examples/tests/vignettes"
So packages in Suggests might be required to compile vignettes.
Ok, I get it now, and a more careful reading of the Writing Extensions
manual would have helped prevent the surprise. Anyway, FastR can't
handle knitr yet so I am backing off to testing types=c("examples, "tests").
Thanks
Mick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Max OSX 3.3.0 and lzma
I have lzma installed (in /usr/local) but R-3.3.0 configure doesn't like something about it: checking for lzma_version_number in -llzma... yes checking lzma.h usability... no checking lzma.h presence... no checking for lzma.h... no configure: error: "liblzma library and headers are required" bash-3.2$ ls /usr/local/lib/*lzma* ls /usr/local/lib/*lzma* /usr/local/lib/liblzma.5.dylib/usr/local/lib/liblzma.a /usr/local/lib/liblzma.dylib bash-3.2$ ls /usr/local/include/*lzma* ls /usr/local/include/*lzma* /usr/local/include/lzma.h /usr/local/include/lzma: base.hblock.hcontainer.hfilter.hindex.h lzma12.hversion.h bcj.hcheck.hdelta.hhardware.h index_hash.h stream_flags.hvli.h I'm no configure wizard so would appreciate a hint. Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] identical on closures
I'm confused by this:
> identical(function() {}, function() {})
[1] FALSE
Yet, after loading the Matrix package (which redefines det), the
following is checked (in library.checkConflicts):
> identical(get("det", baseenv()), get("det", asNamespace("Matrix")),
ignore.environment=T)
[1] TRUE
I've looked at the code in identical.c and for closures it seems to
compare the FORMALS and the BODY_EXPR, so why does the first example not
return TRUE as surely the formals and body are identical?
case CLOSXP:
return(R_compute_identical(FORMALS(x), FORMALS(y), flags) &&
R_compute_identical(BODY_EXPR(x), BODY_EXPR(y), flags) &&
(IGNORE_ENV || CLOENV(x) == CLOENV(y) ? TRUE : FALSE) &&
(IGNORE_BYTECODE || R_compute_identical(BODY(x), BODY(y),
flags))
);
R-3.2.4, Mac OS X El Capitan
Thanks
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical on closures
On 5/20/16 12:40 PM, Mick Jordan wrote:
I'm confused by this:
> identical(function() {}, function() {})
[1] FALSE
Yet, after loading the Matrix package (which redefines det), the
following is checked (in library.checkConflicts):
> identical(get("det", baseenv()), get("det", asNamespace("Matrix")),
ignore.environment=T)
[1] TRUE
I've looked at the code in identical.c and for closures it seems to
compare the FORMALS and the BODY_EXPR, so why does the first example
not return TRUE as surely the formals and body are identical?
case CLOSXP:
return(R_compute_identical(FORMALS(x), FORMALS(y), flags) &&
R_compute_identical(BODY_EXPR(x), BODY_EXPR(y), flags) &&
(IGNORE_ENV || CLOENV(x) == CLOENV(y) ? TRUE : FALSE) &&
(IGNORE_BYTECODE || R_compute_identical(BODY(x), BODY(y),
flags))
);
R-3.2.4, Mac OS X El Capitan
Ok, I figured it out, but this is VERY unintuitive IMHO:
> identical(attributes(function() {}), attributes(function() {}))
[1] FALSE
>
The srcref attribute (obviously) differs.
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical on closures
On 5/20/16 2:00 PM, Gabriel Becker wrote: Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Thanks, and I realized that attributes(f) <- NULL does not help as the srcref attribute is on the body components. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R without graphics
Is it possible to configure and build an R without any graphics support. I..e no grDevices or graphics packages? I tried "--with-x=no --with-cairo=no --with-grDevices=no --with-graphics=no" but it is still building grDevices. My problem is that I am using experimenting with a compiler that cannot compile the Objective-C file, qdCocoa.m, and I don't need graphics for this experiment. Max OS X El Capitan, R-3.2.4. Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R without graphics
On 5/23/16 10:46 PM, Prof Brian Ripley wrote: On 24/05/2016 00:54, Simon Urbanek wrote: Um... any reason why you don't simply disable aqua? That file is only compiled if you enable aqua - it has really nothing to do with grDevices ... Also, you can specify a compiler for Objective-C separately and the manual advises you to do so (to specify Apple's clang). Tried that, but I have to use an old version of clang that can't handle the code. But --with-aqua=no was the solution. On May 23, 2016, at 7:44 PM, Mick Jordan wrote: Is it possible to configure and build an R without any graphics support. I..e no grDevices or graphics packages? I tried "--with-x=no --with-cairo=no --with-grDevices=no --with-graphics=no" Inventing flags does not help you: use configure --help to see what is supported (as the manual says). I have learnt that R manuals are frequently inaccurate or out of date. So from the ./configure script: Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] which is why I tried --with-grDevices=no Reading the manual is faster than posting (and posting Mac-specific Qs to R-sig-mac is more likely to get an informed response). I don't need this kind of grief. I hereby sign off from posting to this list. Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] seq.int/seq.default
This is a message for someone familiar with the implementation.
Superficially the R code for seq.default and the C code for seq.int
appear to be semantically very similar. My question is whether, in fact,
it is intended that behave identically for all inputs. I have found two
cases so far where they differ, first that seq.int will coerce a
character string to a real (via Rf_asReal) whereas seq.default appears
to coerce it to NA and then throws an error:
> seq.default("2", "5")
Error in seq.default("2", "5") : 'from' cannot be NA, NaN or infinite
> seq.int("2", "5")
[1] 2 3 4 5
>
and second, that the error messages for non-numeric arguments differ:
seq.default(to=quote(b), by=2)
Error in is.finite(to) : default method not implemented for type 'symbol'
seq.int(to=quote(b), by=2)
Error in seq.int(to = quote(b), by = 2) :
'to' cannot be NA, NaN or infinite
Please reply off list.
Thanks
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seq.int/seq.default
On 1/4/17 1:26 AM, Martin Maechler wrote:
Mick Jordan
on Tue, 3 Jan 2017 07:57:15 -0800 writes:
> This is a message for someone familiar with the implementation.
> Superficially the R code for seq.default and the C code for seq.int
> appear to be semantically very similar. My question is whether, in fact,
> it is intended that behave identically for all inputs.
Strictly speaking, "no": As usual, RT?Manual (;-)
The help page says in the very first paragraph ('Description'):
‘seq’ is a standard generic with a default method.
‘seq.int’ is a primitive which can be much faster but has a few restrictions.
> I have found two cases so far where they differ, first
> that seq.int will coerce a character string to a real (via
> Rf_asReal) whereas seq.default appears to coerce it to NA
> and then throws an error:
>> seq.default("2", "5")
> Error in seq.default("2", "5") : 'from' cannot be NA, NaN or infinite
>> seq.int("2", "5")
> [1] 2 3 4 5
>>
this may be a bit surprising (if one does _not_ look at the code),
indeed, notably because seq.int() is mentioned to have more
restrictions than seq() which here calls seq.default().
"Surprising" also when considering
> "2":"5"
[1] 2 3 4 5
and the documentation of ':' claims 'from:to' to be the same as
rep(from,to) apart from the case of factors.
--- I am considering a small change in seq.default()
which would make it work for this case, compatibly with ":" and seq.int().
> and second, that the error messages for non-numeric arguments differ:
which I find fine... if the functions where meant to be
identical, we (the R developers) would be silly to have both,
notably as the ".int" suffix has emerged as confusing the
majority of useRs (who don't read help pages).
Rather it has been meant as saying "internal" (including "fast") also for other
such R functions, but the suffix of course is a potential clash
with S3 method naming schemes _and_ the fact that 'int' is used
as type name for integer in other languages, notably C.
> seq.default(to=quote(b), by=2)
> Error in is.finite(to) : default method not implemented for type 'symbol'
which I find a very appropriate and helpful message
> seq.int(to=quote(b), by=2)
> Error in seq.int(to = quote(b), by = 2) :
> 'to' cannot be NA, NaN or infinite
which is true, as well, and there's no "default method" to be
mentioned, but you are right that it would be nicer if the
message mentioned 'symbol' as well.
Thanks for the clarifications. It was surprising that seq.int supported
more types than seq.default. I was expecting the reverse.
BTW, There are a couple of, admittedly odd, cases, exposed by brute
force testing, where seq.int will actually return "missing", which I
presume is not intended, and seq.default behaves differently, vis:
> seq.default(to=1,by=2)
[1] 1
> seq.int(to=1,by=2)
> > x <- seq.int(to=1,by=2)
> x
Error: argument "x" is missing, with no default
Lines 792 and 799 of seq.c return the incoming argument (as opposed to a
value based on its coercion to double via asReal) and this can, as in
the above example, be "missing".
> Please reply off list.
[which I understand as that we should CC you (which of course is
netiquette to do)]
Yes
Thanks
Mick Jordan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seq.int/seq.default
On 1/4/17 8:15 AM, Mick Jordan wrote: Here is another difference that I am guessing is unintended. > y <- seq.int(1L, 3L, length.out=2) > typeof(y) [1] "double" > x <- seq.default(1L, 3L, length.out=2) > typeof(x) [1] "integer" The if (by == R_MissingArg) branch at line 842 doesn't contain a check for "all INTSXP" unlike the if (to == R_MissingArg) branch. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] environment question
According to :https://stat.ethz.ch/R-manual/R-devel/library/base/html/environment.html "If |fun| is a function or a formula then |environment(fun)| returns the environment associated with that function or formula. If |fun| is |NULL| then the current evaluation environment is returned." > environment() > environment(environment) This makes sense, however I have two questions on things that don't seem to make sense: 1. > .Internal(environment(NULL)) Since we are calling from R_GlobalEnv, how can the calling environment be base? 2. In eval.R in library/base/R: .GlobalEnv <- environment() parent.frame <- function(n = 1) .Internal(parent.frame(n)) etc. Since the functions being defined are in base, how can the calling environment be R_GlobalEnv. Or does this just set .GlobalEnv temporarily to base? Thanks Mick Jordan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] environment question
On 5/17/14, 4:00 PM, peter dalgaard wrote: On 17 May 2014, at 19:42 , Mick Jordan wrote: According to :https://stat.ethz.ch/R-manual/R-devel/library/base/html/environment.html "If |fun| is a function or a formula then |environment(fun)| returns the environment associated with that function or formula. If |fun| is |NULL| then the current evaluation environment is returned." environment() environment(environment) This makes sense, however I have two questions on things that don't seem to make sense: 1. .Internal(environment(NULL)) Since we are calling from R_GlobalEnv, how can the calling environment be base? Read the Description section in ?.Internal carefully Basically, you are calling .Internal from the command line. It is not designed to be called from there and only wizards know what happens if it is. (The set of wizards who might know whether it makes any sense at all does not include me!) Well, calling from the shell. Anyway, I was just surprised by the result as, notwithstanding the fact that .Internal is "special", the calling environment is definitely .globalEnv. The enclosing environment might well be different, but that's not what environment(NULL) returns. My curiosity relates to the fact that the two calls have different stack depths, so that the .Internal(environment(NULL)) call has to detect whether it was called via environment() or .Internal(environment(NULL)) in order to return the right answer. 2. In eval.R in library/base/R: .GlobalEnv <- environment() parent.frame <- function(n = 1) .Internal(parent.frame(n)) etc. Since the functions being defined are in base, how can the calling environment be R_GlobalEnv. Or does this just set .GlobalEnv temporarily to base? .GlobalEnv is a variable in base alright. The assignment happens when base is being loaded and _at that point_ the environment is R_GlobalEnv. Sorry, I don't understand how that can be. The function definitions in, say, eval.R, and all the others in library/base/R, end up in base, as made clear by ls(baseenv()). So if these files are evaluated in the "usual way", and the environment() call in eval.R returns globalenv(), then they would, in fact, be defined there and not in baseenv. Now, I realise that this is startup code, so perhaps the implementation does something special and these files really aren't evaluated in the "usual" way. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] environment question
On 5/17/14, 9:02 PM, Simon Urbanek wrote: Thanks, those were exactly the kind of answers that I wanted. More importantly that's not the value forever - note that later there is .GlobalEnv <- globalenv() in base/R/Rprofile which is loaded *after* base/R/*.R which is the value you see when you check after base is locked. That's what I thought might be happening - should have checked the site profile. Now I'm just curious why it's important to have a value for .GlobalEnv during the loading of the base .R files. Mkick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Question on Code snippet semantics
I came across this code in library.R package <- as.character(substitute(package)) where package is the first argument to the "library" function. I've been racking my brains to understand why this is not just an elaborate (and ineffcient) way to write: package <- "package" E.g. > package <- as.character(substitute(package)) > package [1] "package" > Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] vapply definition question
vapply <- function(X, FUN, FUN.VALUE, ..., USE.NAMES = TRUE)
{
FUN <- match.fun(FUN)
if(!is.vector(X) || is.object(X)) X <- as.list(X)
.Internal(vapply(X, FUN, FUN.VALUE, USE.NAMES))
}
This is an implementor question. Basically, what happened to the '...'
args in the call to the .Internal? cf lapply:, where the ... is passed.
lapply <- function (X, FUN, ...)
{
FUN <- match.fun(FUN)
## internal code handles all vector types, including expressions
## However, it would be OK to have attributes which is.vector
## disallows.
if(!is.vector(X) || is.object(X)) X <- as.list(X)
##TODO
## Note ... is not passed down. Rather the internal code
## evaluates FUN(X[i], ...) in the frame of this function
.Internal(lapply(X, FUN, ...))
}
Now both of these functions work when extra arguments are passed, so
evidently the implementation can function whether the .Internal "call"
contains the ... or not. I found other cases, notably in S3 generic
methods where the ... is not passed down.
So, essentially, my question is whether the vapply code "should" be
changed or whether a .Internal implementation should always assume an
implicit ... regardless of the code, if the semantics requires it.
Thanks
Mick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vapply definition question
On 12/16/14, 9:54 PM, Martin Morgan wrote: Hi Mick -- You can see that the source code doesn't contain '...' in the final line ~/src/R-devel/src/library/base/R$ svn annotate lapply.R | grep Internal\(l 38631 ripley .Internal(lapply(X, FUN)) and that it's been there for a long time (I'd guess 'forever') ~/src/R-devel/src/library/base/R$ svn log -r38631 r38631 | ripley | 2006-07-17 14:30:55 -0700 (Mon, 17 Jul 2006) | 2 lines another attempt at a faster lapply so I guess you're looking at a modified version of the function... The implementation detail is in the comment -- FUN(X[i], ...) is evaluated in the frame of lapply. Oh dear, my apologies. It seems that, indeed, we had modified lapply.R (and sapply.R) to add the "...". Ironic in that I am going through the base code and trying to remove all the changes that we made as our implementation was developing, and somehow I missed that one. It's a minor nuisance to have to special case the "..." not being passed, but we can work around it. Thanks Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How do you debug the R implementation?
This is a question for the folks who are developing the C part of the R implementation, and not about R debugging. I'm curious what tools developers use to debug the C implementation on Mac OS and Linux (my two platforms). And, if you happen to use gdb, whether anyone has any macros to simplify seeing inside the R internal data structures. Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gzfile text value
I'm puzzled why gzfile (which the spec says the default mode is "rb")
shows mode="rb" but text="text" from summary when it is in lazy state:
cc <- gzfile("ll.rds")
cc <- gzfile("ll.rds")
> summary(cc)
summary(cc)
$description
[1] "ll.rds"
$class
[1] "gzfile"
$mode
[1] "rb"
$text
[1] "text"
$opened
[1] "closed"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] VPATH build of R on MacOSX
I am trying to do VPATH builds of R3.1.3, i.e. binaries built outside the source directory. It works just fine on Linux but on Mac OSX (Mavericks) I get the following trace from make, after a successful configure step. Any insights gratefully received. make is GNU make 3.81 on both systems. bash-3.2$ make make make[1]: Nothing to be done for `R'. make[1]: Nothing to be done for `R'. make[2]: Nothing to be done for `R'. mkdir ../share/R mkdir ../share/dictionaries mkdir ../share/encodings mkdir ../share/java mkdir ../share/licenses mkdir ../share/make mkdir ../share/sh mkdir ../share/texmf mkdir ../share/texmf/bibtex mkdir ../share/texmf/bibtex/bib mkdir ../share/texmf/bibtex/bst mkdir ../share/texmf/tex mkdir ../share/texmf/tex/latex creating src/scripts/R.fe mkdir ../../bin install: ../../include/Rconfig.h: No such file or directory make[2]: *** [Rconfig.tsa] Error 71 make[1]: *** [R] Error 1 make: *** [R] Error 1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] VPATH build of R on MacOSX
On 3/31/15 10:19 AM, Mick Jordan wrote: I am trying to do VPATH builds of R3.1.3, i.e. binaries built outside the source directory. It works just fine on Linux but on Mac OSX (Mavericks) I get the following trace from make, after a successful configure step. Any insights gratefully received. make is GNU make 3.81 on both systems. Answering my own question - it appears that if a build has already been done in the source directory, this problem occurs. With a pristine source directory a VPATH build works as expected. Micki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Redefining {
I am curious if anyone knows of R code where the "{" function is
redefined in a useful way. Or "(" for that matter.
Thanks
Mick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] --interactive and -f/-e
I was surprised by this: R --interactive -e 'interactive()' bash-3.2$ R -q -e 'interactive()' --interactive > interactive() [1] FALSE > as the command options document says that --interactive should force interactive=TRUE: " When *R* is run in a terminal (via |Rterm.exe| on Windows), it assumes that it is interactive if ‘stdin’ is connected to a (pseudo-)terminal and not if ‘stdin’ is redirected to a file or pipe. Command-line options --interactive (Unix) and --ess (Windows, |Rterm.exe|) override the default assumption" But the code in system.c does this: R_Interactive = R_Interactive && (force_interactive || isatty(0)); R_Interactive is set to FALSE in the -e/-f processing, and force_interactive is set to TRUE in the --interactive processing, so there is no way that it can ever override -e/-f. It seems that --interactive can only have an effect for something like a pipe. Is this actually the expected behavior? Mick Jordan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] --interactive and -f/-e
On 4/29/15 3:20 AM, Martin Maechler wrote: Mick Jordan on Tue, 28 Apr 2015 18:11:54 -0700 writes: So, in principle it should not seem hard to make --interactive work for '-e' and '-f' as well, but I don't see quickly how. Just changing the line in unix/system.c you've mentioned above is clearly not enough. Martin Maechler ETH Zurich Thanks for the detailed assessment. When implementing a feature (I'm on the FastR project) I usually go by what the manual says, then check it against GnuR, and then if they don't match, read the source code. I'd be just as happy for the manual to be fixed rather than the code. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
