Re: [Bioc-devel] Recent error in FamAgg with R-3.4rc

[Rainer Johannes]

An update: the fixed gap package is now in CRAN 
(https://cran.r-project.org/web/packages/gap/index.html). Once the Windows 
build machine uses/installs this updated CRAN package, the error in FamAgg will 
be fixed.

cheers, jo

On 19 Apr 2017, at 13:04, Rainer Johannes 
> wrote:

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Thanks Lori for the info!

Actually, the maintainer of the gap package fixed the problem now in his 
package. Once the new version of gap is in CRAN (hopefully soon) the error in 
FamAgg will be gone too.

cheers, jo

On 19 Apr 2017, at 12:56, Shepherd, Lori 
>
 wrote:

You can continue to commit changes and bug corrections until this Friday 21.  
After that date any change will remain in devel and if necessary would have to 
be corrected in release after the release is finished.

Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263

From: Bioc-devel 
>
 on behalf of Rainer Johannes 
>
Sent: Wednesday, April 19, 2017 3:51:01 AM
To: bioc-devel
Subject: [Bioc-devel] Recent error in FamAgg with R-3.4rc

Dear all,

Somehow the FamAgg fails building with the recent R-3.4rc in Windows. I tracked 
down the error and it comes from a fortran code in a function from the "gap" 
CRAN package I'm using in one of the functions. I contacted the developer and 
in the meantime implemented a workaround in FamAgg.

My question now is if I can still submit changes to svn to fix this or is it 
already too late?

cheers, jo

___
Bioc-devel@r-project.org
 mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

This email message may contain legally privileged and/or confidential 
information. If you are not the intended recipient(s), or the employee or agent 
responsible for the delivery of this message to the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or use of this 
email message is prohibited. If you have received this message in error, please 
notify the sender immediately by e-mail and delete this email message from your 
computer. Thank you.


   [[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] system/system2 and open file descriptors

[Winston Chang]

In addition to the issue of a child process holding onto open files, the
child process can also manipulate a file descriptor in a way that affects
the parent process. For example, calling lseek() in the child process will
move the file offset in the parent process.

Here is a set of commands that demonstrates it. They can be copied and
pasted in a terminal. What it does:
- Creates C program that seeks to the beginning of a file descriptor, and
compiles it to a program named "lseek".
- Creates a file with some text in it.
- Starts R. In R:
- Opens the text file and reads the first line.
- Runs lseek in a child process.
- Reads the rest of the lines.


echo "#include 
int main(void) {
  lseek(3, 0, SEEK_SET);
}" > lseek.c

gcc lseek.c -o lseek

echo "line 1
line 2
line 3" > lines.txt

R
f <- file('lines.txt', 'r')
cat(readLines(f, n = 1), sep = "\n")
system('./lseek')
cat(readLines(f), sep = "\n")


Here's what it outputs:
> f <- file('lines.txt', 'r')
> cat(readLines(f, n = 1), sep = "\n")
line 1
> system('./lseek')
> cat(readLines(f), sep = "\n")
line 2
line 3
line 1
line 2
line 3

The child process has changed what the parent process reads from the file.
(I'm guessing that the reason readLines() prints out "line 2" and "line 3"
before starting over is because it has already buffered the whole file
before lseek is executed.)

This is obviously a highly contrived case, but it illustrates what's
possible. The other issue I mentioned, with child processes holding open
files after the R process exits, is more likely to cause problems in the
real world. That's actually how I encountered this issue in the first
place: when restarting R inside of RStudio on a Mac, if there are any
extant child processes started by system(), they keep some files open, and
this causes RStudio to hang. (There's a fix in progress for RStudio for
this particular issue.)

-Winston



On Tue, Apr 18, 2017 at 3:20 PM, Winston Chang 
wrote:

> It seems that the system() and system2() functions don't close file
> descriptors between the fork() and exec() (on Unix platforms, of course).
> This means that the child processes inherit open files and socket
> connections.
>
> Running this (from a terminal) will result in the child process writing to
> a file that was opened by R:
>
> R
> f <- file('foo.txt', 'w')
> system('echo "abc" >&3')
>
>
>
> You can also see the open files if you run the following:
>   f <- file('foo.txt', 'w')
>   system2('sleep', '100', wait=F)
>
> And then in another terminal:
>   lsof -c R -c sleep
> it will show that both the R and sleep processes have the file open:
>   ...
>   R   324 root3w   REG   0,480   4259 /foo.txt
>   ...
>   sleep   327 root3w   REG   0,480   4259 /foo.txt
>
>
> This behavior can cause problems if R spawns a child process that outlives
> the R process, but keeps open some resources.
>
> Would it be possible to add an option to close file descriptors for child
> processes? It would be nice if that were the default, but I suspect that
> making that change would break a lot of existing code.
>
> To take an example from the Python world, subprocess.Popen() has an
> option, close_fds, which closes all file descriptors except 0, 1, and 2.
>   https://docs.python.org/2/library/subprocess.html#popen-constructor
>
>
> -Winston
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Git mirror missing

[Martin Morgan]

On 04/19/2017 03:33 PM, Astrid Deschenes wrote:

Hi,


The Bioconductor Git mirror  
https://github.com/Bioconductor-mirror/methylInheritance returns a 404 error. 
Is this normal?



This has been corrected.

The mirror is useful as a way to cite or navigate code, but it's 
irrelevant to the package 'landing pages' at bioconductor.org/packages, 
the nightly builds, or the packages made available to users via biocLite().


Martin


Thanks,

Astrid





[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta

[Hervé Pagès]

On 04/19/2017 02:45 AM, Michael Stadler wrote:

Dear BioC core,

Thanks for the report, Herve. If I understand correctly, there is
nothing I can do at this point to make QuasR green on windows, correct?


Nothing you can do in QuasR itself. Sorry that I don't have time to do
this but someone would need to take a close look at this problem though.
And report his/her findings to the R folks. We're running short of time!
(will be a bummer to have R 3.4 released with such a nasty bug in it)

Cheers,
H.



I have another question regarding QuasR not building on veracruz2: The
vignette does not build currently, reporting:
Error on veracruz2.bioconductor.org processing sample
/tmp/RtmpJBWrjI/chip_1_1.fq.bz2df0b6901ff33.fastq : 'asBam' internal:
samtools invoked 'abort' ...

Though it seems to build fine on other platforms, and there were no
recent changes to the vignette. What would you or other suggest to do
about that?

Any suggestions are appreciated,
Michael



On 17.04.2017 02:08, Hervé Pagès wrote:

FWIW here are all the packages that are victim of this
installed.packages bug in today's build report:

  alpine
  fCI
  GenomicFeatures
  QuasR

We only see this error on tokay2 (Windows).

H.


On 04/11/2017 04:21 PM, Gordon K Smyth wrote:

I restarted my PC this morning and the problem disappeared.

I probably should have tried that last night, but it was late ...

Thanks
Gordon


-Original Message-
From: Martin Morgan [mailto:martin.mor...@roswellpark.org]
Sent: Tuesday, 11 April 2017 7:20 PM
To: Gordon K Smyth ; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta

On 04/11/2017 05:01 AM, Gordon K Smyth wrote:

The problem appears to be with installed.packages(). If I start a
fresh R

3.4.0beta session, then I can run installed.packages() once with
correct results,
but running it a second time gives the error message:



installed.packages()

Error in if (file.exists(dest) && file.mtime(dest) > file.mtime(lib)
&&  :
  missing value where TRUE/FALSE needed


The test is in this code chunk, from utils/R/packages.R

 for(lib in lib.loc) {
 if(noCache) {
 ret0 <- .readPkgDesc(lib, fields)
 if(length(ret0)) retval <- rbind(retval, ret0)
 } else {
 ## Previously used URLencode for e.g. Windows paths with
drives
 ## This version works for very long file names.
 base <- paste(c(lib, fields), collapse = ",")
 ## add length and 64-bit CRC in hex (in theory, seems
 ## it is actually 32-bit on some systems)
 enc <- sprintf("%d_%s", nchar(base), .Call(C_crc64, base))
 dest <- file.path(tempdir(), paste0("libloc_", enc,
".rds"))
 if(file.exists(dest) &&
file.mtime(dest) > file.mtime(lib) &&
(val <- readRDS(dest))$base == base)
 ## use the cache file
 retval <- rbind(retval, val$value)
 else {
 ret0 <- .readPkgDesc(lib, fields)
 if(length(ret0)) {
 retval <- rbind(retval, ret0)
 ## save the cache file
 saveRDS(list(base = base, value = ret0), dest)
 }
 }
 }


where 'lib' is one of .libPaths(), 'dest' is one of

   dir(tempdir(), pattern="libloc_", full=TRUE)

and 'base' should be a character(1)

I think the code chunk has tried to cache the packages installed in each
directory of .libPaths() (the saveRDS() line), and these are somehow
corrupted on the second time through (I guess evaluating the
readRDS()??).

For instance I have two paths in .libPaths() and after the first
install.packages() I have

 > str(readRDS(dir(tempdir(), full=TRUE)[1]))
List of 2
  $ base : chr
"/home/mtmorgan/bin/R-3-4-
branch/library,Version,Priority,Depends,Imports,LinkingTo,Suggests,Enhances,Li

cense,Li"|
__truncated__
  $ value: chr [1:29, 1:17] "base" "boot" "class" "cluster" ...
 > str(readRDS(dir(tempdir(), full=TRUE)[2]))
List of 2
  $ base : chr
"/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.4-Bioc-
3.5,Version,Priority,Depends,Imports,LinkingTo,Suggests,E"|
__truncated__
  $ value: chr [1:513, 1:17] "abind" "acepack" "aCGH" "ADaCGH2" ...

I'm guessing that one of these files is corrupted somehow, but it's not
obvious how. Can you use options(error=recover) and find the values that
cause the conditional to fail?

Martin





-Original Message-
From: Gordon K Smyth
Sent: Tuesday, 11 April 2017 6:26 PM
To: bioc-devel@r-project.org
Subject: Using BiocInstaller with R 3.4.0 beta

I thought I would test out R 3.4.0 beta (for Windows) but now I
can't use the
BiocInstaller package. Attempts to use biocLite() or biocValid()
lead to an

error

message as shown below.

What have I overlooked?

Thanks
Gordon


sessionInfo()

R version 3.4.0 beta (2017-04-08 r72499)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 

Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta

[Hervé Pagès]

Hi Michael,

On 04/17/2017 12:31 PM, Michael Love wrote:

alpine, which had this error as of Sunday, is now cleared (I didn't
make any changes to the code)

https://urldefense.proofpoint.com/v2/url?u=http-3A__master.bioconductor.org_checkResults_devel_bioc-2DLATEST_alpine_=DwIBaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FslFDEAm_2UTMu0mMv7oNRUhFjxa9R6r2QKfY7_-ZZ8=NeikP8-8_2PSFQMJ7jiSmXUW4SWzjK-XZXnXqRAf3_U=



The problem seems intermittent. All the packages that make direct
or indirect calls to installed.packages() are not necessarily
affected every day. Today the victims are:

  cobindR
  debrowser
  fCI
  GenomicFeatures
  GGBase
  QuasR

So more victims than 3 days ago. Tomorrow we might see something
different.

H.

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] c documentation after change

[Suharto Anggono Suharto Anggono via R-devel]

In R 3.4.0 RC, argument list of 'c' as S4 generic function has become
(x, ...) .
However, "S4 methods" section in documentation of 'c' (c.Rd) is not updated yet.

Also, in R 3.4.0 RC, 'c' method of class "Date" ('c.Date') is still not 
explicitly documented.

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

Re: [Bioc-devel] xps build problem on veracruz2

[Hervé Pagès]

Hi Christian,

So I installed ROOT 5 from source on veracruz2. It's in
/usr/local/root.

However, Apple's SIP (System Integrity Protection, new and
enabled by default on El Capitan) is getting in the way when
trying to install xps. That's because xps configure and build
process relies on DYLD_LIBRARY_PATH. Problem is that this
environment variable (and any other variables that control
dynamic loading) is not inherited by child processes when SIP
is on:

veracruz2:~ biocbuild$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!'; 
else echo 'nope!'; fi

yep!

veracruz2:~ biocbuild$ sh
sh-3.2$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!'; else echo 
'nope!'; fi

nope!

That breaks xps configure script:

veracruz2:~ biocbuild$ export LD_LIBRARY_PATH=$DYLD_LIBRARY_PATH

veracruz2:~ biocbuild$ echo $LD_LIBRARY_PATH
/usr/local/mysql/lib:/usr/local/root/lib/root:/ImageMagick-7.0.5/lib:/usr/local/ensembl-vep/htslib

veracruz2:~ biocbuild$ R CMD INSTALL xps
* installing to library 
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’

* installing *source* package ‘xps’ ...
checking for gcc... clang
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ANSI C... none needed
checking how to run the C preprocessor... clang -E
checking for gcc... (cached) clang
checking whether we are using the GNU C compiler... (cached) yes
checking whether clang accepts -g... (cached) yes
checking for clang option to accept ANSI C... (cached) none needed
found ROOT version 5.34/36 in directory /usr/local/root

xps configuration error:

   You must set the shell variable LD_LIBRARY_PATH to the
   directory where ROOT resides and re-run R CMD INSTALL
   e.g., (using Bourne shell syntax):

  export "LD_LIBRARY_PATH=$ROOTSYS/lib:$LD_LIBRARY_PATH"
  R CMD INSTALL xps

   Please consult the README file for more information

ERROR: configuration failed for package ‘xps’
* removing 
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/xps’
* restoring previous 
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/xps’


That also breaks the dynlib mechanism because, after I managed to
produce xps.so, it turns out that this shared object is linked to
the ROOT libraries via the @rpath mechanism:

veracruz2:src biocbuild$ otool -L xps.so
xps.so:
xps.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libGui.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libCint.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libNet.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHist.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libGraf.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libGraf3d.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libGpad.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libRint.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libPostscript.so (compatibility version 0.0.0, current version 
0.0.0)

@rpath/libMatrix.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libPhysics.so (compatibility version 0.0.0, current version 
0.0.0)
@rpath/libMathCore.so (compatibility version 0.0.0, current version 
0.0.0)
@rpath/libThread.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1226.10.1)

@rpath/libGed.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libTreePlayer.so (compatibility version 0.0.0, current version 
0.0.0)
	@rpath/libTreeViewer.so (compatibility version 0.0.0, current version 
0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.1.0)


so it can't be loaded in R:

> dyn.load("xps.so")
Error in dyn.load("xps.so") :
  unable to load shared object 
'/Users/biocbuild/bbs-3.5-bioc/xps/src/xps.so':
  dlopen(/Users/biocbuild/bbs-3.5-bioc/xps/src/xps.so, 6): Library not 
loaded: @rpath/libGui.so

  Referenced from: /Users/biocbuild/bbs-3.5-bioc/xps/src/xps.so
  Reason: image not found

because R has no access to DYLD_LIBRARY_PATH:

> Sys.getenv("DYLD_LIBRARY_PATH")
[1] ""

This can be addressed by adding the following flag when linking:

  -rpath $(shell $(ROOTCONFIG) --prefix)/lib

Do you think you can revisit xps configure and build process? Make sure
you test it on a machine 

Re: [R-pkg-devel] R CMD check not finding my vignettes

[Duncan Murdoch]

On 19/04/2017 1:00 PM, David Hugh-Jones wrote:

Hi Uwe,

I'm not sure if you ever got my off-list message with my tarball or
subsequent messages. I can't send a tarball on-list - it gets rejected as
too large - but here is a dropbox link. If you could confirm receipt, that
would be extremely helpful!

https://www.dropbox.com/s/179jrm19kx9o7dz/huxtable_0.2.0.tar.gz?dl=0



Not sure if Uwe has had a chance to look, but I just ran R CMD check on 
your tarball using the latest version of R-devel.  It reported the 
following problems:


* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘David Hugh-Jones ’

Found the following (possibly) invalid URLs:
  URL: http://cran.rstudio.com/web/packages/huxtable/index.html
From: README.md
CRAN URL not in canonical form
  Canonical CRAN.R-project.org URLs use https.

The URL for your package should be in the form

https://CRAN.R-project.org/package=huxtable

* checking top-level files ... NOTE
Non-standard file/directory found at top level:
  ‘multirow.rds’

I'm not sure where that file belongs, but not there.

* checking files in ‘vignettes’ ... WARNING
Files in the 'vignettes' directory newer than all files in 'inst/doc':
  ‘huxreg.html’, ‘huxtable.html’

Those files shouldn't be in the vignettes directory, they are products 
of building the vignettes.  Only the source should normally be in the 
vignettes directory.


* checking package vignettes in ‘inst/doc’ ... WARNING
Package vignettes without corresponding PDF/HTML:
   ‘design-principles.Rmd’
   ‘huxreg.Rmd’
   ‘huxtable.Rmd’

I think this is the warning you were asking about.  If I look at just 
the first of those files, I see that design-principles.Rmd exists in 
vignettes and is set to produce PDF output (only the first output entry 
in the YAML counts).  You also have a .html file in vignettes; it 
shouldn't be there.  In inst/doc, you have source, .html and .pdf 
versions of that file.


The warning isn't very helpful, but I think it is triggered by the fact 
that you've got the .html file in your vignettes directory.  If I remove 
everything but the source from that directory, and everything from the 
inst/doc directory, then all the vignette warnings go away.


(I haven't traced through the code, but I think the warning may be 
literally correct.  Since you had .html files that looked like vignette 
outputs but weren't, you have vignettes without *corresponding* HTML. 
It would have been nicer if it suggested how to fix this, but that 
vignette code is quite tricky, because any file could be source, and any 
html, tex or pdf file could be output.  At some point I may try to clean 
it up a bit and then maybe the error messages will be less obscure.)


Duncan Murdoch

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

Re: [Bioc-devel] R CMD check without WARNING: g++ and STL issue for xcms and mzR

[Hervé Pagès]

Thanks Steffen for bringing this to the R-devel list. I only
see the fix in trunk for now. They'll need to port it to the 3.4
branch if we want to see it propagate to our BioC 3.5 builds.

Just to clarify, by default R doesn't use the -Wall flag to
compile packages on Linux. It's something we add on our Linux
builders.

Cheers,
H.


On 04/19/2017 11:52 AM, Neumann, Steffen wrote:

Hi,

just a quick report, I followed this up to r-devel,
and a fix adding -O2 back to default CXXFLAGS
has been committed (r72549, see [1]) to R by Martyn Plummer,
thus "fixing" the abort() related WARNING in mzR/xcms
once this gets into the R version used on malbec2.

Yours,
Steffen

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.org_R-5Fsvnlog-5F2013=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=nRu69QAXHm0lBKf9Al-8KvSvfGAqLrzp1uWirvd6XF0=

On Mi, 2017-04-12 at 22:07 -0400, Martin Morgan wrote:

On 04/12/2017 11:31 AM, Neumann, Steffen wrote:


Hi,

certainly these are good suggestions, but I would tend
to simply add some whitelisting functionality if the
cause is beyond the package's control.

In this case I doubt it is a handler for SIGABRT,
since that would not go away with -O2, or would it ?

For now, just adding -O2 on Linux would fix this issue.

The code is compiled on the user machine, so twiddling with the
build
system masks the problem from the developer while leaving the user
vulnerable.

Calling abort() is certainly a serious problem, abruptly ending the
user
session.

Optimization could either eliminate a dead code path, or it could
compile the call to abort in a way that R no longer recognizes it --
R
is doing the equivalent of nm *.o |grep abort.

It would be appropriate to ignore the warning about abort() if it
were
never reached; one would only know this by careful code analysis
rather
than adjusting optimization flags.

Rsamtools re-defines abort (before including offending headers), and
avoids the warning (and crash), with the equivalent of

   PKG_CFLAGS=-D__builtin_abort=_samtools_abort

where _samtools_abort is my own implementation to signal an R error
telling the user that an unrecoverable error has occurred and they
should stop what they are doing. Unfortunately this requires
-U_FORTIFY_SOURCE and doesn't actually address the reason for the
abort,
and is hardly ideal.

I don't think the developer can set the optimization flag in a way
that
overrides the R or user setting (the PKG_CXXFLAGS is inserted before
the
R flags). And it doesn't address the underlying problem anyway.

Kasper's pragmatic approach (it's a very unlikely situation, and
difficult to fix, so live with the warning) seems like it would often
be
a reasonable one.

FWIW this little bit of C++ seems to be enough to include abort

tmp.cpp:
---
#include 

int foo(int argc, const char *argv[]) {
 std::list l1, l2;
 std::list::iterator it;

 it = l1.begin();
 l1.splice (it, l2); // mylist1: 1 10 20 30 2 3 4

 return 0;
}
---

Test with

   rm -f tmp.o && R CMD SHLIB tmp.cpp && nm tmp.o | grep abort

with compiler settings in

~/.R/Makevars
-
CXXFLAGS = -g -O0
-


Martin




Yours,
Steffen


On Mi, 2017-04-12 at 10:07 -0400, Vincent Carey wrote:



Suppose you had a handler for SIGABRT in your code.  Could CMD
check
check for that and, if found, refrain from warning?  That is
somewhat
involved and goes beyond Bioc but it seems a principled way of
dealing with operations in binary infrastructure whose behavior
we
cannot control.  The problem will surely arise in other settings.
Could BiocCheck prototype the approach?

On Wed, Apr 12, 2017 at 9:12 AM, Kasper Daniel Hansen
 wrote:



I think "we" have to appreciate that the warning about
abort/etc
and others
is really hard to deal with when you're including (large)
external
source
as you do in mzR and for example affxparser /
Rgraphviz.  Generally
fixing
those in external code requires a lot of effort, and the
further
effort to
document that the included sources in the package are different
from the
official sources.  I have had warnings about this in affxparser
for
a long,
long time and no-one has bothered me over it.

What might be nice is (somehow) setting a flag saying this
should
be
ignored in the check process, but of course we don't want that
flag
to be
set by the developer, because usually, these issues should be
dealt
with.
So perhaps there is nothing to do and I always have to click on
each build
report to verify that there is only 1 warning from this issues
and
not
others.

Best,
Kasper

On Wed, Apr 12, 2017 at 7:22 AM, Neumann, Steffen 
wrote:




Hi Martin and malbec2 admin(s):

Some more digging revealed that malbec2

[Bioc-devel] Bioconductor 3.5 release: potential deprecations

[Obenchain, Valerie]

Hi,

Due to errors / unresponsive maintainers this new group of packages has
been identified for potential deprecation in Biocondcutor 3.5.

anamiR
FunChiP
MutationalPatterns
seqplots
snm
ssviz
stepwiseCM
ToPASeq

If anyone is interested in taking over as maintainer please let us know.
If not fixed by Friday, April 21, these will be deprecated in 3.5.

Valerie



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R CMD check without WARNING: g++ and STL issue for xcms and mzR

[Neumann, Steffen]

Hi,

just a quick report, I followed this up to r-devel,
and a fix adding -O2 back to default CXXFLAGS 
has been committed (r72549, see [1]) to R by Martyn Plummer, 
thus "fixing" the abort() related WARNING in mzR/xcms 
once this gets into the R version used on malbec2.

Yours,
Steffen

[1] http://developer.r-project.org/R_svnlog_2013

On Mi, 2017-04-12 at 22:07 -0400, Martin Morgan wrote:
> On 04/12/2017 11:31 AM, Neumann, Steffen wrote:
> > 
> > Hi,
> > 
> > certainly these are good suggestions, but I would tend
> > to simply add some whitelisting functionality if the
> > cause is beyond the package's control.
> > 
> > In this case I doubt it is a handler for SIGABRT,
> > since that would not go away with -O2, or would it ?
> > 
> > For now, just adding -O2 on Linux would fix this issue.
> The code is compiled on the user machine, so twiddling with the
> build 
> system masks the problem from the developer while leaving the user 
> vulnerable.
> 
> Calling abort() is certainly a serious problem, abruptly ending the
> user 
> session.
> 
> Optimization could either eliminate a dead code path, or it could 
> compile the call to abort in a way that R no longer recognizes it --
> R 
> is doing the equivalent of nm *.o |grep abort.
> 
> It would be appropriate to ignore the warning about abort() if it
> were 
> never reached; one would only know this by careful code analysis
> rather 
> than adjusting optimization flags.
> 
> Rsamtools re-defines abort (before including offending headers), and 
> avoids the warning (and crash), with the equivalent of
> 
>    PKG_CFLAGS=-D__builtin_abort=_samtools_abort
> 
> where _samtools_abort is my own implementation to signal an R error 
> telling the user that an unrecoverable error has occurred and they 
> should stop what they are doing. Unfortunately this requires 
> -U_FORTIFY_SOURCE and doesn't actually address the reason for the
> abort, 
> and is hardly ideal.
> 
> I don't think the developer can set the optimization flag in a way
> that 
> overrides the R or user setting (the PKG_CXXFLAGS is inserted before
> the 
> R flags). And it doesn't address the underlying problem anyway.
> 
> Kasper's pragmatic approach (it's a very unlikely situation, and 
> difficult to fix, so live with the warning) seems like it would often
> be 
> a reasonable one.
> 
> FWIW this little bit of C++ seems to be enough to include abort
> 
> tmp.cpp:
> ---
> #include 
> 
> int foo(int argc, const char *argv[]) {
>  std::list l1, l2;
>  std::list::iterator it;
> 
>  it = l1.begin();
>  l1.splice (it, l2); // mylist1: 1 10 20 30 2 3 4
> 
>  return 0;
> }
> ---
> 
> Test with
> 
>    rm -f tmp.o && R CMD SHLIB tmp.cpp && nm tmp.o | grep abort
> 
> with compiler settings in
> 
> ~/.R/Makevars
> -
> CXXFLAGS = -g -O0
> -
> 
> 
> Martin
> 
> > 
> > 
> > Yours,
> > Steffen
> > 
> > 
> > On Mi, 2017-04-12 at 10:07 -0400, Vincent Carey wrote:
> > > 
> > > 
> > > Suppose you had a handler for SIGABRT in your code.  Could CMD
> > > check
> > > check for that and, if found, refrain from warning?  That is
> > > somewhat
> > > involved and goes beyond Bioc but it seems a principled way of
> > > dealing with operations in binary infrastructure whose behavior
> > > we
> > > cannot control.  The problem will surely arise in other settings.
> > > Could BiocCheck prototype the approach?
> > > 
> > > On Wed, Apr 12, 2017 at 9:12 AM, Kasper Daniel Hansen
> > >  > > n...@gmail.com> wrote:
> > > > 
> > > > 
> > > > I think "we" have to appreciate that the warning about
> > > > abort/etc
> > > > and others
> > > > is really hard to deal with when you're including (large)
> > > > external
> > > > source
> > > > as you do in mzR and for example affxparser /
> > > > Rgraphviz.  Generally
> > > > fixing
> > > > those in external code requires a lot of effort, and the
> > > > further
> > > > effort to
> > > > document that the included sources in the package are different
> > > > from the
> > > > official sources.  I have had warnings about this in affxparser
> > > > for
> > > > a long,
> > > > long time and no-one has bothered me over it.
> > > > 
> > > > What might be nice is (somehow) setting a flag saying this
> > > > should
> > > > be
> > > > ignored in the check process, but of course we don't want that
> > > > flag
> > > > to be
> > > > set by the developer, because usually, these issues should be
> > > > dealt
> > > > with.
> > > > So perhaps there is nothing to do and I always have to click on
> > > > each build
> > > > report to verify that there is only 1 warning from this issues
> > > > and
> > > > not
> > > > others.
> > > > 
> > > > Best,
> > > > Kasper
> > > > 
> > > > On Wed, Apr 12, 2017 at 7:22 AM, Neumann, Steffen  > > > -hal
> > > > le.de>
> > > > wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > Hi Martin and malbec2 admin(s):
> > > > > 
> > > > > Some more digging revealed that malbec2
> > > > > 

Re: [Rd] R 3.4 has broken C++11 support

[Ista Zahn]

Hi Philipp,

Fellow Archlinux user here. I think the problem is with the r-devel
PKGBUILD file, rather than anything wrong in R itself. The PKGBUILD
file does this:

ln -s /etc/R/${i} ${i}

when it should do

ln -s /etc/R-devel/${i} ${i}

You can fix your installed version with

cd /opt/r-devel/lib/R/etc/
sudo rm ./*
sudo ln -s /etc/R-devel/javaconf
sudo ln -s /etc/R-devel/ldpaths
sudo ln -s /etc/R-devel/Makeconf
sudo ln -s /etc/R-devel/Renviron
sudo ln -s /etc/R-devel/repositories

Or (better) fix the PKGBUILD and makepkg/pacman -U

Best,
Ista



On Wed, Apr 19, 2017 at 10:32 AM, Angerer, Philipp via R-devel
 wrote:
> Hi Dirk and Martyn,
>
>> That looks fine. Can you please give a reproducible example of a package
>> that compiles correctly on R 3.3.3 but not with R 3.4.0 or R-devel.
>
> here you go, it’s pretty much the simplest package possible that needs C++11:
>
> https://github.com/flying-sheep/cxx11test
>
>> Maybe you can share with us how you configure the build of R-devel?
>
> Sure, in the mail you quoted, I already linked exactly that:
>
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40
>
>> ./configure --prefix=/opt/r-devel \
>>   --libdir=/opt/r-devel/lib \
>>   --sysconfdir=/etc/R-devel \
>>   --datarootdir=/opt/r-devel/share \
>> rsharedir=/opt/r-devel/share/R/ \
>> rincludedir=/opt/r-devel/include/R/ \
>> rdocdir=/opt/r-devel/share/doc/R/ \
>>   --with-x \
>>   --enable-R-shlib \
>>   --with-lapack \
>>   --with-blas \
>>   F77=gfortran \
>>   LIBnn=lib
>
>
> Thanks and cheers,
> Philipp
>
>
> Helmholtz Zentrum Muenchen
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
> Ingolstaedter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
> Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons 
> Enhsen
> Registergericht: Amtsgericht Muenchen HRB 6466
> USt-IdNr: DE 129521671
>
> __
> 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: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Hi Uwe,

I'm not sure if you ever got my off-list message with my tarball or
subsequent messages. I can't send a tarball on-list - it gets rejected as
too large - but here is a dropbox link. If you could confirm receipt, that
would be extremely helpful!

https://www.dropbox.com/s/179jrm19kx9o7dz/huxtable_0.2.0.tar.gz?dl=0

Cheers,
David Hugh-Jones


On 7 April 2017 at 11:20, Uwe Ligges 
wrote:

> Can you send the tarball please, I can take a look,
>
>> Uwe
>
>>
>>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] as(vcf, "VRanges") is broken in devel, possibly caused by S4Vectors:::recycleVector()

[Robert Castelo]

hi,

got it, the current version on svn of VariantAnnotation (1.21.19) is 
ahead of what's available via biocLite(). i've checked out 
VariantAnnotation 1.21.19, installed it and the bug has dissapeared. 
problem solved.


thanks!

robert.

On 04/19/2017 05:39 PM, Michael Lawrence wrote:

Not reproducing for me. This is with S4Vectors, VariantAnnotation,
etc, from svn.

R Under development (unstable) (2016-12-13 r71785)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

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

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

other attached packages:
 [1] VariantAnnotation_1.21.19  Rsamtools_1.27.16
 [3] Biostrings_2.43.5  XVector_0.15.2
 [5] SummarizedExperiment_1.5.9 DelayedArray_0.1.11
 [7] matrixStats_0.51.0 Biobase_2.34.0
 [9] GenomicRanges_1.27.22  GenomeInfoDb_1.11.9
[11] IRanges_2.9.19 S4Vectors_0.13.15
[13] BiocGenerics_0.21.3

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.8  AnnotationDbi_1.36.0 GenomicAlignments_1.10.0
 [4] zlibbioc_1.20.0  BiocParallel_1.8.1   BSgenome_1.42.0
 [7] lattice_0.20-34  tools_3.4.0  grid_3.4.0
[10] DBI_0.5-1digest_0.6.10Matrix_1.2-7.1
[13] GenomeInfoDbData_0.99.0  rtracklayer_1.35.9   bitops_1.0-6
[16] biomaRt_2.30.0   RCurl_1.95-4.8   memoise_1.0.0
[19] RSQLite_1.1-1compiler_3.4.0   BiocInstaller_1.25.3
[22] GenomicFeatures_1.27.14  XML_3.98-1.5



On Wed, Apr 19, 2017 at 7:06 AM, Robert Castelo  wrote:

hi,

it seems that recent changes to S4Vectors are breaking the coercion from the
'*VCF' class to the 'VRanges' class. the traceback points to the private
function 'recycleVector() from the 'S4Vectors' package, please find below
the minimal example that reproduces the problem with the session
information.

cheers,

robert.

library(VariantAnnotation)
example(VRanges)
as(vcf, "VRanges")
Error in ans[] <- x : replacement has length zero
traceback()
4: S4Vectors:::recycleVector(ref, maxLen)
3: VRanges(seqnames, ranges, ref, alt, totalDepth, refDepth, altDepth,
   hardFilters = FilterRules(), sampleNames = sampleNames,
softFilterMatrix = filter,
   meta)
2: asMethod(object)
1: as(vcf, "VRanges")

sessionInfo()
R Under development (unstable) (2017-03-23 r72385)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS: /opt/R/R-devel/lib64/R/lib/libRblas.so
LAPACK: /opt/R/R-devel/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
 [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
 [7] LC_PAPER=en_US.UTF8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C

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

other attached packages:
 [1] VariantAnnotation_1.21.18  Rsamtools_1.27.16
 [3] Biostrings_2.43.8  XVector_0.15.2
 [5] SummarizedExperiment_1.5.9 DelayedArray_0.1.11
 [7] matrixStats_0.52.2 Biobase_2.35.1
 [9] GenomicRanges_1.27.23  GenomeInfoDb_1.11.10
[11] IRanges_2.9.19 S4Vectors_0.13.15
[13] BiocGenerics_0.21.3BiocInstaller_1.25.3
[15] setwidth_1.0-4 colorout_1.1-2

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.10  AnnotationDbi_1.37.4
 [3] GenomicAlignments_1.11.12 zlibbioc_1.21.0
 [5] BiocParallel_1.9.6BSgenome_1.43.7
 [7] lattice_0.20-35   tools_3.4.0
 [9] grid_3.4.0DBI_0.6-1
[11] digest_0.6.12 Matrix_1.2-9
[13] GenomeInfoDbData_0.99.0   rtracklayer_1.35.12
[15] bitops_1.0-6  biomaRt_2.31.10
[17] RCurl_1.95-4.8memoise_1.0.0
[19] RSQLite_1.1-2 compiler_3.4.0
[21] GenomicFeatures_1.27.14   XML_3.98-1.6





--
Robert Castelo, PhD
Associate Professor
Dept. of Experimental and Health Sciences
Universitat Pompeu Fabra (UPF)
Barcelona Biomedical Research Park (PRBB)
Dr Aiguader 88
E-08003 Barcelona, Spain
telf: +34.933.160.514
fax: +34.933.160.550

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] R 3.4 has broken C++11 support

[Dirk Eddelbuettel]

FWIW works for me too, with or without my ~/.R/Makevars

edd@max:~/git$ git clone https://github.com/flying-sheep/cxx11test
Cloning into 'cxx11test'...
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 13 (delta 0), reused 13 (delta 0), pack-reused 0
Unpacking objects: 100% (13/13), done.
Checking connectivity... done.
edd@max:~/git$ cd cxx11test/
edd@max:~/git/cxx11test(master)$ RD CMD INSTALL .
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘cxx11test’ ...
** libs
ccache g++ -std=gnu++11 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
-I"/usr/local/lib/R/site-library/Rcpp/include" -I/usr/local/include   -fpic
-ggdb -pipe -Wall -pedantic -c RcppExports.cpp -o RcppExports.o
ccache g++ -std=gnu++11 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
-I"/usr/local/lib/R/site-library/Rcpp/include" -I/usr/local/include   -fpic
-ggdb -pipe -Wall -pedantic -c test.cpp -o test.o
ccache g++ -std=gnu++11 -shared -L/usr/local/lib/R-devel/lib/R/lib
-L/usr/local/lib -o cxx11test.so RcppExports.o test.o
-L/usr/local/lib/R-devel/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/cxx11test/libs
** R
** preparing package for lazy loading
** help
No man pages found in package  ‘cxx11test’
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (cxx11test)
edd@max:~/git/cxx11test(master)$

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Bioc-devel] as(vcf, "VRanges") is broken in devel, possibly caused by S4Vectors:::recycleVector()

[Michael Lawrence]

Not reproducing for me. This is with S4Vectors, VariantAnnotation,
etc, from svn.

R Under development (unstable) (2016-12-13 r71785)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

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

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

other attached packages:
 [1] VariantAnnotation_1.21.19  Rsamtools_1.27.16
 [3] Biostrings_2.43.5  XVector_0.15.2
 [5] SummarizedExperiment_1.5.9 DelayedArray_0.1.11
 [7] matrixStats_0.51.0 Biobase_2.34.0
 [9] GenomicRanges_1.27.22  GenomeInfoDb_1.11.9
[11] IRanges_2.9.19 S4Vectors_0.13.15
[13] BiocGenerics_0.21.3

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.8  AnnotationDbi_1.36.0 GenomicAlignments_1.10.0
 [4] zlibbioc_1.20.0  BiocParallel_1.8.1   BSgenome_1.42.0
 [7] lattice_0.20-34  tools_3.4.0  grid_3.4.0
[10] DBI_0.5-1digest_0.6.10Matrix_1.2-7.1
[13] GenomeInfoDbData_0.99.0  rtracklayer_1.35.9   bitops_1.0-6
[16] biomaRt_2.30.0   RCurl_1.95-4.8   memoise_1.0.0
[19] RSQLite_1.1-1compiler_3.4.0   BiocInstaller_1.25.3
[22] GenomicFeatures_1.27.14  XML_3.98-1.5



On Wed, Apr 19, 2017 at 7:06 AM, Robert Castelo  wrote:
> hi,
>
> it seems that recent changes to S4Vectors are breaking the coercion from the
> '*VCF' class to the 'VRanges' class. the traceback points to the private
> function 'recycleVector() from the 'S4Vectors' package, please find below
> the minimal example that reproduces the problem with the session
> information.
>
> cheers,
>
> robert.
>
> library(VariantAnnotation)
> example(VRanges)
> as(vcf, "VRanges")
> Error in ans[] <- x : replacement has length zero
> traceback()
> 4: S4Vectors:::recycleVector(ref, maxLen)
> 3: VRanges(seqnames, ranges, ref, alt, totalDepth, refDepth, altDepth,
>hardFilters = FilterRules(), sampleNames = sampleNames,
> softFilterMatrix = filter,
>meta)
> 2: asMethod(object)
> 1: as(vcf, "VRanges")
>
> sessionInfo()
> R Under development (unstable) (2017-03-23 r72385)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: CentOS Linux 7 (Core)
>
> Matrix products: default
> BLAS: /opt/R/R-devel/lib64/R/lib/libRblas.so
> LAPACK: /opt/R/R-devel/lib64/R/lib/libRlapack.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
>  [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
>  [7] LC_PAPER=en_US.UTF8   LC_NAME=C
>  [9] LC_ADDRESS=C  LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices
> [6] utils datasets  methods   base
>
> other attached packages:
>  [1] VariantAnnotation_1.21.18  Rsamtools_1.27.16
>  [3] Biostrings_2.43.8  XVector_0.15.2
>  [5] SummarizedExperiment_1.5.9 DelayedArray_0.1.11
>  [7] matrixStats_0.52.2 Biobase_2.35.1
>  [9] GenomicRanges_1.27.23  GenomeInfoDb_1.11.10
> [11] IRanges_2.9.19 S4Vectors_0.13.15
> [13] BiocGenerics_0.21.3BiocInstaller_1.25.3
> [15] setwidth_1.0-4 colorout_1.1-2
>
> loaded via a namespace (and not attached):
>  [1] Rcpp_0.12.10  AnnotationDbi_1.37.4
>  [3] GenomicAlignments_1.11.12 zlibbioc_1.21.0
>  [5] BiocParallel_1.9.6BSgenome_1.43.7
>  [7] lattice_0.20-35   tools_3.4.0
>  [9] grid_3.4.0DBI_0.6-1
> [11] digest_0.6.12 Matrix_1.2-9
> [13] GenomeInfoDbData_0.99.0   rtracklayer_1.35.12
> [15] bitops_1.0-6  biomaRt_2.31.10
> [17] RCurl_1.95-4.8memoise_1.0.0
> [19] RSQLite_1.1-2 compiler_3.4.0
> [21] GenomicFeatures_1.27.14   XML_3.98-1.6
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] R 3.4 has broken C++11 support

[Martyn Plummer]

On Wed, 2017-04-19 at 16:32 +0200, Angerer, Philipp wrote:
> Hi Dirk and Martyn,
> 
> > That looks fine. Can you please give a reproducible example of a
> > package
> > that compiles correctly on R 3.3.3 but not with R 3.4.0 or R-devel.
> 
> here you go, it’s pretty much the simplest package possible that
> needs C++11:
> 
> https://github.com/flying-sheep/cxx11test

This works for me (See below). Make sure you are not overwriting some
key variables in a personal Makevars file or a site-wide Makevars.site
file.

[plummerm@D-160182 temp]$ ~/R-devel/r-devel/build/bin/R CMD INSTALL 
cxx11test_1.0.tar.gz 
* installing to library ‘/home/plummerm/R-devel/r-devel/build/library’
* installing *source* package ‘cxx11test’ ...
** libs
g++ -std=gnu++11 -I/home/plummerm/R-devel/r-devel/build/include -DNDEBUG  
-I"/home/plummerm/R-devel/r-devel/build/library/Rcpp/include" 
-I/usr/local/include   -fpic  -g -O2 -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++11 -I/home/plummerm/R-devel/r-devel/build/include -DNDEBUG  
-I"/home/plummerm/R-devel/r-devel/build/library/Rcpp/include" 
-I/usr/local/include   -fpic  -g -O2 -c test.cpp -o test.o
g++ -std=gnu++11 -shared -L/usr/local/lib64 -o cxx11test.so RcppExports.o test.o
installing to /home/plummerm/R-devel/r-devel/build/library/cxx11test/libs
** R
** preparing package for lazy loading
** help
No man pages found in package  ‘cxx11test’ 
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (cxx11test)

Martyn

> > Maybe you can share with us how you configure the build of R-devel?
> 
> Sure, in the mail you quoted, I already linked exactly that:
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40
> 
> > ./configure --prefix=/opt/r-devel \
> > --libdir=/opt/r-devel/lib \
> > --sysconfdir=/etc/R-devel \
> > --datarootdir=/opt/r-devel/share \
> >   rsharedir=/opt/r-devel/share/R/ \
> >   rincludedir=/opt/r-devel/include/R/ \
> >   rdocdir=/opt/r-devel/share/doc/R/ \
> > --with-x \
> > --enable-R-shlib \
> > --with-lapack \
> > --with-blas \
> > F77=gfortran \
> > LIBnn=lib
> 
> 
> Thanks and cheers,
> Philipp
>  
> 
> Helmholtz Zentrum Muenchen
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
> Ingolstaedter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
> Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr.
> Alfons Enhsen
> Registergericht: Amtsgericht Muenchen HRB 6466
> USt-IdNr: DE 129521671
> 
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R 3.4 has broken C++11 support

[Angerer, Philipp via R-devel]

Hi Dirk and Martyn,

> That looks fine. Can you please give a reproducible example of a package
> that compiles correctly on R 3.3.3 but not with R 3.4.0 or R-devel.

here you go, it’s pretty much the simplest package possible that needs C++11:

https://github.com/flying-sheep/cxx11test

> Maybe you can share with us how you configure the build of R-devel?

Sure, in the mail you quoted, I already linked exactly that:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40

> ./configure --prefix=/opt/r-devel \
>   --libdir=/opt/r-devel/lib \
>   --sysconfdir=/etc/R-devel \
>   --datarootdir=/opt/r-devel/share \
> rsharedir=/opt/r-devel/share/R/ \
> rincludedir=/opt/r-devel/include/R/ \
> rdocdir=/opt/r-devel/share/doc/R/ \
>   --with-x \
>   --enable-R-shlib \
>   --with-lapack \
>   --with-blas \
>   F77=gfortran \
>   LIBnn=lib


Thanks and cheers,
Philipp
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

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

Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta

[Michael Stadler]

Dear Martin,

Thank you for the quick response - you are right to suspect bowtie, it
seems that version 1.1.1 which I am using in Rbowtie has an issue on
newer macOS versions, and I am currently looking into wether an update
to version 1.2 would fix this.

A first issue that I stumbled into is that R CMD check now warns about
the bowtie code using C++11 extensions. Following the manual, I have
added the following to DESCRIPTION:
  SystemRequirements: GNU make, C++11
("GNU make" was already there), but the field seems to be ignored by R
CMD check and the warning persists. Is this something to worry about?

I hope to get back with a solution for the bowtie issue soon.
Michael



On 19.04.2017 13:47, Martin Morgan wrote:
> On 04/19/2017 05:45 AM, Michael Stadler wrote:
>> Dear BioC core,
>>
>> Thanks for the report, Herve. If I understand correctly, there is
>> nothing I can do at this point to make QuasR green on windows, correct?
>>
>> I have another question regarding QuasR not building on veracruz2: The
>> vignette does not build currently, reporting:
>> Error on veracruz2.bioconductor.org processing sample
>> /tmp/RtmpJBWrjI/chip_1_1.fq.bz2df0b6901ff33.fastq : 'asBam' internal:
>> samtools invoked 'abort' ...
>>
>> Though it seems to build fine on other platforms, and there were no
>> recent changes to the vignette. What would you or other suggest to do
>> about that?
> 
> The error is in createGenomicAlignmentsController after
> 
> https://github.com/Bioconductor-mirror/QuasR/blob/cc374678033055f2bd4d105c502a426807223c1c/R/createAlignments-functions.R#L292
> 
> 
> it looks like the sam file is quite funky
> 
> Browse[4]> options(nwarnings=1)
> Browse[4]> xx = readLines(samFile)
> There were 2339 warnings (use warnings() to see them)
> Browse[4]> head(warnings(), 3)
> Warning messages:
> 1: In readLines(samFile) : line 7 appears to contain an embedded nul
> 2: In readLines(samFile) : line 8 appears to contain an embedded nul
> 3: In readLines(samFile) : line 9 appears to contain an embedded nul
> Browse[4]> table(nzchar(xx))
> 
> FALSE  TRUE
>  2341   261
> Browse[4]> substring(head(xx, 10), 1, 70)
>  [1] "@HD\tVN:1.0\tSO:unsorted"
>  [2] "@SQ\tSN:chr1\tLN:4"
>  [3] "@SQ\tSN:chr2\tLN:1"
>  [4] "@SQ\tSN:chr3\tLN:45000"
> [5]
> "@PG\tID:Bowtie\tVN:1.1.1\tCL:\"/Library/Frameworks/R.framework/Versions/3."
> 
>  [6] ""
>  [7] ""
>  [8] ""
>  [9] ""
> [10] ""
> 
> The 'abort' from Rsamtools is
> 
>   Parse error at line 143: missing colon in auxiliary data
> 
> It's not really clear whether R is being confused by the embedded nulls
> or blank lines or other problem
> 
> Browse[4]> xx[140 + 1:5]
> [1] "" "" "" "" ""
> Browse[4]> xx[nzhchar(xx)][140 + 1:5]
> Error in nzhchar(xx) : could not find function "nzhchar"
> Browse[4]> xx[nzchar(xx)][140 + 1:5]
> [1]
> "seq10137\t4\t*\t0\t0\t*\t*\t0\t0\tTCGTTATGGTTTCCGTTGCTGCCATCTCACAT\tB@BABCBBBABABA?A>8>A7:6=@>>:@BAA>1;B\tXM:i:0"
> 
> [2]
> "seq10138\t4\t*\t0\t0\t*\t*\t0\t0\tCTGGCGACTCCTTCGAGATGGACGCCGTTGGCGCTC\tABBB@CBBBA9BB@>'>9@AA=A?\tXM:i:0"
> 
> [3]
> "seq10139\t4\t*\t0\t0\t*\t*\t0\t0\tCAAGCAACAGCAGGTTTCCGAGATTATGCGCCAAAT\tBBCBBC=A@BAABBABBA=A??><\tXM:i:0"
> 
> [4]
> "seq10140\t4\t*\t0\t0\t*\t*\t0\t0\tGGTTGTCAGCGTCATAAGAGGACCTCCAAATG\t;;;AA=AA>=CCBB>9@@>B=BB=\tXM:i:0"
> 
> [5]
> "seq10141\t4\t*\t0\t0\t*\t*\t0\t0\tAACCCTAATGAGCTTAATCAAGATGATGCTCGTTAT\tBBAB@AAB@BBBA@B@ABAABBABAA@B?A?@\tXM:i:0"
> 
> 
> So I guess it's in creation of the sam file -- Bowtie?
> 
> Martin
> 
>>
>> Any suggestions are appreciated,
>> Michael
>>
>>
>>
>> On 17.04.2017 02:08, Hervé Pagès wrote:
>>> FWIW here are all the packages that are victim of this
>>> installed.packages bug in today's build report:
>>>
>>>   alpine
>>>   fCI
>>>   GenomicFeatures
>>>   QuasR
>>>
>>> We only see this error on tokay2 (Windows).
>>>
>>> H.
>>>
>>>
>>> On 04/11/2017 04:21 PM, Gordon K Smyth wrote:
 I restarted my PC this morning and the problem disappeared.

 I probably should have tried that last night, but it was late ...

 Thanks
 Gordon

> -Original Message-
> From: Martin Morgan [mailto:martin.mor...@roswellpark.org]
> Sent: Tuesday, 11 April 2017 7:20 PM
> To: Gordon K Smyth ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta
>
> On 04/11/2017 05:01 AM, Gordon K Smyth wrote:
>> The problem appears to be with installed.packages(). If I start a
>> fresh R
> 3.4.0beta session, then I can run installed.packages() once with
> correct results,
> but running it a second time gives the error message:
>>
>>> installed.packages()
>> Error in if (file.exists(dest) && file.mtime(dest) > file.mtime(lib)
>> &&  :
>>   missing value where TRUE/FALSE needed
>
> The test is in this code chunk, from utils/R/packages.R
>
>  for(lib in lib.loc) {
>  if(noCache) {

[Bioc-devel] as(vcf, "VRanges") is broken in devel, possibly caused by S4Vectors:::recycleVector()

[Robert Castelo]

hi,

it seems that recent changes to S4Vectors are breaking the coercion from 
the '*VCF' class to the 'VRanges' class. the traceback points to the 
private function 'recycleVector() from the 'S4Vectors' package, please 
find below the minimal example that reproduces the problem with the 
session information.


cheers,

robert.

library(VariantAnnotation)
example(VRanges)
as(vcf, "VRanges")
Error in ans[] <- x : replacement has length zero
traceback()
4: S4Vectors:::recycleVector(ref, maxLen)
3: VRanges(seqnames, ranges, ref, alt, totalDepth, refDepth, altDepth,
   hardFilters = FilterRules(), sampleNames = sampleNames, 
softFilterMatrix = filter,

   meta)
2: asMethod(object)
1: as(vcf, "VRanges")

sessionInfo()
R Under development (unstable) (2017-03-23 r72385)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS: /opt/R/R-devel/lib64/R/lib/libRblas.so
LAPACK: /opt/R/R-devel/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
 [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
 [7] LC_PAPER=en_US.UTF8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C

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

other attached packages:
 [1] VariantAnnotation_1.21.18  Rsamtools_1.27.16
 [3] Biostrings_2.43.8  XVector_0.15.2
 [5] SummarizedExperiment_1.5.9 DelayedArray_0.1.11
 [7] matrixStats_0.52.2 Biobase_2.35.1
 [9] GenomicRanges_1.27.23  GenomeInfoDb_1.11.10
[11] IRanges_2.9.19 S4Vectors_0.13.15
[13] BiocGenerics_0.21.3BiocInstaller_1.25.3
[15] setwidth_1.0-4 colorout_1.1-2

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.10  AnnotationDbi_1.37.4
 [3] GenomicAlignments_1.11.12 zlibbioc_1.21.0
 [5] BiocParallel_1.9.6BSgenome_1.43.7
 [7] lattice_0.20-35   tools_3.4.0
 [9] grid_3.4.0DBI_0.6-1
[11] digest_0.6.12 Matrix_1.2-9
[13] GenomeInfoDbData_0.99.0   rtracklayer_1.35.12
[15] bitops_1.0-6  biomaRt_2.31.10
[17] RCurl_1.95-4.8memoise_1.0.0
[19] RSQLite_1.1-2 compiler_3.4.0
[21] GenomicFeatures_1.27.14   XML_3.98-1.6

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

[Tomas Kalibera]

We're working on a workaround for the JVM issue, it should be available 
in rJava soon.
(the JVM issue is only on Linux and it turns infinite/deep recursion 
into a crash of R; it also effectively reduces the R stack size)


Best
Tomas

On 04/19/2017 02:56 PM, Michael Lawrence wrote:

I think this is a known issue with Java messing with the stack, see
e.g. 
http://r.789695.n4.nabble.com/Error-memory-exhausted-limit-reached-td4729708.html.

I'll fix the infinite recursion caused by the methods package.

Michael

On Wed, Apr 19, 2017 at 1:12 AM, Wolfgang Huber  wrote:

Dear Hilmar

Perhaps this gives an indication of why the infinite recursion happens:

## after calling `*` on ma and a matrix:


showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE)


Function: * (package base)
e1="FOOCLASS", e2="matrix"
 (inherited from: e1="vector", e2="structure")
 (definition from function "Ops")
function (e1, e2)
{
 value <- callGeneric(e1, e2@.Data)
 if (length(value) == length(e2)) {
 e2@.Data <- value
 e2
 }
 else value
}




is(ma, "vector")

[1] TRUE

I got that in a fresh session of

sessionInfo()

R Under development (unstable) (2017-04-18 r72542)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4

Best wishes
Wolfgang

19.4.17 10:01, Hilmar Berger scripsit:

Hi,

following up on my own question, I found smaller example that does not
require LIMMA:

setClass("FOOCLASS",
  representation("list")
)
ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))


ma * ma$M

Error: C stack usage  7970512 is too close to the limit


library(xlsx)

Loading required package: rJava
Loading required package: xlsxjars

ma * ma$M

---> Crash

xlsx seems to act like a catalyst here, with the product operator
running in a deep nested iteration, exhausting the stack. Valgrind shows
thousands of invalid stack accesses when loading xslx, which might
contribute to the problem. Package xlsx has not been updated since 2014,
so it might fail with more current versions of R or Java (I'm using
Oracle Java 8).

Still, even if xlsx was the package to be blamed for the crash, I fail
to understand what exactly the product operator is trying to do in the
multiplication of the matrix with the object.

Best regards,
Hilmar

On 18/04/17 18:57, Hilmar Berger wrote:

Hi,

this is a problem that occurs in the presence of two libraries (limma,
xlsx) and leads to a crash of R. The problematic code is the wrong
application of sweep or the product ("*") function on an LIMMA MAList
object. To my knowledge, limma does not define a "*" method for MAList
objects.

If only LIMMA is loaded but not package xlsx, the code does not crash
but rather produces an error ("Error: C stack usage  7970512 is too
close to the limit"). Loading only package rJava instead of xlsx does
also not produce the crash but the error message instead. Note that
xlsx functions are not explicitly used.

It could be reproduced on two different Linux machines running
R-3.2.5, R-3.3.0 and R-3.3.2.

Code to reproduce the problem:
-
library(limma)
library(xlsx)

# a MAList
ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
M=matrix(rnorm(300), 30,10)))

# This should actually be sweep(ma$M, ...) for functional code, but I
omitted the $M...
#sweep(ma, 2, c(1:10), "*")
# sweep will crash when doing the final operation of applying the
function over the input matrix, which in this case is function "*"

f = match.fun("*")
# This is not exactly the same as in sweep but it also tries to
multiply the MAList object with a matrix of same size and leads to the
crash
f(ma, ma$M)
# ma * ma$M has the same effect
-

My output:

R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

   Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


library(limma)
library(xlsx)

Loading required package: rJava
Loading required package: xlsxjars

sessionInfo()

R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

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

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

[Michael Lawrence]

I think this is a known issue with Java messing with the stack, see
e.g. 
http://r.789695.n4.nabble.com/Error-memory-exhausted-limit-reached-td4729708.html.

I'll fix the infinite recursion caused by the methods package.

Michael

On Wed, Apr 19, 2017 at 1:12 AM, Wolfgang Huber  wrote:
> Dear Hilmar
>
> Perhaps this gives an indication of why the infinite recursion happens:
>
> ## after calling `*` on ma and a matrix:
>
>> showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE)
>
>
> Function: * (package base)
> e1="FOOCLASS", e2="matrix"
> (inherited from: e1="vector", e2="structure")
> (definition from function "Ops")
> function (e1, e2)
> {
> value <- callGeneric(e1, e2@.Data)
> if (length(value) == length(e2)) {
> e2@.Data <- value
> e2
> }
> else value
> }
>
>
>
>> is(ma, "vector")
>
> [1] TRUE
>
> I got that in a fresh session of
>>
>> sessionInfo()
>
> R Under development (unstable) (2017-04-18 r72542)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Best wishes
> Wolfgang
>
> 19.4.17 10:01, Hilmar Berger scripsit:
>>
>> Hi,
>>
>> following up on my own question, I found smaller example that does not
>> require LIMMA:
>>
>> setClass("FOOCLASS",
>>  representation("list")
>> )
>> ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))
>>
>>> ma * ma$M
>>
>> Error: C stack usage  7970512 is too close to the limit
>>
>>> library(xlsx)
>>
>> Loading required package: rJava
>> Loading required package: xlsxjars
>>>
>>> ma * ma$M
>>
>> ---> Crash
>>
>> xlsx seems to act like a catalyst here, with the product operator
>> running in a deep nested iteration, exhausting the stack. Valgrind shows
>> thousands of invalid stack accesses when loading xslx, which might
>> contribute to the problem. Package xlsx has not been updated since 2014,
>> so it might fail with more current versions of R or Java (I'm using
>> Oracle Java 8).
>>
>> Still, even if xlsx was the package to be blamed for the crash, I fail
>> to understand what exactly the product operator is trying to do in the
>> multiplication of the matrix with the object.
>>
>> Best regards,
>> Hilmar
>>
>> On 18/04/17 18:57, Hilmar Berger wrote:
>>>
>>> Hi,
>>>
>>> this is a problem that occurs in the presence of two libraries (limma,
>>> xlsx) and leads to a crash of R. The problematic code is the wrong
>>> application of sweep or the product ("*") function on an LIMMA MAList
>>> object. To my knowledge, limma does not define a "*" method for MAList
>>> objects.
>>>
>>> If only LIMMA is loaded but not package xlsx, the code does not crash
>>> but rather produces an error ("Error: C stack usage  7970512 is too
>>> close to the limit"). Loading only package rJava instead of xlsx does
>>> also not produce the crash but the error message instead. Note that
>>> xlsx functions are not explicitly used.
>>>
>>> It could be reproduced on two different Linux machines running
>>> R-3.2.5, R-3.3.0 and R-3.3.2.
>>>
>>> Code to reproduce the problem:
>>> -
>>> library(limma)
>>> library(xlsx)
>>>
>>> # a MAList
>>> ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
>>> M=matrix(rnorm(300), 30,10)))
>>>
>>> # This should actually be sweep(ma$M, ...) for functional code, but I
>>> omitted the $M...
>>> #sweep(ma, 2, c(1:10), "*")
>>> # sweep will crash when doing the final operation of applying the
>>> function over the input matrix, which in this case is function "*"
>>>
>>> f = match.fun("*")
>>> # This is not exactly the same as in sweep but it also tries to
>>> multiply the MAList object with a matrix of same size and leads to the
>>> crash
>>> f(ma, ma$M)
>>> # ma * ma$M has the same effect
>>> -
>>>
>>> My output:
>>>
>>> R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
>>> Copyright (C) 2016 The R Foundation for Statistical Computing
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>>
>>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>>> You are welcome to redistribute it under certain conditions.
>>> Type 'license()' or 'licence()' for distribution details.
>>>
>>>   Natural language support but running in an English locale
>>>
>>> R is a collaborative project with many contributors.
>>> Type 'contributors()' for more information and
>>> 'citation()' on how to cite R or R packages in publications.
>>>
>>> Type 'demo()' for some demos, 'help()' for on-line help, or
>>> 'help.start()' for an HTML browser interface to help.
>>> Type 'q()' to quit R.
>>>
>>> > library(limma)
>>> > library(xlsx)
>>> Loading required package: rJava
>>> Loading required package: xlsxjars
>>> >
>>> > sessionInfo()
>>> R version 3.3.0 (2016-05-03)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Ubuntu 14.04.5 LTS
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=en_US.UTF-8
>>>  [4] LC_COLLATE=en_US.UTF-8LC_MONETARY=en_US.UTF-8
>>> 

Re: [Rd] R 3.4 has broken C++11 support

[Angerer, Philipp via R-devel]

Hmm, doesn’t look like my R was configured incorrectly:



R is now configured for x86_64-pc-linux-gnu

  Source directory:  .
  Installation directory:/opt/r-devel

  C compiler:gcc  -march=x86-64 -mtune=generic -O2 -pipe 
-fstack-protector-strong --param=ssp-buffer-size=4
  Fortran 77 compiler:   gfortran  -g -O2

  Default C++ compiler:  g++   -march=x86-64 -mtune=generic -O2 -pipe 
-fstack-protector-strong --param=ssp-buffer-size=4
  C++98 compiler:g++ -std=gnu++98 -march=x86-64 -mtune=generic -O2 
-pipe -fstack-protector-strong --param=ssp-buffer-size=4
  C++11 compiler:g++ -std=gnu++11 -march=x86-64 -mtune=generic -O2 
-pipe -fstack-protector-strong --param=ssp-buffer-size=4
  C++14 compiler:g++  -march=x86-64 -mtune=generic -O2 -pipe 
-fstack-protector-strong --param=ssp-buffer-size=4
  C++17 compiler:  
  Fortran 90/95 compiler:gfortran -g -O2
  Obj-C compiler: 

  Interfaces supported:  X11, tcltk
  External libraries:readline, BLAS(generic), LAPACK(generic), curl
  Additional capabilities:   PNG, JPEG, TIFF, NLS, cairo, ICU
  Options enabled:   shared R library, R profiling

  Capabilities skipped:  
  Options not enabled:   shared BLAS, memory profiling

  Recommended packages:  yes

- Ursprüngliche Mail -
Von: "Angerer, Philipp" 
An: "Martyn Plummer" 
CC: "r-devel" 
Gesendet: Mittwoch, 19. April 2017 12:42:33
Betreff: Re: [Rd] R 3.4 has broken C++11 support

Hi! 

Well, my linux distribution has very recent versions 
of everything, so a working C++11 compiler exists: 

$ gcc --version | head -n1 
gcc (GCC) 6.3.1 20170306 

Could wrong ./configure options be at fault here? See: 

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40 

My sessionInfo(): 

$ R-devel --slave -e 'sessionInfo()' | head -n3 
R Under development (unstable) (2017-04-18 r72542) 
Platform: x86_64-pc-linux-gnu (64-bit) 
Running under: Arch Linux 

Thanks, Philipp 

 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

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

[Rd] Default R-3.4.0 RC CXXFLAGS without -O2 on x86_64-linux-gnu with g++-5.4.0 causes WARNING from stl_list.h

[Neumann, Steffen]

Hi r-devel,

a recent install of R-3.4.0 RC (2017-04-13 r72510) 
on Linux (Ubuntu 16.04.1 LTS) x86_64-linux-gnu 
with g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
(see 
http://bioconductor.org/checkResults/devel/bioc-LATEST/malbec2-NodeInfo.html 
for more) 
results in CXXFLAGS not containing "-O2" as optimisation flag,
there is only " -Wall", while CFLAGS are happy with "-g -O2
-Wall"

This has an influence in at least one place
https://stat.ethz.ch/pipermail/bioc-devel/2017-April/010733.html
where we have WARNINGS in R CMD check from "Found ‘abort’, 
possibly from ‘abort’ (C)" in packages xcms/mzR.
The abort() call is not coming from XCMS, but rather 
from the C++ code in the STL:

[...]
# 1770 "/usr/include/c++/5/bits/stl_list.h"
void _M_check_equal_allocators(list& __x) {
 if (_M_get_Node_allocator())
   __builtin_abort();
}

If we compile with -O2 optimisation, this getting rid of 
the abort() symbol, as shown 
in https://github.com/sneumann/xcms/issues/150#issuecomment-293545521

Martin Morgan created a minimum example that shows that 
the symbol is indeed deep down in the STL (see below and in:
https://stat.ethz.ch/pipermail/bioc-devel/2017-April/010837.html )

This raises several questions:

1) is there any way to avoid the WARNING / abort() inside 
   the STL list implementation ? Or just live with it ?

2) If not, is there a reason why the Bioconductor build farm 
   Ubuntu machine is not using -O2 as default CXXFLAG ?
   BioC admins are trying to have a vanilla R installation with defaults. 
   According to Herve Pages, CXXFLAGS without -O2 is default 
   since R-3.4 beta, but I don't know enough about the package 
   build logic to point to a particular R commit. 

3) I thought about cheating the system and add -O2 
   in the package CXXFLAGS, but Martin Morgan 
   recommends packages shouldn't mess and override system build defaults
   to mask and paper over the actual issue having a nasty abort() 
   lurking somewhere.
   But I couldn't add PKG_CXXFLAGS=-O2 in first place, since that 
   triggers the different WARNING that -O2 is not portable. 

=> Any help and input would be highly appreciated. 

Thanks in advance, 
yours,
Steffen


tmp.cpp by Martin Morgan (also in above linked mail thread)
---
#include 

int foo(int argc, const char *argv[]) {
 std::list l1, l2;
 std::list::iterator it;

 it = l1.begin();
 l1.splice (it, l2); // mylist1: 1 10 20 30 2 3 4

 return 0;
}
---

Test with

   rm -f tmp.o && R CMD SHLIB tmp.cpp && nm tmp.o | grep abort

with compiler settings in ~/.R/Makevars with/without -O2 
-
CXXFLAGS = -g -O0
-





--
IPB HalleAG Massenspektrometrie &
Bioinformatik
Dr. Steffen Neumann  http://www.IPB-Halle.DE
Weinberg 3                   Tel. +49 (0) 345 5582 - 1470
06120 Halle                       +49 (0) 345 5582 - 0           
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409

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

[Rd] ask.yes.no() function

[Duncan Murdoch]

As described in 
, R base 
functions are currently inconsistent in asking interactive "yes/no" type 
questions.  One solution to this is to have a function to do it, and to 
use it consistently.


Rather than just writing such a function and possibly missing some 
desirable feature, I'd like to ask if anyone can point to an existing 
one that is perfect (or nearly perfect, and point out what changes would 
be desirable)?


Duncan Murdoch

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

Re: [Rd] R 3.4 has broken C++11 support

[Dirk Eddelbuettel]

On 19 April 2017 at 12:42, Angerer, Philipp via R-devel wrote:
| Well, my linux distribution has very recent versions
| of everything, so a working C++11 compiler exists:
| 
| $ gcc --version | head -n1
| gcc (GCC) 6.3.1 20170306
| 
| Could wrong ./configure options be at fault here? See:
| 
| https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40
| 
| My sessionInfo():
| 
| $ R-devel --slave -e 'sessionInfo()' | head -n3
| R Under development (unstable) (2017-04-18 r72542)
| Platform: x86_64-pc-linux-gnu (64-bit)
| Running under: Arch Linux

Maybe you can share with us how you configure the build of R-devel?  I tend
to locally build every week or so and I have the following on Ubuntu 16.10:

  CXX = ccache g++ 
  CXXCPP = $(CXX) -E
  CXXFLAGS = -ggdb -pipe -Wall -pedantic $(LTO)
  CXXPICFLAGS = -fpic
  CXX98 = ccache g++
  CXX98FLAGS = -ggdb -pipe -Wall -pedantic
  CXX98PICFLAGS = -fpic
  CXX98STD = -std=gnu++98
  CXX11 = ccache g++
  CXX11FLAGS = -ggdb -pipe -Wall -pedantic
  CXX11PICFLAGS = -fpic
  CXX11STD = -std=gnu++11
  CXX14 = ccache g++
  CXX14FLAGS = -ggdb -pipe -Wall -pedantic
  CXX14PICFLAGS = -fpic
  CXX14STD = 
  CXX17 = 
  CXX17FLAGS = 
  CXX17PICFLAGS = 
  CXX17STD = 

I call configure in build shell script (which has not changed in years) with 

  R_PAPERSIZE=letter\
  R_BATCHSAVE="--no-save --no-restore"  \
  R_BROWSER=xdg-open\
  PAGER=/usr/bin/pager  \
  PERL=/usr/bin/perl\
  R_UNZIPCMD=/usr/bin/unzip \
  R_ZIPCMD=/usr/bin/zip \
  R_PRINTCMD=/usr/bin/lpr   \
  LIBnn=lib \
  AWK=/usr/bin/awk  \
  CC="ccache gcc"   \
  CFLAGS="-ggdb -pipe -std=gnu99 -Wall -pedantic" \
  CXX="ccache g++"  \
  CXXFLAGS="-ggdb -pipe -Wall -pedantic"\
  FC="ccache gfortran"  \
  F77="ccache gfortran" \
  MAKE="make -j4"   \
  ./configure   \
  --prefix=/usr/local/lib/R-devel   \
  --enable-R-shlib  \
  --without-blas\
  --without-lapack  \
  --without-recommended-packages

Works here ...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] R 3.4 has broken C++11 support

[Martyn Plummer]

On Wed, 2017-04-19 at 13:17 +0200, Angerer, Philipp wrote:
> Hmm, doesn’t look like my R was configured incorrectly:

That looks fine. Can you please give a reproducible example of a
package that compiles correctly on R 3.3.3 but not with R 3.4.0 or R-
devel.

Martyn

> 
> 
> R is now configured for x86_64-pc-linux-gnu
> 
>   Source directory:  .
>   Installation directory:/opt/r-devel
> 
>   C compiler:gcc  -march=x86-64 -mtune=generic -O2 -pipe 
> -fstack-protector-strong --param=ssp-buffer-size=4
>   Fortran 77 compiler:   gfortran  -g -O2
> 
>   Default C++ compiler:  g++   -march=x86-64 -mtune=generic -O2 -pipe 
> -fstack-protector-strong --param=ssp-buffer-size=4
>   C++98 compiler:g++ -std=gnu++98 -march=x86-64 -mtune=generic 
> -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
>   C++11 compiler:g++ -std=gnu++11 -march=x86-64 -mtune=generic 
> -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
>   C++14 compiler:g++  -march=x86-64 -mtune=generic -O2 -pipe 
> -fstack-protector-strong --param=ssp-buffer-size=4
>   C++17 compiler:  
>   Fortran 90/95 compiler:gfortran -g -O2
>   Obj-C compiler: 
> 
>   Interfaces supported:  X11, tcltk
>   External libraries:readline, BLAS(generic), LAPACK(generic), curl
>   Additional capabilities:   PNG, JPEG, TIFF, NLS, cairo, ICU
>   Options enabled:   shared R library, R profiling
> 
>   Capabilities skipped:  
>   Options not enabled:   shared BLAS, memory profiling
> 
>   Recommended packages:  yes
> 
> - Ursprüngliche Mail -
> Von: "Angerer, Philipp" 
> An: "Martyn Plummer" 
> CC: "r-devel" 
> Gesendet: Mittwoch, 19. April 2017 12:42:33
> Betreff: Re: [Rd] R 3.4 has broken C++11 support
> 
> Hi! 
> 
> Well, my linux distribution has very recent versions 
> of everything, so a working C++11 compiler exists: 
> 
> $ gcc --version | head -n1 
> gcc (GCC) 6.3.1 20170306 
> 
> Could wrong ./configure options be at fault here? See: 
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40 
> 
> My sessionInfo(): 
> 
> $ R-devel --slave -e 'sessionInfo()' | head -n3 
> R Under development (unstable) (2017-04-18 r72542) 
> Platform: x86_64-pc-linux-gnu (64-bit) 
> Running under: Arch Linux 
> 
> Thanks, Philipp 
> 
>  
> 
> Helmholtz Zentrum Muenchen
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
> Ingolstaedter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
> Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr.
> Alfons Enhsen
> Registergericht: Amtsgericht Muenchen HRB 6466
> USt-IdNr: DE 129521671
> 
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R 3.4 has broken C++11 support

[Martyn Plummer]

On Wed, 2017-04-19 at 12:42 +0200, Angerer, Philipp wrote:
> Hi!
> 
> Well, my linux distribution has very recent versions
> of everything, so a working C++11 compiler exists:
> 
> $ gcc --version | head -n1
> gcc (GCC) 6.3.1 20170306

I am on Fedora 25 which also uses gcc 6.3.1. The default standard for
6.3.1 is C++14. The output from configure should contain these lines:

  Default C++ compiler:  g++   
  C++98 compiler:g++ -std=gnu++98 
  C++11 compiler:g++ -std=gnu++11 
  C++14 compiler:g++  
  C++17 compiler:  

Please check.

Martyn

> Could wrong ./configure options be at fault here? See:
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40
> 
> My sessionInfo():
> 
> $ R-devel --slave -e 'sessionInfo()' | head -n3
> R Under development (unstable) (2017-04-18 r72542)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Arch Linux
> 
> Thanks, Philipp
>  
> 
> Helmholtz Zentrum Muenchen
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
> Ingolstaedter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
> Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr.
> Alfons Enhsen
> Registergericht: Amtsgericht Muenchen HRB 6466
> USt-IdNr: DE 129521671
> 
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Recent error in FamAgg with R-3.4rc

[Rainer Johannes]

Thanks Lori for the info!

Actually, the maintainer of the gap package fixed the problem now in his 
package. Once the new version of gap is in CRAN (hopefully soon) the error in 
FamAgg will be gone too.

cheers, jo

On 19 Apr 2017, at 12:56, Shepherd, Lori 
> wrote:

You can continue to commit changes and bug corrections until this Friday 21.  
After that date any change will remain in devel and if necessary would have to 
be corrected in release after the release is finished.

Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263

From: Bioc-devel 
> on 
behalf of Rainer Johannes 
>
Sent: Wednesday, April 19, 2017 3:51:01 AM
To: bioc-devel
Subject: [Bioc-devel] Recent error in FamAgg with R-3.4rc

Dear all,

Somehow the FamAgg fails building with the recent R-3.4rc in Windows. I tracked 
down the error and it comes from a fortran code in a function from the "gap" 
CRAN package I'm using in one of the functions. I contacted the developer and 
in the meantime implemented a workaround in FamAgg.

My question now is if I can still submit changes to svn to fix this or is it 
already too late?

cheers, jo

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

This email message may contain legally privileged and/or confidential 
information. If you are not the intended recipient(s), or the employee or agent 
responsible for the delivery of this message to the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or use of this 
email message is prohibited. If you have received this message in error, please 
notify the sender immediately by e-mail and delete this email message from your 
computer. Thank you.


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] R 3.4 has broken C++11 support

[Angerer, Philipp via R-devel]

Hi!

Well, my linux distribution has very recent versions
of everything, so a working C++11 compiler exists:

$ gcc --version | head -n1
gcc (GCC) 6.3.1 20170306

Could wrong ./configure options be at fault here? See:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40

My sessionInfo():

$ R-devel --slave -e 'sessionInfo()' | head -n3
R Under development (unstable) (2017-04-18 r72542)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

Thanks, Philipp
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

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

Re: [Bioc-devel] Recent error in FamAgg with R-3.4rc

[Shepherd, Lori]

You can continue to commit changes and bug corrections until this Friday 21.  
After that date any change will remain in devel and if necessary would have to 
be corrected in release after the release is finished.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Rainer 
Johannes 
Sent: Wednesday, April 19, 2017 3:51:01 AM
To: bioc-devel
Subject: [Bioc-devel] Recent error in FamAgg with R-3.4rc

Dear all,

Somehow the FamAgg fails building with the recent R-3.4rc in Windows. I tracked 
down the error and it comes from a fortran code in a function from the "gap" 
CRAN package I'm using in one of the functions. I contacted the developer and 
in the meantime implemented a workaround in FamAgg.

My question now is if I can still submit changes to svn to fix this or is it 
already too late?

cheers, jo

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta

[Michael Stadler]

Dear BioC core,

Thanks for the report, Herve. If I understand correctly, there is
nothing I can do at this point to make QuasR green on windows, correct?

I have another question regarding QuasR not building on veracruz2: The
vignette does not build currently, reporting:
Error on veracruz2.bioconductor.org processing sample
/tmp/RtmpJBWrjI/chip_1_1.fq.bz2df0b6901ff33.fastq : 'asBam' internal:
samtools invoked 'abort' ...

Though it seems to build fine on other platforms, and there were no
recent changes to the vignette. What would you or other suggest to do
about that?

Any suggestions are appreciated,
Michael



On 17.04.2017 02:08, Hervé Pagès wrote:
> FWIW here are all the packages that are victim of this
> installed.packages bug in today's build report:
> 
>   alpine
>   fCI
>   GenomicFeatures
>   QuasR
> 
> We only see this error on tokay2 (Windows).
> 
> H.
> 
> 
> On 04/11/2017 04:21 PM, Gordon K Smyth wrote:
>> I restarted my PC this morning and the problem disappeared.
>>
>> I probably should have tried that last night, but it was late ...
>>
>> Thanks
>> Gordon
>>
>>> -Original Message-
>>> From: Martin Morgan [mailto:martin.mor...@roswellpark.org]
>>> Sent: Tuesday, 11 April 2017 7:20 PM
>>> To: Gordon K Smyth ; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta
>>>
>>> On 04/11/2017 05:01 AM, Gordon K Smyth wrote:
 The problem appears to be with installed.packages(). If I start a
 fresh R
>>> 3.4.0beta session, then I can run installed.packages() once with
>>> correct results,
>>> but running it a second time gives the error message:

> installed.packages()
 Error in if (file.exists(dest) && file.mtime(dest) > file.mtime(lib)
 &&  :
   missing value where TRUE/FALSE needed
>>>
>>> The test is in this code chunk, from utils/R/packages.R
>>>
>>>  for(lib in lib.loc) {
>>>  if(noCache) {
>>>  ret0 <- .readPkgDesc(lib, fields)
>>>  if(length(ret0)) retval <- rbind(retval, ret0)
>>>  } else {
>>>  ## Previously used URLencode for e.g. Windows paths with
>>> drives
>>>  ## This version works for very long file names.
>>>  base <- paste(c(lib, fields), collapse = ",")
>>>  ## add length and 64-bit CRC in hex (in theory, seems
>>>  ## it is actually 32-bit on some systems)
>>>  enc <- sprintf("%d_%s", nchar(base), .Call(C_crc64, base))
>>>  dest <- file.path(tempdir(), paste0("libloc_", enc,
>>> ".rds"))
>>>  if(file.exists(dest) &&
>>> file.mtime(dest) > file.mtime(lib) &&
>>> (val <- readRDS(dest))$base == base)
>>>  ## use the cache file
>>>  retval <- rbind(retval, val$value)
>>>  else {
>>>  ret0 <- .readPkgDesc(lib, fields)
>>>  if(length(ret0)) {
>>>  retval <- rbind(retval, ret0)
>>>  ## save the cache file
>>>  saveRDS(list(base = base, value = ret0), dest)
>>>  }
>>>  }
>>>  }
>>>
>>>
>>> where 'lib' is one of .libPaths(), 'dest' is one of
>>>
>>>dir(tempdir(), pattern="libloc_", full=TRUE)
>>>
>>> and 'base' should be a character(1)
>>>
>>> I think the code chunk has tried to cache the packages installed in each
>>> directory of .libPaths() (the saveRDS() line), and these are somehow
>>> corrupted on the second time through (I guess evaluating the
>>> readRDS()??).
>>>
>>> For instance I have two paths in .libPaths() and after the first
>>> install.packages() I have
>>>
>>>  > str(readRDS(dir(tempdir(), full=TRUE)[1]))
>>> List of 2
>>>   $ base : chr
>>> "/home/mtmorgan/bin/R-3-4-
>>> branch/library,Version,Priority,Depends,Imports,LinkingTo,Suggests,Enhances,Li
>>>
>>> cense,Li"|
>>> __truncated__
>>>   $ value: chr [1:29, 1:17] "base" "boot" "class" "cluster" ...
>>>  > str(readRDS(dir(tempdir(), full=TRUE)[2]))
>>> List of 2
>>>   $ base : chr
>>> "/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.4-Bioc-
>>> 3.5,Version,Priority,Depends,Imports,LinkingTo,Suggests,E"|
>>> __truncated__
>>>   $ value: chr [1:513, 1:17] "abind" "acepack" "aCGH" "ADaCGH2" ...
>>>
>>> I'm guessing that one of these files is corrupted somehow, but it's not
>>> obvious how. Can you use options(error=recover) and find the values that
>>> cause the conditional to fail?
>>>
>>> Martin
>>>


> -Original Message-
> From: Gordon K Smyth
> Sent: Tuesday, 11 April 2017 6:26 PM
> To: bioc-devel@r-project.org
> Subject: Using BiocInstaller with R 3.4.0 beta
>
> I thought I would test out R 3.4.0 beta (for Windows) but now I
> can't use the
> BiocInstaller package. Attempts to use biocLite() or biocValid()
> lead to an
>>> error
> message as shown below.
>
> What have I overlooked?
>
> Thanks
> Gordon

Re: [R-pkg-devel] Build error: "DLL 'BayesFactor' not found: maybe not installed for this architecture?"

[Uwe Ligges]

A race condition on the check system.

Best,
Uwe Ligges



On 18.04.2017 13:22, Nathaniel Phillips wrote:

In submitting my package yarrr v0.1.5 to CRAN (https://github.com/
ndphillips/yarrr), I received the following error:

* installing *source* package 'yarrr' ...
** R
** data
*** moving datasets to lazyload DB
** inst
** preparing package for lazy loading
Warning: S3 methods 'is.na.BFBayesFactor', 'c.BFBayesFactor',
'plot.BFBayesFactor', 'head.BFBayesFactor', 'tail.BFBayesFactor',
'min.BFBayesFactor', 'max.BFBayesFactor', 'which.min.BFBayesFactor',
'which.max.BFBayesFactor', 'sort.BFBayesFactor',
'as.data.frame.BFBayesFactor', 'as.vector.BFBayesFactor',
'names.BFBayesFactor', 'length.BFBayesFactor', 't.BFBayesFactor',
'as.matrix.BFBayesFactorList', 'as.vector.BFBayesFactorList',
'as.mcmc.BFmcmc', 'as.matrix.BFmcmc', 'as.data.frame.BFmcmc',
'as.BFBayesFactor.BFBayesFactorTop', 'plot.BFBayesFactorTop',
'sort.BFBayesFactorTop', 'length.BFBayesFactorTop',
'as.BFBayesFactor.BFodds', 'as.BFprobability.BFodds', 'c.BFodds',
'length.BFodds', 'head.BFodds', 'tail.BFodds', 'min.BFodds',
'max.BFodds', 'which.min.BFodds', 'which.max.BFodds', 'sort.BFodds',
'as.data.frame.BFodds', 'as.vector.BFodds', 'names.BFodds',
'head.BFprobability', 'tail.BFprobability', 'min.BFprobability',
'max.BFprobability', 'which.min.BFprobability',
'which.max.BFprobability', 'sort [... truncated]
Error: package or namespace load failed for 'BayesFactor' in
library.dynam(lib, package, package.lib):
 DLL 'BayesFactor' not found: maybe not installed for this architecture?
Error : package 'BayesFactor' could not be loaded
ERROR: lazy loading failed for package 'yarrr'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/yarrr'


Here is the check log:
https://win-builder.r-project.org/incoming_pretest/170418_120616_yarrr_015/00check.log

Here is the install log:
https://win-builder.r-project.org/incoming_pretest/170418_120616_yarrr_015/00install.out

There seems to be a problem with loading the BayesFactor package.
However, when I check and build the package on my machine it loads
just fine.

Can someone help me to fix this error for CRAN submission? Thank you!

Nathaniel

nathaniel.d.phillips...@gmail.com

[[alternative HTML version deleted]]

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



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

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

[Wolfgang Huber]

Dear Hilmar

Perhaps this gives an indication of why the infinite recursion happens:

## after calling `*` on ma and a matrix:


showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE)


Function: * (package base)
e1="FOOCLASS", e2="matrix"
(inherited from: e1="vector", e2="structure")
(definition from function "Ops")
function (e1, e2)
{
value <- callGeneric(e1, e2@.Data)
if (length(value) == length(e2)) {
e2@.Data <- value
e2
}
else value
}




is(ma, "vector")

[1] TRUE

I got that in a fresh session of

sessionInfo()

R Under development (unstable) (2017-04-18 r72542)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4

Best wishes
Wolfgang

19.4.17 10:01, Hilmar Berger scripsit:

Hi,

following up on my own question, I found smaller example that does not
require LIMMA:

setClass("FOOCLASS",
 representation("list")
)
ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))


ma * ma$M

Error: C stack usage  7970512 is too close to the limit


library(xlsx)

Loading required package: rJava
Loading required package: xlsxjars

ma * ma$M

---> Crash

xlsx seems to act like a catalyst here, with the product operator
running in a deep nested iteration, exhausting the stack. Valgrind shows
thousands of invalid stack accesses when loading xslx, which might
contribute to the problem. Package xlsx has not been updated since 2014,
so it might fail with more current versions of R or Java (I'm using
Oracle Java 8).

Still, even if xlsx was the package to be blamed for the crash, I fail
to understand what exactly the product operator is trying to do in the
multiplication of the matrix with the object.

Best regards,
Hilmar

On 18/04/17 18:57, Hilmar Berger wrote:

Hi,

this is a problem that occurs in the presence of two libraries (limma,
xlsx) and leads to a crash of R. The problematic code is the wrong
application of sweep or the product ("*") function on an LIMMA MAList
object. To my knowledge, limma does not define a "*" method for MAList
objects.

If only LIMMA is loaded but not package xlsx, the code does not crash
but rather produces an error ("Error: C stack usage  7970512 is too
close to the limit"). Loading only package rJava instead of xlsx does
also not produce the crash but the error message instead. Note that
xlsx functions are not explicitly used.

It could be reproduced on two different Linux machines running
R-3.2.5, R-3.3.0 and R-3.3.2.

Code to reproduce the problem:
-
library(limma)
library(xlsx)

# a MAList
ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
M=matrix(rnorm(300), 30,10)))

# This should actually be sweep(ma$M, ...) for functional code, but I
omitted the $M...
#sweep(ma, 2, c(1:10), "*")
# sweep will crash when doing the final operation of applying the
function over the input matrix, which in this case is function "*"

f = match.fun("*")
# This is not exactly the same as in sweep but it also tries to
multiply the MAList object with a matrix of same size and leads to the
crash
f(ma, ma$M)
# ma * ma$M has the same effect
-

My output:

R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(limma)
> library(xlsx)
Loading required package: rJava
Loading required package: xlsxjars
>
> sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

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

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

other attached packages:
[1] xlsx_0.5.7 xlsxjars_0.6.1 rJava_0.9-8limma_3.30.7

loaded via a namespace (and not attached):
[1] tools_3.3.0
>
> ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
M=matrix(rnorm(300), 30,10)))
> #sweep(ma, 2, c(1:10), "*")
>
> f = match.fun("*")
> f
function (e1, e2)  .Primitive("*")

> f(ma, ma$M)

> crash to command line with segfault.

Best regards,
Hilmar





__
R-devel@r-project.org mailing 

Re: [Rd] Crash after (wrongly) applying product operator on object from LIMMA package

[Hilmar Berger]

Hi,

following up on my own question, I found smaller example that does not 
require LIMMA:


setClass("FOOCLASS",
 representation("list")
)
ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))

> ma * ma$M
Error: C stack usage  7970512 is too close to the limit

> library(xlsx)
Loading required package: rJava
Loading required package: xlsxjars
> ma * ma$M
---> Crash

xlsx seems to act like a catalyst here, with the product operator 
running in a deep nested iteration, exhausting the stack. Valgrind shows 
thousands of invalid stack accesses when loading xslx, which might 
contribute to the problem. Package xlsx has not been updated since 2014, 
so it might fail with more current versions of R or Java (I'm using 
Oracle Java 8).


Still, even if xlsx was the package to be blamed for the crash, I fail 
to understand what exactly the product operator is trying to do in the 
multiplication of the matrix with the object.


Best regards,
Hilmar

On 18/04/17 18:57, Hilmar Berger wrote:

Hi,

this is a problem that occurs in the presence of two libraries (limma, 
xlsx) and leads to a crash of R. The problematic code is the wrong 
application of sweep or the product ("*") function on an LIMMA MAList 
object. To my knowledge, limma does not define a "*" method for MAList 
objects.


If only LIMMA is loaded but not package xlsx, the code does not crash 
but rather produces an error ("Error: C stack usage  7970512 is too 
close to the limit"). Loading only package rJava instead of xlsx does 
also not produce the crash but the error message instead. Note that 
xlsx functions are not explicitly used.


It could be reproduced on two different Linux machines running 
R-3.2.5, R-3.3.0 and R-3.3.2.


Code to reproduce the problem:
-
library(limma)
library(xlsx)

# a MAList
ma = new("MAList", list(A=matrix(rnorm(300), 30,10), 
M=matrix(rnorm(300), 30,10)))


# This should actually be sweep(ma$M, ...) for functional code, but I 
omitted the $M...

#sweep(ma, 2, c(1:10), "*")
# sweep will crash when doing the final operation of applying the 
function over the input matrix, which in this case is function "*"


f = match.fun("*")
# This is not exactly the same as in sweep but it also tries to 
multiply the MAList object with a matrix of same size and leads to the 
crash

f(ma, ma$M)
# ma * ma$M has the same effect
-

My output:

R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(limma)
> library(xlsx)
Loading required package: rJava
Loading required package: xlsxjars
>
> sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

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


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

other attached packages:
[1] xlsx_0.5.7 xlsxjars_0.6.1 rJava_0.9-8limma_3.30.7

loaded via a namespace (and not attached):
[1] tools_3.3.0
>
> ma = new("MAList", list(A=matrix(rnorm(300), 30,10), 
M=matrix(rnorm(300), 30,10)))

> #sweep(ma, 2, c(1:10), "*")
>
> f = match.fun("*")
> f
function (e1, e2)  .Primitive("*")

> f(ma, ma$M)

> crash to command line with segfault.

Best regards,
Hilmar



--
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charitéplatz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:+ 49 30 28460 401
 
E-Mail: ber...@mpiib-berlin.mpg.de

Web   : www.mpiib-berlin.mpg.de

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

[Bioc-devel] Recent error in FamAgg with R-3.4rc

[Rainer Johannes]

Dear all,

Somehow the FamAgg fails building with the recent R-3.4rc in Windows. I tracked 
down the error and it comes from a fortran code in a function from the "gap" 
CRAN package I'm using in one of the functions. I contacted the developer and 
in the meantime implemented a workaround in FamAgg.

My question now is if I can still submit changes to svn to fix this or is it 
already too late?

cheers, jo

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Package Version Checking

[Richard Barnes]

This is a feature suggestion.

My apologies if it's already been raised.

I recently noticed that dplyr's behaviour has changed:
> *dplyr 0.4.0*
> df <- data_frame(x = c(1, 1, 1, 2, 2), y = 1:5)
> result <- df %>% dplyr::distinct(x) %>% sum
> *# result == 8*
>
> *dplyr 0.5.0*
> df <- data_frame(x = c(1, 1, 1, 2, 2), y = 1:5)
> result <- df %>% dplyr::distinct(x) %>% sum
> *# result == 3*
That's fine. It's nice to see package maintainers fixing bugs and
improving functionality.

What's not fine is that for most users, myself included, this change was
essentially silent.

I would suggest amending the `library` and `require` functions as
follows, e.g.:
> library(dplyr, version='0.4.0', versioning='semantic')
> library(dplyr, version='0.4.0', versioning='exact')
If the version check indicates the package has been updated in a way
which doesn't maintain backwards compatibility, a warning message would
be generated or, possibly, the code would halt.

This would provide R users a way of specifying the conditions under
which their scripts produced the results they obtain.

Best regards,
Richard

[[alternative HTML version deleted]]

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