date:20171130

Dear Uwe,


Thank you very much for your help.


Sorry that I misread your email about the maintainer. 
@Dirk

Thank you for pointing this out.@Ege


Best regards,

Senren





From: Uwe Ligges 
Sent: 01 December 2017 05:51:35
To: Tan, Senren; Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Errors in the pre-test after submitting the R package



On 30.11.2017 22:46, Tan, Senren wrote:
> Dear Uwe,
>
>
> |One more question: Which version of fftw do you need for these symbols?
>
>
> The system requirement for fftw is fftw-3.3.4 or above. I have tried to
> build that on fftw-3.3.4, as well as on fftw-3.3.6.
>

The fftw on winbuilder is rather outdated.
I see what I can do to update it during the next days.

Best,
Uwe Ligges





>
> Thank you very much.
>
>
> Best regards,
>
> Senren
>
>
>
>
> 
> *From:* Uwe Ligges 
> *Sent:* 01 December 2017 05:33:44
> *To:* Dirk Eddelbuettel; Tan, Senren
> *Cc:* r-package-devel@r-project.org
> *Subject:* Re: [R-pkg-devel] Errors in the pre-test after submitting the
> R package
>
>
> On 30.11.2017 19:57, Dirk Eddelbuettel wrote:
>>
>> Hi Senren,
>>
>> On 30 November 2017 at 16:49, Tan, Senren wrote:
>> | Thank you very much for your reply.
>>
>> My pleasure. You did well here.
>>
>> | I have been trying to look at the R package fftw developed by Olaf and Uwe 
>> over the last few days. And I have tried to make use of the configure.ac. 
>> file in their source package to generate the configure script. I tried R CMD 
>> Check on my Mac, as well as  on some machines running Linux. It seems that I 
>> could pass all the R
> CMD Checks on these Unix / Linux machines.
>>
>> Great!  [ Configure/autoconf are hated by many but it is really just a shell
>> scripting variant.  I don't mind it as much.  And great when it works. ]
>>
>> | Also, I have come across the following website 
>> https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html,
> on which it seems to suggest that the C library fftw3 (with the make
> variable LIB_FFTW) is installed on the CRAN build machine for Windows.
>>
>> Yes!
>> |
>> | So, I tried the following Makevars.win.
>> |
>> | PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
>> | CXX11 = g++
>> | PKG_CXXFLAGS = -std=c++11
>> | PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3
>>
>> That looks correct to me (assuming LIB_FFTW is the chosen name). I do
>> something similar with my packages linking to the GNU GSL.
>>
>> | However, when I tried to re-submit the package to CRAN, I still got the 
>> same error message on the pre-test as follows, suggesting that the machine 
>> had not detected the fftw3 library.
>> |
>> |  **
>> |WARNING: this package has a configure script
>> |  It probably needs manual configuration
>> |**
>> |
>> | ** libs
>> |
>> | *** arch - i386
>> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
>> -I"D:/RCompile/recent/R/include" -DNDEBUG 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215 
>> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
>> -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall  
>> -mtune=core2 -c RcppExports.cpp -o RcppExports.o
>> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
>> -I"D:/RCompile/recent/R/include" -DNDEBUG 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215 
>> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
>> -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall  
>> -mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
>> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
>> -I"D:/RCompile/recent/R/include" -DNDEBUG 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215 
>> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
>> -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall  
>> -mtune=core2 -c crossprob_new.cc -o crossprob_new.o
>> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
>> -I"D:/RCompile/recent/R/include" -DNDEBUG 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215 
>> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
>> -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall  
>> -mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
>> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
>> -I"D:/RCompile/recent/R/include" -DNDEBUG 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
>> -Id:/Rcompile/CRANpkg/extralibs215/local215 
>> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
>> -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall

Re: [R-pkg-devel] Errors in the pre-test after submitting the R package

2017-11-30 Thread Uwe Ligges




On 30.11.2017 22:46, Tan, Senren wrote:

Dear Uwe,


|One more question: Which version of fftw do you need for these symbols?


The system requirement for fftw is fftw-3.3.4 or above. I have tried to 
build that on fftw-3.3.4, as well as on fftw-3.3.6.




The fftw on winbuilder is rather outdated.
I see what I can do to update it during the next days.

Best,
Uwe Ligges







Thank you very much.


Best regards,

Senren





*From:* Uwe Ligges 
*Sent:* 01 December 2017 05:33:44
*To:* Dirk Eddelbuettel; Tan, Senren
*Cc:* r-package-devel@r-project.org
*Subject:* Re: [R-pkg-devel] Errors in the pre-test after submitting the 
R package



On 30.11.2017 19:57, Dirk Eddelbuettel wrote:


Hi Senren,

On 30 November 2017 at 16:49, Tan, Senren wrote:
| Thank you very much for your reply.

My pleasure. You did well here.
  
| I have been trying to look at the R package fftw developed by Olaf and Uwe over the last few days. And I have tried to make use of the configure.ac. file in their source package to generate the configure script. I tried R CMD Check on my Mac, as well as  on some machines running Linux. It seems that I could pass all the R 

CMD Checks on these Unix / Linux machines.


Great!  [ Configure/autoconf are hated by many but it is really just a shell
scripting variant.  I don't mind it as much.  And great when it works. ]
  
| Also, I have come across the following website https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html, 
on which it seems to suggest that the C library fftw3 (with the make 
variable LIB_FFTW) is installed on the CRAN build machine for Windows.


Yes!
|
| So, I tried the following Makevars.win.
|
| PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
| CXX11 = g++
| PKG_CXXFLAGS = -std=c++11
| PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3

That looks correct to me (assuming LIB_FFTW is the chosen name). I do
something similar with my packages linking to the GNU GSL.
  
| However, when I tried to re-submit the package to CRAN, I still got the same error message on the pre-test as follows, suggesting that the machine had not detected the fftw3 library.

|
|  **
|    WARNING: this package has a configure script
|  It probably needs manual configuration
|    **
|
| ** libs
|
| *** arch - i386
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
-std=c++11   -O2 -Wall  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
-std=c++11   -O2 -Wall  -mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
-std=c++11   -O2 -Wall  -mtune=core2 -c crossprob_new.cc -o crossprob_new.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
-std=c++11   -O2 -Wall  -mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
-std=c++11   -O2 -Wall  -mtune=core2 -c fftwconvolver.cc -o fftwconvolver.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG -Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall  -mtune=core2 -c 

one_sided_noncrossing_probability.cc -o one_sided_noncrossing_probability.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG -Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" -std=c++11   -O2 -Wall

Re: [R-pkg-devel] Errors in the pre-test after submitting the R package

Dear Uwe,


|One more question: Which version of fftw do you need for these symbols?


The system requirement for fftw is fftw-3.3.4 or above. I have tried to build 
that on fftw-3.3.4, as well as on fftw-3.3.6.


Thank you very much.


Best regards,

Senren





From: Uwe Ligges 
Sent: 01 December 2017 05:33:44
To: Dirk Eddelbuettel; Tan, Senren
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Errors in the pre-test after submitting the R package



On 30.11.2017 19:57, Dirk Eddelbuettel wrote:
>
> Hi Senren,
>
> On 30 November 2017 at 16:49, Tan, Senren wrote:
> | Thank you very much for your reply.
>
> My pleasure. You did well here.
>
> | I have been trying to look at the R package fftw developed by Olaf and Uwe 
> over the last few days. And I have tried to make use of the configure.ac. 
> file in their source package to generate the configure script. I tried R CMD 
> Check on my Mac, as well as on some machines running Linux. It seems that I 
> could pass all the R CMD Checks on these Unix / Linux machines.
>
> Great!  [ Configure/autoconf are hated by many but it is really just a shell
> scripting variant.  I don't mind it as much.  And great when it works. ]
>
> | Also, I have come across the following website 
> https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html, on 
> which it seems to suggest that the C library fftw3 (with the make variable 
> LIB_FFTW) is installed on the CRAN build machine for Windows.
>
> Yes!
> |
> | So, I tried the following Makevars.win.
> |
> | PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
> | CXX11 = g++
> | PKG_CXXFLAGS = -std=c++11
> | PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3
>
> That looks correct to me (assuming LIB_FFTW is the chosen name). I do
> something similar with my packages linking to the GNU GSL.
>
> | However, when I tried to re-submit the package to CRAN, I still got the 
> same error message on the pre-test as follows, suggesting that the machine 
> had not detected the fftw3 library.
> |
> |  **
> |WARNING: this package has a configure script
> |  It probably needs manual configuration
> |**
> |
> | ** libs
> |
> | *** arch - i386
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c RcppExports.cpp -o RcppExports.o
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c crossprob_new.cc -o crossprob_new.o
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c fftwconvolver.cc -o fftwconvolver.o
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c one_sided_noncrossing_probability.cc -o 
> one_sided_noncrossing_probability.o
> | d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
> -I"D:/RCompile/recent/R/include" -DNDEBUG 
> -Id:/Rcompile/CRANpkg/extralibs215/local215/include 
> -Id:/Rcompile/CRANpkg/extralibs215/local215 
> -I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
> -I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
> -mtune=core2 -c

Re: [R-pkg-devel] Errors in the pre-test after submitting the R package

Dear Dirk,


Thank you very much for your reply.


|That looks like it expanded right.

|What I would do now is take one of the working packages, create a local
|tarball _and put my name and email into Maintainer_ because that way the
|win-builder test log will come back to me.  And then submit, and compare.

I have put your name and email into the Maintainer of the package. I submitted 
the package to Win-Builder just now.

Best regards,
Senren





From: Dirk Eddelbuettel  on behalf of Dirk 
Eddelbuettel 
Sent: 01 December 2017 02:57:56
To: Tan, Senren
Cc: Dirk Eddelbuettel; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Errors in the pre-test after submitting the R package


Hi Senren,

On 30 November 2017 at 16:49, Tan, Senren wrote:
| Thank you very much for your reply.

My pleasure. You did well here.

| I have been trying to look at the R package fftw developed by Olaf and Uwe 
over the last few days. And I have tried to make use of the configure.ac. file 
in their source package to generate the configure script. I tried R CMD Check 
on my Mac, as well as on some machines running Linux. It seems that I could 
pass all the R CMD Checks on these Unix / Linux machines.

Great!  [ Configure/autoconf are hated by many but it is really just a shell
scripting variant.  I don't mind it as much.  And great when it works. ]

| Also, I have come across the following website 
https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html, on 
which it seems to suggest that the C library fftw3 (with the make variable 
LIB_FFTW) is installed on the CRAN build machine for Windows.

Yes!
|
| So, I tried the following Makevars.win.
|
| PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
| CXX11 = g++
| PKG_CXXFLAGS = -std=c++11
| PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3

That looks correct to me (assuming LIB_FFTW is the chosen name). I do
something similar with my packages linking to the GNU GSL.

| However, when I tried to re-submit the package to CRAN, I still got the same 
error message on the pre-test as follows, suggesting that the machine had not 
detected the fftw3 library.
|
|  **
|WARNING: this package has a configure script
|  It probably needs manual configuration
|**
|
| ** libs
|
| *** arch - i386
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c RcppExports.cpp -o RcppExports.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c crossprob_new.cc -o crossprob_new.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c fftwconvolver.cc -o fftwconvolver.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability.cc -o 
one_sided_noncrossing_probability.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall

Re: [R-pkg-devel] Errors in the pre-test after submitting the R package

2017-11-30 Thread Uwe Ligges




On 30.11.2017 19:57, Dirk Eddelbuettel wrote:


Hi Senren,

On 30 November 2017 at 16:49, Tan, Senren wrote:
| Thank you very much for your reply.

My pleasure. You did well here.
  
| I have been trying to look at the R package fftw developed by Olaf and Uwe over the last few days. And I have tried to make use of the configure.ac. file in their source package to generate the configure script. I tried R CMD Check on my Mac, as well as on some machines running Linux. It seems that I could pass all the R CMD Checks on these Unix / Linux machines.


Great!  [ Configure/autoconf are hated by many but it is really just a shell
scripting variant.  I don't mind it as much.  And great when it works. ]
  
| Also, I have come across the following website https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html, on which it seems to suggest that the C library fftw3 (with the make variable LIB_FFTW) is installed on the CRAN build machine for Windows.


Yes!
|
| So, I tried the following Makevars.win.
|
| PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
| CXX11 = g++
| PKG_CXXFLAGS = -std=c++11
| PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3

That looks correct to me (assuming LIB_FFTW is the chosen name). I do
something similar with my packages linking to the GNU GSL.
  
| However, when I tried to re-submit the package to CRAN, I still got the same error message on the pre-test as follows, suggesting that the machine had not detected the fftw3 library.

|
|  **
|WARNING: this package has a configure script
|  It probably needs manual configuration
|**
|
| ** libs
|
| *** arch - i386
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c crossprob_new.cc -o crossprob_new.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c fftwconvolver.cc -o fftwconvolver.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c one_sided_noncrossing_probability.cc -o 
one_sided_noncrossing_probability.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c one_sided_noncrossing_probability_n2.cc -o 
one_sided_noncrossing_probability_n2.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   -I"d:/Compiler/gcc-4.9.3/local330/include" 
 -std=c++11   -O2 -Wall  -mtune=core2 -c one_sided_noncrossing_probability_n2logn.cc -o 
one_sided_noncrossing_probability_n2logn.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include -Id:/Rcompile/CRANpkg/extralibs215/local215

Re: [R-pkg-devel] Errors in the pre-test after submitting the R package

2017-11-30 Thread Dirk Eddelbuettel


Hi Senren,

On 30 November 2017 at 16:49, Tan, Senren wrote:
| Thank you very much for your reply.

My pleasure. You did well here.
 
| I have been trying to look at the R package fftw developed by Olaf and Uwe 
over the last few days. And I have tried to make use of the configure.ac. file 
in their source package to generate the configure script. I tried R CMD Check 
on my Mac, as well as on some machines running Linux. It seems that I could 
pass all the R CMD Checks on these Unix / Linux machines.

Great!  [ Configure/autoconf are hated by many but it is really just a shell
scripting variant.  I don't mind it as much.  And great when it works. ]
 
| Also, I have come across the following website 
https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html, on 
which it seems to suggest that the C library fftw3 (with the make variable 
LIB_FFTW) is installed on the CRAN build machine for Windows.

Yes!
| 
| So, I tried the following Makevars.win.
| 
| PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
| CXX11 = g++
| PKG_CXXFLAGS = -std=c++11
| PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3

That looks correct to me (assuming LIB_FFTW is the chosen name). I do
something similar with my packages linking to the GNU GSL.
 
| However, when I tried to re-submit the package to CRAN, I still got the same 
error message on the pre-test as follows, suggesting that the machine had not 
detected the fftw3 library.
| 
|  **
|WARNING: this package has a configure script
|  It probably needs manual configuration
|**
| 
| ** libs
| 
| *** arch - i386
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c RcppExports.cpp -o RcppExports.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c crossprob_new.cc -o crossprob_new.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c fftwconvolver.cc -o fftwconvolver.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability.cc -o 
one_sided_noncrossing_probability.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability_n2.cc -o 
one_sided_noncrossing_probability_n2.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability_n2logn.cc -o 
one_sided_noncrossing_probability_n2logn.o
| d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"

Re: [R-pkg-devel] New package submission error (ieee_arithmetic)

2017-11-30 Thread Avraham Adler

On Wed, Nov 29, 2017 at 4:37 PM, Waleed Almutiry  wrote:
> Hi all,
>
> I tried to upload my package to CRAN and did not pass the the incoming 
> checks. This was because the use of ieee_arithmetic module in a fortran 
> subroutine in the src folder. I built and checked the package using (R CMD 
> build) and (R CMD check) under IOS system and it is working fine without 
> errors. The gcc version in my system is (GNU Fortran (GCC) 5.2.0) while the 
> gcc version in the CRAN system is 4.9.3. This is the message that I have got 
> from the CRAN:
[snip]
>
> I used the ieee_arithmetic in some subroutines to read and write results of 
> Infinity values. I used it inside the subroutine as
>
> IF (ieee_support_inf(Inf)) THEN Inf = ieee_value(Inf, ieee_positive_inf) END 
> IF
>

Hello, Waleed.

I handled Inf and NaN by writing a C function that passes the magic
code words R_NaN and INFINITY and called them as external functions in
Fortran. See the source code of 'utils_and_wrappers.c' and
'delaporte.f95' at [1] for a working example of "set_nan" and
"set_inf"ideas. Originally, I used the actual bitpatterns to make the
functions pure, if not elemental, but Soldaris SPARC through a fit
since it was the opposite endian from the rest of the known universe.
Using the magic R words will ensure that the proper values will be
passed regardless of platform.

Hope that helps,

Avi

[1] https://bitbucket.org/aadler/delaporte

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

Re: [R-pkg-devel] New package submission error (ieee_arithmetic)

2017-11-30 Thread Avraham Adler

On Wed, Nov 29, 2017 at 4:37 PM, Waleed Almutiry  wrote:
> I tried to upload my package to CRAN and did not pass the the incoming 
> checks. This was because the use of ieee_arithmetic module in a fortran 
> subroutine in the src folder. I built and checked the package using (R CMD 
> build) and (R CMD check) under IOS system and it is working fine without 
> errors. The gcc version in my system is (GNU Fortran (GCC) 5.2.0) while the 
> gcc version in the CRAN system is 4.9.3. This is the message that I have got 
> from the CRAN:

I ran into this problem with my Delaporte package. GCC 4.9.3 does not
support the IEEE modules, which were added in the GFortran tied to GCC
5.0. I believe you will have to re-write your code to comply with
4.9.3 until Jeroen et. al. release a new version of Rtolls built on a
newer version of GCC.

Avi

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

[R-pkg-devel] New package submission error (ieee_arithmetic)

2017-11-30 Thread Waleed Almutiry

Hi all,

I tried to upload my package to CRAN and did not pass the the incoming checks. 
This was because the use of ieee_arithmetic module in a fortran subroutine in 
the src folder. I built and checked the package using (R CMD build) and (R CMD 
check) under IOS system and it is working fine without errors. The gcc version 
in my system is (GNU Fortran (GCC) 5.2.0) while the gcc version in the CRAN 
system is 4.9.3. This is the message that I have got from the CRAN:


* installing *source* package 'EpiILMCT' ...
** libs

*** arch - i386
d:/Compiler/gcc-4.9.3/mingw_32/bin/gfortran-pedantic -fbounds-check -O3  
-mtune=core2 -c  datsim.f95 -o datsim.o
datsim.f95:21.4:

USE ieee_arithmetic
1
Fatal Error: Can't open module file 'ieee_arithmetic.mod' for reading at (1): 
No such file or directory
make: *** [datsim.o] Error 1
ERROR: compilation failed for package 'EpiILMCT'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/EpiILMCT'

I used the ieee_arithmetic in some subroutines to read and write results of 
Infinity values. I used it inside the subroutine as

IF (ieee_support_inf(Inf)) THEN Inf = ieee_value(Inf, ieee_positive_inf) END IF

So, any thought of how to overcome this issue, would be highly beneficial to me.


Many thanks,

Waleed


[[alternative HTML version deleted]]

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

Re: [Rd] binary form of is() contradicts its unary form

On 30 November 2017 at 16:30, Iñaki Úcar  wrote:
> If you really believe that references should be needed to know what to
> expect from a function call, then we work with different definitions

A behaviour of a function call might be quite complex depending on
the arguments characteristics,  it may not possible always to boil
down all possible behaviours of a function to a man page as in `?`,
and sometimes giving a reference to a larger exposition makes more
sense.

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

Re: [Bioc-devel] Data package timeouts

2017-11-30 Thread Leonardo Collado Torres

Thanks Sean! I was seeing timeouts also in recount related to GEOquery
which I just recently looked into.

On Thu, Nov 30, 2017 at 11:14 AM, Sean Davis  wrote:

>
> On Thu, Nov 30, 2017 at 6:05 AM, Mike Smith  wrote:
>
> > Thanks for the speedy response Sean.  I'll switch back to the version
> > using a file name shortly.
> >
>
> No problem. Let me know if it does not work as expected.
>
> Sean
>
>
>
> >
> > Cheers,
> > Mike
> >
> > On 30 November 2017 at 11:20, Sean Davis  wrote:
> >
> >> Thanks for the report, Mike.
> >>
> >> The problem was (specifically) in parsing a GSEMatrix file using a
> >> filename. This should be fixed in versions 2.46.10 (release) and 2.47.12
> >> (devel).
> >>
> >> Sean
> >>
> >>
> >> On Thu, Nov 30, 2017 at 4:09 AM, Mike Smith 
> wrote:
> >>
> >>> Hi Mike,
> >>>
> >>> I was experiencing similar problems with the BeadArrayUseCases
> vignette,
> >>> where using getGEO() from GEOquery was getting stuck in a (seemingly)
> >>> infinite loop processing a GSE series matrix file.  It looks like both
> of
> >>> your examples try to do this too, so I suspect it's a similar issue.  I
> >>> think the format of those files has changed recently and it seems to be
> >>> causing a fair few issues with GEOquery.
> >>>
> >>> I temporarily settled a solution by getting querying GEO directly
> rather
> >>> than using a local file, but it would be nice to get it back working as
> >>> intended.
> >>>
> >>> Mike
> >>>
> >>> On 29 November 2017 at 18:56, Michael Love <
> michaelisaiahl...@gmail.com>
> >>> wrote:
> >>>
> >>> > I got simultaneous timeout notices for 'airway' and 'parathyroidSE'
> on
> >>> > both release and devel machines (release was fine leading up to the
> >>> > Bioc release).
> >>> >
> >>> > Not sure what's the issue, I haven't changed these packages in a
> >>> > while. I checked these out and these both build fine and in ~30s on
> my
> >>> > machine (devel branch).
> >>> >
> >>> > Here are the reports for release:
> >>> >
> >>> > http://bioconductor.org/checkResults/release/data-
> >>> > experiment-LATEST/airway/malbec1-buildsrc.html
> >>> > http://bioconductor.org/checkResults/release/data-experiment-LATEST/
> >>> > parathyroidSE/malbec1-buildsrc.html
> >>> >
> >>> > The vignettes are here:
> >>> >
> >>> > http://bioconductor.org/packages/3.6/data/experiment/
> >>> > vignettes/airway/inst/doc/airway.html
> >>> > http://bioconductor.org/packages/3.6/data/experiment/
> >>> > vignettes/parathyroidSE/inst/doc/parathyroidSE.pdf
> >>> >
> >>> > best,
> >>> > Mike
> >>> >
> >>> > ___
> >>> > 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
> >>>
> >>
> >>
> >>
> >> --
> >> Sean Davis, MD, PhD
> >> Center for Cancer Research
> >> National Cancer Institute
> >> National Institutes of Health
> >> Bethesda, MD 20892
> >> https://seandavi.github.io/
> >> https://twitter.com/seandavis12
> >>
> >
> >
>
>
> --
> Sean Davis, MD, PhD
> Center for Cancer Research
> National Cancer Institute
> National Institutes of Health
> Bethesda, MD 20892
> https://seandavi.github.io/
> https://twitter.com/seandavis12
>
> [[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: [Bioc-devel] Build failing for MutationalPatterns

2017-11-30 Thread Martin Morgan

On 11/30/2017 10:01 AM, Janssen-10, R.R.E. wrote:

Dear Martin,

Martin writes:

On 11/29/2017 11:14 AM, Janssen-10, R.R.E. wrote:

Hi Martin,

Thanks for your reply!

Martin Morgan writes:

On 11/29/2017 09:58 AM, Janssen-10, R.R.E. wrote:

Dear Bioconductor,

The build for MutationalPatterns has been failing for a week. The exact same
code built fine, because the last commit ups the version number to 1.4.1, which
is the version that is available on Bioconductor.

I also cannot reproduce the error with the code from upstream on my computer.
What can we do about this to fix the build on your infrastructure?

I reproduced this on my linux laptop, installing the package and then
running

MutationalPatterns/vignettes master$ Rdev CMD Sweave --pdf
Introduction_to_MutationalPatterns.Rnw

The key to reproducibility is using the same software as the build
system -- currently, R-devel and Bioc-devel with current packages

$ Rdev -e "BiocInstaller::biocVersion()" # 3.7
$ Rdev -e "BiocInstaller::isDevel()" # TRUE
$ Rdev -e "BiocInstaller::biocValid()" # TRUE

and to be sure that you're running in a clean checkout of your package,
e.g., by cloning into tmp

$ cd /tmp
$ git clone https://git.bioconductor.org/packages/MutationalPatterns

Apparently, I need to use a version of R that hasn't been released yet:

$ R
R version 3.4.2 (2017-09-28) -- "Short Summer"
...

library(BiocInstaller)

Bioconductor version 3.6 (BiocInstaller 1.28.0), ?biocLite for help

useDevel()

Error: 'devel' version requires a more recent R

It seems that R version 3.4.3 is going to be released tomorrow, so I'll wait
for that.

Thanks for verifying that this error can be reproduced.

For the current Bioconductor cycle, we are using the 'devel' version of
R, see

http://bioconductor.org/developers/how-to/useDevel/

The 'devel' version of R is always available, e.g., after clicking
through to your operating system of choice at
https://cran.r-project.org/bin/ and looking for something along the
lines of r-devel snapshot.

Thanks.

I have Ubuntu "xenial", for which I installed "r-base-dev" following the
instructions here:
https://cran.r-project.org/bin/linux/ubuntu/

sudo apt-get install r-base-dev

This is 'base R, but with development headers', what you want is 'r-devel'.

This

https://cran.r-project.org/bin/linux/debian/#r-devel

seems to suggest that the way to get this is via svn checkout and local
build

https://cran.r-project.org/bin/linux/debian/#installing-r-devel-or-a-release-branch-from-svn

Martin

This provides R 3.4.2, from which I cannot use the devel stuff.

I then upgraded GNU Guix's R to 3.4.3, but from there I also cannot use the
devel stuff from Bioconductor.
I attached the dependency graph for that R environment, including the
dependencies for MutationalPatterns.

So, I tested this in a container with the attached dependency graph, and I
still receive the same error:
Error: 'devel' version requires a more recent R

On R 3.4.3 I cannot reproduce the issue, so I suspect it's how our package
integrates with Bioconductor 3.7.
Is there a complete guide to get the development version up and running?

Also, should packages in Bioconductor release 3.6 be built with the development
version of R?

Thank you for your time.

Kind regards,
Roel Janssen

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.

Denk s.v.p aan het milieu voor u deze e-mail afdrukt.

This message may contain confidential information and ...{{dropped:12}}

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

Re: [R-pkg-devel] Errors in the pre-test after submitting the R package

Dear Dirk,


Thank you very much for your reply.


I have been trying to look at the R package fftw developed by Olaf and Uwe over 
the last few days. And I have tried to make use of the configure.ac. file in 
their source package to generate the configure script. I tried R CMD Check on 
my Mac, as well as on some machines running Linux. It seems that I could pass 
all the R CMD Checks on these Unix / Linux machines.


Also, I have come across the following website 
https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html, on 
which it seems to suggest that the C library fftw3 (with the make variable 
LIB_FFTW) is installed on the CRAN build machine for Windows.


So, I tried the following Makevars.win.


PKG_CPPFLAGS = -I$(LIB_FFTW)/include  -I$(LIB_FFTW)
CXX11 = g++
PKG_CXXFLAGS = -std=c++11
PKG_LIBS = -L$(LIB_FFTW)/lib${R_ARCH} -lfftw3



However, when I tried to re-submit the package to CRAN, I still got the same 
error message on the pre-test as follows, suggesting that the machine had not 
detected the fftw3 library.




 **
   WARNING: this package has a configure script
 It probably needs manual configuration
   **


** libs

*** arch - i386
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c RcppExports.cpp -o RcppExports.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c cont_ks_dist.cpp -o cont_ks_dist.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c crossprob_new.cc -o crossprob_new.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c fftw_wrappers.cc -o fftw_wrappers.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c fftwconvolver.cc -o fftwconvolver.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability.cc -o 
one_sided_noncrossing_probability.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability_n2.cc -o 
one_sided_noncrossing_probability_n2.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c one_sided_noncrossing_probability_n2logn.cc -o 
one_sided_noncrossing_probability_n2logn.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall  
-mtune=core2 -c poisson_pmf.cc -o poisson_pmf.o
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 
-I"D:/RCompile/recent/R/include" -DNDEBUG 
-Id:/Rcompile/CRANpkg/extralibs215/local215/include 
-Id:/Rcompile/CRANpkg/extralibs215/local215 
-I"d:/RCompile/CRANpkg/lib/3.5/Rcpp/include"   
-I"d:/Compiler/gcc-4.9.3/local330/include"  -std=c++11   -O2 -Wall

Re: [Bioc-devel] Build failing for MutationalPatterns

2017-11-30 Thread Sean Davis

On Thu, Nov 30, 2017 at 10:01 AM, Janssen-10, R.R.E. <
r.r.e.janssen...@umcutrecht.nl> wrote:

> Dear Martin,
>
> Martin writes:
>
> > On 11/29/2017 11:14 AM, Janssen-10, R.R.E. wrote:
> >> Hi Martin,
> >>
> >> Thanks for your reply!
> >>
> >> Martin Morgan writes:
> >>
> >>> On 11/29/2017 09:58 AM, Janssen-10, R.R.E. wrote:
>  Dear Bioconductor,
> 
>  The build for MutationalPatterns has been failing for a week.  The
> exact same code built fine, because the last commit ups the version number
> to 1.4.1, which is the version that is available on Bioconductor.
> 
>  I also cannot reproduce the error with the code from upstream on my
> computer. What can we do about this to fix the build on your infrastructure?
> >>>
> >>> I reproduced this on my linux laptop, installing the package and then
> >>> running
> >>>
> >>>MutationalPatterns/vignettes master$ Rdev CMD Sweave --pdf
> >>> Introduction_to_MutationalPatterns.Rnw
> >>>
> >>> The key to reproducibility is using the same software as the build
> >>> system -- currently, R-devel and Bioc-devel with current packages
> >>>
> >>>$ Rdev -e "BiocInstaller::biocVersion()" # 3.7
> >>>$ Rdev -e "BiocInstaller::isDevel()"   # TRUE
> >>>$ Rdev -e "BiocInstaller::biocValid()" # TRUE
> >>>
> >>> and to be sure that you're running in a clean checkout of your package,
> >>> e.g., by cloning into tmp
> >>>
> >>>$ cd /tmp
> >>>$ git clone https://git.bioconductor.org/
> packages/MutationalPatterns
> >>
> >>
> >> Apparently, I need to use a version of R that hasn't been released yet:
> >>
> >> $ R
> >> R version 3.4.2 (2017-09-28) -- "Short Summer"
> >> ...
> >>> library(BiocInstaller)
> >> Bioconductor version 3.6 (BiocInstaller 1.28.0), ?biocLite for help
> >>> useDevel()
> >> Error: 'devel' version requires a more recent R
> >>
> >> It seems that R version 3.4.3 is going to be released tomorrow, so I'll
> wait for that.
> >
> >> Thanks for verifying that this error can be reproduced.
> >
> > For the current Bioconductor cycle, we are using the 'devel' version of
> > R, see
> >
> >   http://bioconductor.org/developers/how-to/useDevel/
> >
> > The 'devel' version of R is always available, e.g., after clicking
> > through to your operating system of choice at
> > https://cran.r-project.org/bin/ and looking for something along the
> > lines of r-devel snapshot.
>
> Thanks.
>
> I have Ubuntu "xenial", for which I installed "r-base-dev" following the
> instructions here:
> https://cran.r-project.org/bin/linux/ubuntu/
>
> sudo apt-get install r-base-dev
>
> This provides R 3.4.2, from which I cannot use the devel stuff.
>
> I then upgraded GNU Guix's R to 3.4.3, but from there I also cannot use
> the devel stuff from Bioconductor.
> I attached the dependency graph for that R environment, including the
> dependencies for MutationalPatterns.
>
> So, I tested this in a container with the attached dependency graph, and I
> still receive the same error:
> Error: 'devel' version requires a more recent R
>
> On R 3.4.3 I cannot reproduce the issue, so I suspect it's how our package
> integrates with Bioconductor 3.7.
> Is there a complete guide to get the development version up and running?
>

Not a recommendation, but here is a quick way to go:

docker run -p 8787:8787 bioconductor/devel_core2

After doing so, navigating to:

http://127.0.0.1:8787/

will open up Rstudio running on R-devel with core bioc-devel packages
installed.

Full details are here: http://bioconductor.org/help/docker/

Sean



> Also, should packages in Bioconductor release 3.6 be built with the
> development version of R?
>
> Thank you for your time.
>
> Kind regards,
> Roel Janssen
>
> 
> --
>
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
> direct
> te informeren door het bericht te retourneren. Het Universitair Medisch
> Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de
> W.H.W.
> (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd
> bij
> de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
>
> Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
>
> 
> --
>
> This message may contain confidential information and ...{{dropped:30}}

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

Re: [Rd] binary form of is() contradicts its unary form

2017-11-30 15:54 GMT+01:00 Suzen, Mehmet :
>
>
> On 30 Nov 2017 14:32, "Iñaki Úcar"  wrote:
>
>>>
>>> Am I supposed to read every reference on a man page just to know what
>>> to expect from a function?
>>>
>>
>> If the reference is from John Chamber, you are supposed to read it.
>
> As a joke, it's funny.
>
>
>
> Not a joke. John Chambers is the authority in R object systems. Please do
> not mock him or resources pointing to his works.

I perfectly know John Chambers' work, thank you, and there was no
mockery towards him.

If you really believe that references should be needed to know what to
expect from a function call, then we work with different definitions
of "manual". But judging from the excellent R documentation, I would
say that the R maintainers don't share your view.

Iñaki

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

Re: [Rd] binary form of is() contradicts its unary form

On 30 Nov 2017 14:32, "Iñaki Úcar"  wrote:

>>
>> Am I supposed to read every reference on a man page just to know what
>> to expect from a function?
>>
>
> If the reference is from John Chamber, you are supposed to read it.

As a joke, it's funny.

Not a joke. John Chambers is the authority in R object systems. Please do
not mock him or resources pointing to his works.

> It is not always possible for maintainers to document everything on a man
page.

My only point is that Hervé's concern is perfectly legitimate given
the output of "?is". Whether the inconsistency is in the behaviour of
the function or in the documentation, that I don't know. Personally, I

There is no inconsistency as far as I understood; Data.frame do not have a
pure S4 super-class hierachy.

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Build failing for MutationalPatterns

2017-11-30 Thread Janssen-10, R.R.E.

Dear Martin,

Martin writes:

> On 11/29/2017 11:14 AM, Janssen-10, R.R.E. wrote:
>> Hi Martin,
>>
>> Thanks for your reply!
>>
>> Martin Morgan writes:
>>
>>> On 11/29/2017 09:58 AM, Janssen-10, R.R.E. wrote:
 Dear Bioconductor,

 The build for MutationalPatterns has been failing for a week.  The exact 
 same code built fine, because the last commit ups the version number to 
 1.4.1, which is the version that is available on Bioconductor.

 I also cannot reproduce the error with the code from upstream on my 
 computer. What can we do about this to fix the build on your 
 infrastructure?
>>>
>>> I reproduced this on my linux laptop, installing the package and then
>>> running
>>>
>>>MutationalPatterns/vignettes master$ Rdev CMD Sweave --pdf
>>> Introduction_to_MutationalPatterns.Rnw
>>>
>>> The key to reproducibility is using the same software as the build
>>> system -- currently, R-devel and Bioc-devel with current packages
>>>
>>>$ Rdev -e "BiocInstaller::biocVersion()" # 3.7
>>>$ Rdev -e "BiocInstaller::isDevel()"   # TRUE
>>>$ Rdev -e "BiocInstaller::biocValid()" # TRUE
>>>
>>> and to be sure that you're running in a clean checkout of your package,
>>> e.g., by cloning into tmp
>>>
>>>$ cd /tmp
>>>$ git clone https://git.bioconductor.org/packages/MutationalPatterns
>>
>>
>> Apparently, I need to use a version of R that hasn't been released yet:
>>
>> $ R
>> R version 3.4.2 (2017-09-28) -- "Short Summer"
>> ...
>>> library(BiocInstaller)
>> Bioconductor version 3.6 (BiocInstaller 1.28.0), ?biocLite for help
>>> useDevel()
>> Error: 'devel' version requires a more recent R
>>
>> It seems that R version 3.4.3 is going to be released tomorrow, so I'll wait 
>> for that.
>
>> Thanks for verifying that this error can be reproduced.
>
> For the current Bioconductor cycle, we are using the 'devel' version of
> R, see
>
>   http://bioconductor.org/developers/how-to/useDevel/
>
> The 'devel' version of R is always available, e.g., after clicking
> through to your operating system of choice at
> https://cran.r-project.org/bin/ and looking for something along the
> lines of r-devel snapshot.

Thanks.

I have Ubuntu "xenial", for which I installed "r-base-dev" following the 
instructions here:
https://cran.r-project.org/bin/linux/ubuntu/

sudo apt-get install r-base-dev

This provides R 3.4.2, from which I cannot use the devel stuff.

I then upgraded GNU Guix's R to 3.4.3, but from there I also cannot use the 
devel stuff from Bioconductor.
I attached the dependency graph for that R environment, including the 
dependencies for MutationalPatterns.

So, I tested this in a container with the attached dependency graph, and I 
still receive the same error:
Error: 'devel' version requires a more recent R

On R 3.4.3 I cannot reproduce the issue, so I suspect it's how our package 
integrates with Bioconductor 3.7.
Is there a complete guide to get the development version up and running?

Also, should packages in Bioconductor release 3.6 be built with the development 
version of R?

Thank you for your time.

Kind regards,
Roel Janssen

--

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.

Denk s.v.p aan het milieu voor u deze e-mail afdrukt.

--

This message may contain confidential information and is intended exclusively
for the addressee. If you receive this message unintentionally, please do not
use the contents but notify the sender immediately by return e-mail. University
Medical Center Utrecht is a legal person by public law and is registered at
the Chamber of Commerce for Midden-Nederland under no. 30244197.

Please consider the environment before printing this e-mail.

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

Re: [Rd] binary form of is() contradicts its unary form

2017-11-30 Thread Martin Maechler

> Iñaki Úcar 
> on Thu, 30 Nov 2017 14:32:12 +0100 writes:

> 2017-11-30 14:13 GMT+01:00 Suzen, Mehmet :
>> On 30 November 2017 at 14:04, Iñaki Úcar  wrote:
>>> 
>>> Am I supposed to read every reference on a man page just to know what
>>> to expect from a function?
>>> 
>> 
>> If the reference is from John Chamber, you are supposed to read it.
   (note: it is  Chamber*s* )

> As a joke, it's funny.

>> It is not always possible for maintainers to document everything on a 
man page.

Correct.  But honestly, I'm not even sure if John Chambers'
change to the help page last October dropped that description of
is() on purpose.   In my eyes, the main change to the help page was to
deemphasize the use of setIs(), and document that separately
(for experts, whereas the doc for is() and extends() is for mere useRs) :

r71460 | jmc | 2016-10-06 20:23:19 +0200 (Thu, 06. Oct 2016) |

   M src/library/methods/man/as.Rd
   M src/library/methods/man/is.Rd
   A src/library/methods/man/setAs.Rd
   A src/library/methods/man/setIs.Rd
   M src/library/methods/man/setMethod.Rd

Further changes to separate user-relevant doc. for is(), as().
Change examples in setMethod() to be acceptable R code 

> My only point is that Hervé's concern is perfectly legitimate given
> the output of "?is". 

I'd tend to agree -- but am *not* volunteering to fix it, currently.

> Whether the inconsistency is in the behaviour of
> the function or in the documentation, that I don't know. Personally, I
> think that having two functions (is, extends) with exactly the same
> output wouldn't be very practical. 

They have different "input", (or---better language-- 'argument's) :

is(, ..)
   extends(,  ..)

I would also tend to agree with Hervé that the binary and unary
uses of is()  "should be" consistent, as they are for S4, where
indeed, is() stems from.

> But it's a fact that the difference
> is not currently addressed in the man page.

correct, too.

> Iñaki

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

Re: [Rd] binary form of is() contradicts its unary form

2017-11-30 14:13 GMT+01:00 Suzen, Mehmet :
> On 30 November 2017 at 14:04, Iñaki Úcar  wrote:
>>
>> Am I supposed to read every reference on a man page just to know what
>> to expect from a function?
>>
>
> If the reference is from John Chamber, you are supposed to read it.

As a joke, it's funny.

> It is not always possible for maintainers to document everything on a man 
> page.

My only point is that Hervé's concern is perfectly legitimate given
the output of "?is". Whether the inconsistency is in the behaviour of
the function or in the documentation, that I don't know. Personally, I
think that having two functions (is, extends) with exactly the same
output wouldn't be very practical. But it's a fact that the difference
is not currently addressed in the man page.

Iñaki

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

Re: [Rd] binary form of is() contradicts its unary form

On 30 November 2017 at 14:04, Iñaki Úcar  wrote:
>
> Am I supposed to read every reference on a man page just to know what
> to expect from a function?
>

If the reference is from John Chamber, you are supposed to read it.
It is not always possible for maintainers to document everything on a man page.

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

Re: [Rd] binary form of is() contradicts its unary form

2017-11-30 13:26 GMT+01:00 Suzen, Mehmet :
> On 30 November 2017 at 11:37, Iñaki Úcar  wrote:
>> 2017-11-30 3:14 GMT+01:00 Suzen, Mehmet :
>>> My understanding is that there is no inconsistency. `is` does what it
>>> claims, from the documentation:
>>>
>>> ‘is’: With two arguments, tests whether ‘object’ can be treated as
>>>   from ‘class2’.
>>>
>>>   With one argument, returns all the super-classes of this
>>>   object's class.
>>
>> Note that this is not in the documentation since a year ago.
>>
>
> As far as I understood and gather, starting from methods v3.3.2, the following
> new reference is added:
>
> * Chambers, John M. (2016) Extending R, Chapman & Hall. (Chapters 9 and 10.)
>
> Pushing that details there, I assume.

Am I supposed to read every reference on a man page just to know what
to expect from a function?

Iñaki

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

Re: [Rd] binary form of is() contradicts its unary form

On 30 November 2017 at 11:37, Iñaki Úcar  wrote:
> 2017-11-30 3:14 GMT+01:00 Suzen, Mehmet :
>> My understanding is that there is no inconsistency. `is` does what it
>> claims, from the documentation:
>>
>> ‘is’: With two arguments, tests whether ‘object’ can be treated as
>>   from ‘class2’.
>>
>>   With one argument, returns all the super-classes of this
>>   object's class.
>
> Note that this is not in the documentation since a year ago.
>

As far as I understood and gather, starting from methods v3.3.2, the following
new reference is added:

* Chambers, John M. (2016) Extending R, Chapman & Hall. (Chapters 9 and 10.)

Pushing that details there, I assume.

Best,
Mehmet

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

[R-pkg-devel] CRAN Package error

2017-11-30 Thread Andrew Holding

Hi all,

I’m trying to upload a new version of my package and it was automatically
bounced because of the following warnings:

Warning: namespace 'BiocFileCache' is not available and has been replaced

Warning: namespace 'AnnotationFilter' is not available and has been replaced

Warning: namespace 'Organism.dplyr' is not available and has been replaced


Theses all seem to be related to the bioconductor annotation in one of the
loaded packages. I know the new Bioconductor on devel is unstable but I
thought I should check before suggesting the pretest rejection was a false
positive to see if there was a resolution.

Cheers,

Andy
-- 
Dr Andrew Holding
Fellow of Biochemistry / Senior Research Associate
Downing College / Cancer Research UK Cambridge Institute
CRUK CI: 01223 769696
Mobile: 07595 666459

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Data package timeouts

2017-11-30 Thread Martin Morgan


On 11/30/2017 06:05 AM, Mike Smith wrote:

Thanks for the speedy response Sean.  I'll switch back to the version using
a file name shortly.


Is there a use case for BiocFileCache in here -- check if the file is in 
the cache bfcquery(), if so, check whether it needs updating 
bfcneedsupdate() and perhaps bfcupdate() ? this might make the overall 
download process more robust, and would certainly save on build time.


Martin



Cheers,
Mike

On 30 November 2017 at 11:20, Sean Davis  wrote:


Thanks for the report, Mike.

The problem was (specifically) in parsing a GSEMatrix file using a
filename. This should be fixed in versions 2.46.10 (release) and 2.47.12
(devel).

Sean


On Thu, Nov 30, 2017 at 4:09 AM, Mike Smith  wrote:


Hi Mike,

I was experiencing similar problems with the BeadArrayUseCases vignette,
where using getGEO() from GEOquery was getting stuck in a (seemingly)
infinite loop processing a GSE series matrix file.  It looks like both of
your examples try to do this too, so I suspect it's a similar issue.  I
think the format of those files has changed recently and it seems to be
causing a fair few issues with GEOquery.

I temporarily settled a solution by getting querying GEO directly rather
than using a local file, but it would be nice to get it back working as
intended.

Mike

On 29 November 2017 at 18:56, Michael Love 
wrote:


I got simultaneous timeout notices for 'airway' and 'parathyroidSE' on
both release and devel machines (release was fine leading up to the
Bioc release).

Not sure what's the issue, I haven't changed these packages in a
while. I checked these out and these both build fine and in ~30s on my
machine (devel branch).

Here are the reports for release:

http://bioconductor.org/checkResults/release/data-
experiment-LATEST/airway/malbec1-buildsrc.html
http://bioconductor.org/checkResults/release/data-experiment-LATEST/
parathyroidSE/malbec1-buildsrc.html

The vignettes are here:

http://bioconductor.org/packages/3.6/data/experiment/
vignettes/airway/inst/doc/airway.html
http://bioconductor.org/packages/3.6/data/experiment/
vignettes/parathyroidSE/inst/doc/parathyroidSE.pdf

best,
Mike

___
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





--
Sean Davis, MD, PhD
Center for Cancer Research
National Cancer Institute
National Institutes of Health
Bethesda, MD 20892
https://seandavi.github.io/
https://twitter.com/seandavis12



[[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] Data package timeouts

2017-11-30 Thread Sean Davis

On Thu, Nov 30, 2017 at 6:05 AM, Mike Smith  wrote:

> Thanks for the speedy response Sean.  I'll switch back to the version
> using a file name shortly.
>

No problem. Let me know if it does not work as expected.

Sean



>
> Cheers,
> Mike
>
> On 30 November 2017 at 11:20, Sean Davis  wrote:
>
>> Thanks for the report, Mike.
>>
>> The problem was (specifically) in parsing a GSEMatrix file using a
>> filename. This should be fixed in versions 2.46.10 (release) and 2.47.12
>> (devel).
>>
>> Sean
>>
>>
>> On Thu, Nov 30, 2017 at 4:09 AM, Mike Smith  wrote:
>>
>>> Hi Mike,
>>>
>>> I was experiencing similar problems with the BeadArrayUseCases vignette,
>>> where using getGEO() from GEOquery was getting stuck in a (seemingly)
>>> infinite loop processing a GSE series matrix file.  It looks like both of
>>> your examples try to do this too, so I suspect it's a similar issue.  I
>>> think the format of those files has changed recently and it seems to be
>>> causing a fair few issues with GEOquery.
>>>
>>> I temporarily settled a solution by getting querying GEO directly rather
>>> than using a local file, but it would be nice to get it back working as
>>> intended.
>>>
>>> Mike
>>>
>>> On 29 November 2017 at 18:56, Michael Love 
>>> wrote:
>>>
>>> > I got simultaneous timeout notices for 'airway' and 'parathyroidSE' on
>>> > both release and devel machines (release was fine leading up to the
>>> > Bioc release).
>>> >
>>> > Not sure what's the issue, I haven't changed these packages in a
>>> > while. I checked these out and these both build fine and in ~30s on my
>>> > machine (devel branch).
>>> >
>>> > Here are the reports for release:
>>> >
>>> > http://bioconductor.org/checkResults/release/data-
>>> > experiment-LATEST/airway/malbec1-buildsrc.html
>>> > http://bioconductor.org/checkResults/release/data-experiment-LATEST/
>>> > parathyroidSE/malbec1-buildsrc.html
>>> >
>>> > The vignettes are here:
>>> >
>>> > http://bioconductor.org/packages/3.6/data/experiment/
>>> > vignettes/airway/inst/doc/airway.html
>>> > http://bioconductor.org/packages/3.6/data/experiment/
>>> > vignettes/parathyroidSE/inst/doc/parathyroidSE.pdf
>>> >
>>> > best,
>>> > Mike
>>> >
>>> > ___
>>> > 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
>>>
>>
>>
>>
>> --
>> Sean Davis, MD, PhD
>> Center for Cancer Research
>> National Cancer Institute
>> National Institutes of Health
>> Bethesda, MD 20892
>> https://seandavi.github.io/
>> https://twitter.com/seandavis12
>>
>
>


-- 
Sean Davis, MD, PhD
Center for Cancer Research
National Cancer Institute
National Institutes of Health
Bethesda, MD 20892
https://seandavi.github.io/
https://twitter.com/seandavis12

[[alternative HTML version deleted]]

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

Re: [Rd] binary form of is() contradicts its unary form