Re: [Bioc-devel] Something about time out errors

2017-03-27 Thread Dan Tenenbaum


- Original Message -
> From: "Martin Morgan" 
> To: "Rainer Johannes" 
> Cc: "Aimin Yan" , "bioc-devel" 
> 
> Sent: Monday, March 27, 2017 12:29:49 PM
> Subject: Re: [Bioc-devel] Something about time out errors

> On 03/27/2017 12:57 PM, Rainer Johannes wrote:
>> Do you have code fetching data from web resources? I also sometimes get 
>> timeout
>> errors on ensembldb and I guess it's because in some unit tests I'm fetching
>> data from the ensembl ftp server.
>>
>
> Testing web resources is a pretty interesting topic. It doesn't really
> make sense to spend a lot of time downloading a large amount of data,
> but rather to focus the test on the existence of the endpoint, and the
> returned data type. It seems like these tests can be fast and
> light-weight. One approach (for static resources) might ask the web
> server for a last-modified or entity tag (ETag) value, and compare that
> to a manually maintained last-known-good exemplar.
>
> Unit tests for parsing the data into R and processing the data once in R
> are really separate from the web resource, and should probably be
> isolated from tests of the web resource itself.
>
> The approach on this page
>
>   http://bioconductor.org/developers/how-to/web-query/
>
> especially use of timeout(), might be a reasonable way to implement
> this; also BiocFileCache is now available and provides appropriate
> functionality (although looking I see that it doesn't currently support
> time-outs -- but it's better to fix this in the one location rather than
> in many different locations).
>

Another approach is to write a function that simply returns the web resource, 
and then 'mock' that function in your unit tests, to have it return an expected 
result. This keeps the scope of your unit tests appropriate (i.e. you are only 
testing your own code, you're not testing if some resource is available on a 
remote server or if the internet is working that day). 

Look at ?with_mock in the `testthat` package for more information. 

Dan



> Martin
>
>> jo
>>
>>> On 27 Mar 2017, at 18:37, Martin Morgan  
>>> wrote:
>>>
>>> On 03/27/2017 12:22 PM, Aimin Yan wrote:
 I am submitting a R package to bioconductor. but I got time out errors when
 I performed R CMD check.


 Is there a possible way that I can set up time to allow more time for R CMD
 check? Or I have to use examples that they do not cost large time.
>>>
>>> Submitted packages need to conform to package guidelines for space and time
>>>
>>>  http://bioconductor.org/developers/package-guidelines/#correctness
>>>
>>> so you'll need to develop realistic examples requiring modest resources.
>>>
>>> Often long-running examples result from inefficient code, so it is 
>>> worth-while
>>> to profile your code to discover where the most time is spent, and seek
>>> efficient implementations for that section of code either through better 
>>> use of
>>> vectorization or more sophisticated algorithms.
>>>
>>> Martin
>>>


 Thank you for your help

 Aimin

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

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


Re: [Bioc-devel] Something about time out errors

2017-03-27 Thread Martin Morgan

On 03/27/2017 12:57 PM, Rainer Johannes wrote:

Do you have code fetching data from web resources? I also sometimes get timeout 
errors on ensembldb and I guess it's because in some unit tests I'm fetching 
data from the ensembl ftp server.



Testing web resources is a pretty interesting topic. It doesn't really 
make sense to spend a lot of time downloading a large amount of data, 
but rather to focus the test on the existence of the endpoint, and the 
returned data type. It seems like these tests can be fast and 
light-weight. One approach (for static resources) might ask the web 
server for a last-modified or entity tag (ETag) value, and compare that 
to a manually maintained last-known-good exemplar.


Unit tests for parsing the data into R and processing the data once in R 
are really separate from the web resource, and should probably be 
isolated from tests of the web resource itself.


The approach on this page

  http://bioconductor.org/developers/how-to/web-query/

especially use of timeout(), might be a reasonable way to implement 
this; also BiocFileCache is now available and provides appropriate 
functionality (although looking I see that it doesn't currently support 
time-outs -- but it's better to fix this in the one location rather than 
in many different locations).


Martin


jo


On 27 Mar 2017, at 18:37, Martin Morgan  wrote:

On 03/27/2017 12:22 PM, Aimin Yan wrote:

I am submitting a R package to bioconductor. but I got time out errors when
I performed R CMD check.


Is there a possible way that I can set up time to allow more time for R CMD
check? Or I have to use examples that they do not cost large time.


Submitted packages need to conform to package guidelines for space and time

 http://bioconductor.org/developers/package-guidelines/#correctness

so you'll need to develop realistic examples requiring modest resources.

Often long-running examples result from inefficient code, so it is worth-while 
to profile your code to discover where the most time is spent, and seek 
efficient implementations for that section of code either through better use of 
vectorization or more sophisticated algorithms.

Martin




Thank you for your help

Aimin

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





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] Cannot find SummarizedExperiment's function assays()

2017-03-27 Thread Michael Lawrence
Actually, I don't see where the package itself is loaded in the
vignette. If it were, this error would not occur.

Unsurprisingly, I get this when trying to run the vignette code:

Warning message:
In data(list = ds) : data set ‘pathprintSummarizedGEOData’ not found

I noticed that pathprintGEOData just provides compressed_result, not
the "pathprintSummarizedGEOData" so I'm not sure where that lives now.
You might also consider turning off lazy data and using a datalist
file for that package since the file is somewhat large.

I also think that the datalist file for pathprint is out of date.

Michael

On Mon, Mar 27, 2017 at 11:26 AM, Marcel Ramos
 wrote:
> Hi Sokratis,
>
> You can resolve this issue by moving `SummarizedExperiment` to the
> Suggests field and
>
> including a `library(SummarizedExperiment)` call in your vignette.
>
> Best regards,
>
> Marcel
>
>
> On Mon, Mar 27, 2017 at 11:09 AM Sokratis Kariotis
> mailto:s.kario...@sheffield.ac.uk>> wrote:
>
> Hey,
>
> I have submitted the package pathprintGEOData, which got accepted,
> but the
> build/check report is now producing the following error:
>
>
>
> *Error: processing vignette 'usingPathprintGEOData.Rnw' failed with
> diagnostics:  chunk 1 Error in assays(result) : could not find function
> "assays"*
>
> *assays *is a function from the SummarizedExperiment package which I
> have
> added on my Depends in DESCRIPTION. This error was not present during
> building/checking before this package was accepted. Besides adding
> SummarizedExperiment
> to my Imports what else might be responsible for that error?
>
> Thank you for any help on the matter!
>
> -Sokratis
>
>  [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
>
> --
> Marcel Ramos
> Bioconductor Core Team Member
> Roswell Park Cancer Institute
>
>
>
> This email message may contain legally privileged and/or...{{dropped:4}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] Cannot find SummarizedExperiment's function assays()

2017-03-27 Thread Marcel Ramos
Hi Sokratis,

You can resolve this issue by moving `SummarizedExperiment` to the 
Suggests field and

including a `library(SummarizedExperiment)` call in your vignette.

Best regards,

Marcel


On Mon, Mar 27, 2017 at 11:09 AM Sokratis Kariotis 
mailto:s.kario...@sheffield.ac.uk>> wrote:

Hey,

I have submitted the package pathprintGEOData, which got accepted,
but the
build/check report is now producing the following error:



*Error: processing vignette 'usingPathprintGEOData.Rnw' failed with
diagnostics:  chunk 1 Error in assays(result) : could not find function
"assays"*

*assays *is a function from the SummarizedExperiment package which I
have
added on my Depends in DESCRIPTION. This error was not present during
building/checking before this package was accepted. Besides adding
SummarizedExperiment
to my Imports what else might be responsible for that error?

Thank you for any help on the matter!

-Sokratis

 [[alternative HTML version deleted]]

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


-- 
Marcel Ramos
Bioconductor Core Team Member
Roswell Park Cancer Institute



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

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


Re: [Bioc-devel] Something about time out errors

2017-03-27 Thread Rainer Johannes
Do you have code fetching data from web resources? I also sometimes get timeout 
errors on ensembldb and I guess it's because in some unit tests I'm fetching 
data from the ensembl ftp server.

jo

> On 27 Mar 2017, at 18:37, Martin Morgan  wrote:
> 
> On 03/27/2017 12:22 PM, Aimin Yan wrote:
>> I am submitting a R package to bioconductor. but I got time out errors when
>> I performed R CMD check.
>> 
>> 
>> Is there a possible way that I can set up time to allow more time for R CMD
>> check? Or I have to use examples that they do not cost large time.
> 
> Submitted packages need to conform to package guidelines for space and time
> 
>  http://bioconductor.org/developers/package-guidelines/#correctness
> 
> so you'll need to develop realistic examples requiring modest resources.
> 
> Often long-running examples result from inefficient code, so it is 
> worth-while to profile your code to discover where the most time is spent, 
> and seek efficient implementations for that section of code either through 
> better use of vectorization or more sophisticated algorithms.
> 
> Martin
> 
>> 
>> 
>> Thank you for your help
>> 
>> Aimin
>> 
>>  [[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

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


Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'

2017-03-27 Thread Michael Lawrence
I committed a fix into R trunk with a regression test.

On Mon, Mar 27, 2017 at 8:41 AM, Michael Lawrence  wrote:
> My bad guys, I'll fix when I get to work.
>
> On Mon, Mar 27, 2017 at 3:59 AM, Martin Morgan
>  wrote:
>> On 03/22/2017 01:12 PM, Hervé Pagès wrote:
>>>
>>> Hi Martin,
>>>
>>> On 03/22/2017 03:17 AM, Martin Maechler wrote:
>
> Andrzej Oleś 
> on Wed, 22 Mar 2017 10:29:57 +0100 writes:


 > Just for the record, on R-3.3.2 Herve's code fails with the
 following error:
 > Error in x[TRUE] <- new("A") :
 > incompatible types (from S4 to logical) in subassignment type fix

 yes, (of course) and I would be interested in a small
 reproducible example which uses _valid_ code.
>>>
>>>
>>> Looks like before performing the subassignment itself, [<- first tries
>>> to coerce the RHS to the "mode" of the LHS by calling as.vector() on the
>>> former. So if we define an as.vector S3 method for A objects:
>>>
>>>   setClass("A", representation(stuff="numeric"))
>>>   as.vector.A <- function (x, mode="any") x@stuff
>>>   a <- new("A", stuff=c(3.5, 0.1))
>>>   x <- numeric(10)
>>>   x[3:4] <- a
>>
>>
>> The relevant stack trace is
>>
>>   * frame #0: 0x00010dded77a libR.dylib`R_has_methods(op=)
>> + 74 at objects.c:1415
>> frame #1: 0x00010ddaabf4
>> libR.dylib`Rf_DispatchOrEval(call=0x7fcea36f68a8, op=0x7fcea201a178,
>> generic=0x00010df0a185, args=, rho=0x7fcea2053318,
>> ans=0x7fff51f60c48, dropmissing=, argsevald=1) + 404 at
>> eval.c:3150
>> frame #2: 0x00010de4e658 libR.dylib`SubassignTypeFix [inlined]
>> dispatch_asvector(x=, call=0x7fcea36f68a8,
>> rho=0x7fcea2053318) + 295 at subassign.c:283
>>
>>
>> The segfault is at objects.c:1415
>>
>> offset = PRIMOFFSET(op);
>> if(offset > curMaxOffset || prim_methods[offset] == NO_METHODS
>>|| prim_methods[offset] == SUPPRESSED)
>>
>> where offset is negative and prim_methods[offset] fails.
>>
>> (lldb) p *op
>> (SEXPREC) $8 = {
>>   sxpinfo = (type = 0, obj = 0, named = 2, gp = 0, mark = 1, debug = 0,
>> trace = 0, spare = 0, gcgen = 1, gccls = 0)
>>   attrib = 0x7fcea201a178
>>   gengc_next_node = 0x7fcea21874e8
>>   gengc_prev_node = 0x7fcea2019ff0
>>   u = {
>> primsxp = (offset = -1576951432)
>> symsxp = {
>>
>>
>> 'op' is assigned from subassign.c:287, op = R_Primitive("as.vector")
>>
>> static Rboolean dispatch_asvector(SEXP *x, SEXP call, SEXP rho) {
>> static SEXP op = NULL;
>> SEXP args;
>> Rboolean ans;
>> if (op == NULL)
>> op = R_Primitive("as.vector");
>> PROTECT(args = list2(*x, mkString("any")));
>> ans = DispatchOrEval(call, op, "as.vector", args, rho, x, 0, 1);
>> UNPROTECT(1);
>> return ans;
>> }
>>
>> But as.vector is not a primitive, so gets R_NilValue. This is passed to
>> DispatchOrEval, and then to R_has_methods.
>>
>> It seems like dispatch_asvector() was introduced by
>>
>> $ svn log -c69747
>> 
>> r69747 | lawrence | 2015-12-09 09:04:56 -0500 (Wed, 09 Dec 2015) | 3 lines
>>
>> subassignment of an S4 value into an atomic vector coerces the value
>> with as.vector
>>
>> 
>>
>> So maybe Michael can tell us about his thinking here.
>>
>> Also, should R_has_methods be robust to R_NilValue? And R_NilValue
>> explicitly zero it's data?
>>
>> Martin
>>
>>
>>
>>>
>>> then the code is now valid and we still get the segfault on Mac.
>>>
>>> I didn't define as.vector.A in my original minimalist reproducible
>>> code in order to keep it as simple as possible.
>>>
>>> H.
>>>
>>>
 We have seen such examples with something (more complicated
 than, but basically like)

   df <- data.frame(x=1:5, y=5:1, m=matrix(-pi*1:30, 5,6))
   M <- Matrix::Matrix(exp(0:3),2)
   df[1:2,1:2] <- M

 which actually calls `[<-`, and then `[<-.data.frame`  and
 always works for me but does seg.fault (in the CRAN checks of
 package FastImputation (on 3 of the dozen platforms,

 https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_web_checks_check-5Fresults-5FFastImputation.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY&s=zUahQYlBHRwNf6lPnSA1515Rm-iL5ffQI7hUcDW-JkE&e=


 one of them is


 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.r-2Dproject.org_nosvn_R.check_r-2Ddevel-2Dmacos-2Dx86-5F64-2Dclang_FastImputation-2D00check.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY&s=Z7LkVlUzmdmhqxGNFl4LuMVxYwQQGHSV7KdpKCJu12k&e=


 I strongly suspect this is the same bug as yours, but for a case
 where the correct behavior is *not* giving an error.

 I

Re: [Bioc-devel] Something about time out errors

2017-03-27 Thread Martin Morgan

On 03/27/2017 12:22 PM, Aimin Yan wrote:

I am submitting a R package to bioconductor. but I got time out errors when
I performed R CMD check.


Is there a possible way that I can set up time to allow more time for R CMD
check? Or I have to use examples that they do not cost large time.


Submitted packages need to conform to package guidelines for space and time

  http://bioconductor.org/developers/package-guidelines/#correctness

so you'll need to develop realistic examples requiring modest resources.

Often long-running examples result from inefficient code, so it is 
worth-while to profile your code to discover where the most time is 
spent, and seek efficient implementations for that section of code 
either through better use of vectorization or more sophisticated algorithms.


Martin




Thank you for your help

Aimin

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


[Bioc-devel] Something about time out errors

2017-03-27 Thread Aimin Yan
I am submitting a R package to bioconductor. but I got time out errors when
I performed R CMD check.


Is there a possible way that I can set up time to allow more time for R CMD
check? Or I have to use examples that they do not cost large time.


Thank you for your help

Aimin

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'

2017-03-27 Thread Michael Lawrence
My bad guys, I'll fix when I get to work.

On Mon, Mar 27, 2017 at 3:59 AM, Martin Morgan
 wrote:
> On 03/22/2017 01:12 PM, Hervé Pagès wrote:
>>
>> Hi Martin,
>>
>> On 03/22/2017 03:17 AM, Martin Maechler wrote:

 Andrzej Oleś 
 on Wed, 22 Mar 2017 10:29:57 +0100 writes:
>>>
>>>
>>> > Just for the record, on R-3.3.2 Herve's code fails with the
>>> following error:
>>> > Error in x[TRUE] <- new("A") :
>>> > incompatible types (from S4 to logical) in subassignment type fix
>>>
>>> yes, (of course) and I would be interested in a small
>>> reproducible example which uses _valid_ code.
>>
>>
>> Looks like before performing the subassignment itself, [<- first tries
>> to coerce the RHS to the "mode" of the LHS by calling as.vector() on the
>> former. So if we define an as.vector S3 method for A objects:
>>
>>   setClass("A", representation(stuff="numeric"))
>>   as.vector.A <- function (x, mode="any") x@stuff
>>   a <- new("A", stuff=c(3.5, 0.1))
>>   x <- numeric(10)
>>   x[3:4] <- a
>
>
> The relevant stack trace is
>
>   * frame #0: 0x00010dded77a libR.dylib`R_has_methods(op=)
> + 74 at objects.c:1415
> frame #1: 0x00010ddaabf4
> libR.dylib`Rf_DispatchOrEval(call=0x7fcea36f68a8, op=0x7fcea201a178,
> generic=0x00010df0a185, args=, rho=0x7fcea2053318,
> ans=0x7fff51f60c48, dropmissing=, argsevald=1) + 404 at
> eval.c:3150
> frame #2: 0x00010de4e658 libR.dylib`SubassignTypeFix [inlined]
> dispatch_asvector(x=, call=0x7fcea36f68a8,
> rho=0x7fcea2053318) + 295 at subassign.c:283
>
>
> The segfault is at objects.c:1415
>
> offset = PRIMOFFSET(op);
> if(offset > curMaxOffset || prim_methods[offset] == NO_METHODS
>|| prim_methods[offset] == SUPPRESSED)
>
> where offset is negative and prim_methods[offset] fails.
>
> (lldb) p *op
> (SEXPREC) $8 = {
>   sxpinfo = (type = 0, obj = 0, named = 2, gp = 0, mark = 1, debug = 0,
> trace = 0, spare = 0, gcgen = 1, gccls = 0)
>   attrib = 0x7fcea201a178
>   gengc_next_node = 0x7fcea21874e8
>   gengc_prev_node = 0x7fcea2019ff0
>   u = {
> primsxp = (offset = -1576951432)
> symsxp = {
>
>
> 'op' is assigned from subassign.c:287, op = R_Primitive("as.vector")
>
> static Rboolean dispatch_asvector(SEXP *x, SEXP call, SEXP rho) {
> static SEXP op = NULL;
> SEXP args;
> Rboolean ans;
> if (op == NULL)
> op = R_Primitive("as.vector");
> PROTECT(args = list2(*x, mkString("any")));
> ans = DispatchOrEval(call, op, "as.vector", args, rho, x, 0, 1);
> UNPROTECT(1);
> return ans;
> }
>
> But as.vector is not a primitive, so gets R_NilValue. This is passed to
> DispatchOrEval, and then to R_has_methods.
>
> It seems like dispatch_asvector() was introduced by
>
> $ svn log -c69747
> 
> r69747 | lawrence | 2015-12-09 09:04:56 -0500 (Wed, 09 Dec 2015) | 3 lines
>
> subassignment of an S4 value into an atomic vector coerces the value
> with as.vector
>
> 
>
> So maybe Michael can tell us about his thinking here.
>
> Also, should R_has_methods be robust to R_NilValue? And R_NilValue
> explicitly zero it's data?
>
> Martin
>
>
>
>>
>> then the code is now valid and we still get the segfault on Mac.
>>
>> I didn't define as.vector.A in my original minimalist reproducible
>> code in order to keep it as simple as possible.
>>
>> H.
>>
>>
>>> We have seen such examples with something (more complicated
>>> than, but basically like)
>>>
>>>   df <- data.frame(x=1:5, y=5:1, m=matrix(-pi*1:30, 5,6))
>>>   M <- Matrix::Matrix(exp(0:3),2)
>>>   df[1:2,1:2] <- M
>>>
>>> which actually calls `[<-`, and then `[<-.data.frame`  and
>>> always works for me but does seg.fault (in the CRAN checks of
>>> package FastImputation (on 3 of the dozen platforms,
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_web_checks_check-5Fresults-5FFastImputation.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY&s=zUahQYlBHRwNf6lPnSA1515Rm-iL5ffQI7hUcDW-JkE&e=
>>>
>>>
>>> one of them is
>>>
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.r-2Dproject.org_nosvn_R.check_r-2Ddevel-2Dmacos-2Dx86-5F64-2Dclang_FastImputation-2D00check.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY&s=Z7LkVlUzmdmhqxGNFl4LuMVxYwQQGHSV7KdpKCJu12k&e=
>>>
>>>
>>> I strongly suspect this is the same bug as yours, but for a case
>>> where the correct behavior is *not* giving an error.
>>>
>>> I have also written and shown  Herve's example  to the R-core team.
>>>
>>> Unfortunately, I have no platform where I can trigger the bug.
>>> Martin
>>>
>>>
>>>
>>> > Cheers,
>>> > Andrzej
>>>
>>>
>>>
>>> > On Wed, Mar 22, 2017 at 1:28 AM, Mar

[Bioc-devel] Cannot find SummarizedExperiment's function assays()

2017-03-27 Thread Sokratis Kariotis
Hey,

I have submitted the package pathprintGEOData, which got accepted, but the
build/check report is now producing the following error:



*Error: processing vignette 'usingPathprintGEOData.Rnw' failed with
diagnostics:  chunk 1 Error in assays(result) : could not find function
"assays"*

*assays *is a function from the SummarizedExperiment package which I have
added on my Depends in DESCRIPTION. This error was not present during
building/checking before this package was accepted. Besides adding
SummarizedExperiment
to my Imports what else might be responsible for that error?

Thank you for any help on the matter!

-Sokratis

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'

2017-03-27 Thread Martin Morgan

On 03/22/2017 01:12 PM, Hervé Pagès wrote:

Hi Martin,

On 03/22/2017 03:17 AM, Martin Maechler wrote:

Andrzej Oleś 
on Wed, 22 Mar 2017 10:29:57 +0100 writes:


> Just for the record, on R-3.3.2 Herve's code fails with the
following error:
> Error in x[TRUE] <- new("A") :
> incompatible types (from S4 to logical) in subassignment type fix

yes, (of course) and I would be interested in a small
reproducible example which uses _valid_ code.


Looks like before performing the subassignment itself, [<- first tries
to coerce the RHS to the "mode" of the LHS by calling as.vector() on the
former. So if we define an as.vector S3 method for A objects:

  setClass("A", representation(stuff="numeric"))
  as.vector.A <- function (x, mode="any") x@stuff
  a <- new("A", stuff=c(3.5, 0.1))
  x <- numeric(10)
  x[3:4] <- a


The relevant stack trace is

  * frame #0: 0x00010dded77a 
libR.dylib`R_has_methods(op=) + 74 at objects.c:1415
frame #1: 0x00010ddaabf4 
libR.dylib`Rf_DispatchOrEval(call=0x7fcea36f68a8, 
op=0x7fcea201a178, generic=0x00010df0a185, args=, 
rho=0x7fcea2053318, ans=0x7fff51f60c48, 
dropmissing=, argsevald=1) + 404 at eval.c:3150
frame #2: 0x00010de4e658 libR.dylib`SubassignTypeFix [inlined] 
dispatch_asvector(x=, call=0x7fcea36f68a8, 
rho=0x7fcea2053318) + 295 at subassign.c:283



The segfault is at objects.c:1415

offset = PRIMOFFSET(op);
if(offset > curMaxOffset || prim_methods[offset] == NO_METHODS
   || prim_methods[offset] == SUPPRESSED)

where offset is negative and prim_methods[offset] fails.

(lldb) p *op
(SEXPREC) $8 = {
  sxpinfo = (type = 0, obj = 0, named = 2, gp = 0, mark = 1, debug = 0, 
trace = 0, spare = 0, gcgen = 1, gccls = 0)

  attrib = 0x7fcea201a178
  gengc_next_node = 0x7fcea21874e8
  gengc_prev_node = 0x7fcea2019ff0
  u = {
primsxp = (offset = -1576951432)
symsxp = {


'op' is assigned from subassign.c:287, op = R_Primitive("as.vector")

static Rboolean dispatch_asvector(SEXP *x, SEXP call, SEXP rho) {
static SEXP op = NULL;
SEXP args;
Rboolean ans;
if (op == NULL)
op = R_Primitive("as.vector");
PROTECT(args = list2(*x, mkString("any")));
ans = DispatchOrEval(call, op, "as.vector", args, rho, x, 0, 1);
UNPROTECT(1);
return ans;
}

But as.vector is not a primitive, so gets R_NilValue. This is passed to 
DispatchOrEval, and then to R_has_methods.


It seems like dispatch_asvector() was introduced by

$ svn log -c69747

r69747 | lawrence | 2015-12-09 09:04:56 -0500 (Wed, 09 Dec 2015) | 3 lines

subassignment of an S4 value into an atomic vector coerces the value
with as.vector



So maybe Michael can tell us about his thinking here.

Also, should R_has_methods be robust to R_NilValue? And R_NilValue 
explicitly zero it's data?


Martin




then the code is now valid and we still get the segfault on Mac.

I didn't define as.vector.A in my original minimalist reproducible
code in order to keep it as simple as possible.

H.



We have seen such examples with something (more complicated
than, but basically like)

  df <- data.frame(x=1:5, y=5:1, m=matrix(-pi*1:30, 5,6))
  M <- Matrix::Matrix(exp(0:3),2)
  df[1:2,1:2] <- M

which actually calls `[<-`, and then `[<-.data.frame`  and
always works for me but does seg.fault (in the CRAN checks of
package FastImputation (on 3 of the dozen platforms,
https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_web_checks_check-5Fresults-5FFastImputation.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY&s=zUahQYlBHRwNf6lPnSA1515Rm-iL5ffQI7hUcDW-JkE&e=


one of them is

 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.r-2Dproject.org_nosvn_R.check_r-2Ddevel-2Dmacos-2Dx86-5F64-2Dclang_FastImputation-2D00check.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY&s=Z7LkVlUzmdmhqxGNFl4LuMVxYwQQGHSV7KdpKCJu12k&e=


I strongly suspect this is the same bug as yours, but for a case
where the correct behavior is *not* giving an error.

I have also written and shown  Herve's example  to the R-core team.

Unfortunately, I have no platform where I can trigger the bug.
Martin



> Cheers,
> Andrzej



> On Wed, Mar 22, 2017 at 1:28 AM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:

>> On 03/21/2017 08:21 PM, Hervé Pagès wrote:
>>
>>> Hi Leonardo,
>>>
>>> Thanks for hunting down and isolating that bug! I tried to
simplify
>>> your code even more and was able to get a segfault with just:
>>>
>>> setClass("A", representation(stuff="numeric"))
>>> x <- logical(10)
>>> x[TRUE] <- new("A")
>>>
>>> I get the segfault about 50% of th