[Bioc-devel] sorry, no build report for BioC 3.10 today
Dear Bioconductor developers, Some issue with the software builds prevents us from having a build report today for BioC 3.10. Things should get back to normal tomorrow. Sorry for the inconvenience. Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Getting error in rbindlist
This is (was) a bug in data.table that is similar to one which was
putatively closed. Recommend you update to the latest version and if the
problem persists reopen the issue here
https://github.com/Rdatatable/data.table/issues/3032
This mailing list is for R bugs, which this isn’t. R Core can no more help
you with this bug than with a paper jam in your printer.
Hth
On Sat, 2 Nov 2019 at 3:14 am, Anshul Saravgi <
anshul.sara...@o9solutions.com> wrote:
> Hi All
>
> Can you help me understand the meaning of the below error message then I
> will try to figure out what is going wrong:
>
> *Input Code:*
> > q <- lapply(
> + lapply(split(lctolc2, lctolc2$Item), function(x) graph.data.frame(x[,
> 2:3])),
> + function(x) lapply(
> + V(x)[degree(x, mode = "in") == 0],
> + function(s) all_simple_paths(x, from = s,
> + to = V(x)[degree(x, mode = "out") == 0])
> %>%
> + lapply(
> + function(y) as.data.table(t(names(y))) %>% setnames(paste0("LC",
> seq_along(.)))
> + ) %>%
> + rbindlist(use.names=TRUE,fill = TRUE)
> + ) %>% rbindlist(use.names=TRUE,fill = TRUE)
> + ) %>% rbindlist(use.names=TRUE,fill = TRUE, idcol = "Item")
>
> *Error message:*
> Error in rbindlist(., use.names = TRUE, fill = TRUE, idcol = "Item") :
> attempt to set index 8424/8424 in SET_STRING_ELT
> In addition: There were 50 or more warnings (use warnings() to see the
> first 50)
>
> I am not understanding what is in SET_STRING_ELT which it is trying to
> throw an error.
> Please help me
>
>
> *Regards,*
>
> *Anshul Saravgi*
>
> Consulting
> m: 7757030307
>
>
Re: [Rd] Getting error in rbindlist
On 11/1/19 5:24 PM, Anshul Saravgi wrote:
> Thanks Tomas for identifying the bug.
>
> *How to resolve this bug? Can you please help me here?*
I would recommend you first try to create a complete reproducible
example (the code below is just a snippet). Then try to minimize it -
make it do as little as possible but still trigger the bug. Then try to
reduce the number of packages used. If you ended up with code that used
only base R (no packages outside R distribution), then submit again to
R-devel (it is a likely bug in R itself, so if you can't trace the bug
down yourself, someone here would do it). Base R would not let any user
code write beyond the end of the string, so if you can reproduce this in
base R, it is definitely a bug.
If you end up with code that still uses some contributed packages from
these below, you need to find out/guess which of them is responsible and
try to ask for help the maintainer of that package. It would more likely
be a bug in some of those packages, but in principle it could also be a
problem in how you are using them.
If you haven't done that already, it may be useful to update your
packages - just in case the problem has already been resolved.
Best
Tomas
> *I am using the below code:*
> library(plyr)
> library(dplyr)
> library(tidyr)
> library(igraph)
> library(magrittr)
> library(reshape2)
> library(tibble)
>
> colnames(lctolc3) <- c("Item","LC","ToLC")
>
> bodlane3 <- lapply(
> lapply(split(lctolc3, lctolc3$Item), function(x)
> graph.data.frame(x[, 2:3])),
> function(x) lapply(
> V(x)[degree(x, mode = "in") == 0],
> function(s) all_simple_paths(x, from = s,
> to = V(x)[degree(x, mode = "out") ==
> 0]) %>%
> lapply(
> function(y) as.data.table(t(names(y))) %>%
> setnames(paste0("LC", seq_along(.)))
> ) %>%
> rbindlist(use.names=TRUE,fill = TRUE)
> ) %>% rbindlist(use.names=TRUE,fill = TRUE)
> ) %>% rbindlist(use.names=TRUE,fill = TRUE, idcol = "Item")
>
>
> *Regards,*
>
> *Anshul Saravgi*
>
> Consulting
>
> m: 7757030307
>
>
Re: [Bioc-devel] merge github + bioc versions
To push to your github branch git push origin master To push to the Bioconductor git server and have changes active in Bioconductor devel git push upstream master The upstream master branch is equivalent to whatever the current devel branch is on Bioconductor (in this case Bioc 3.11). Pushing to the master branch will have no effect on the Bioc 3.10 (you would need to push to upstream RELEASE_3_10 in order to make changes to the Bioconductor Release 3.10 branch) Hope this helps. Lori Shepherd Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel on behalf of Venu Thatikonda Sent: Friday, November 1, 2019 9:49 AM To: bioc-devel Subject: [Bioc-devel] merge github + bioc versions Hello all, I am a bit confused by how git works with bioc ecosystem. I am following this guide to sync my github + bioc repos (for the first time). https://bioconductor.org/developers/how-to/git/sync-existing-repositories/ After step-6, I see following branches * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/upstream/RELEASE_3_10 remotes/upstream/master So, if I add new features to the package and commit & push to master branch, does it affect current version that is released in bioc10? Or do they go to bioc11 devel branch and generate build reports, without affecting the package in bioc10? Should I create a branch RELEASE_3_11 and commit all changes to this branch? I want the changes to be released in bioc11 and do not want to affect bioc10 version. Thank you & have a nice day! -- Best regards Venu Thatikonda https://itsvenu.github.io/ [[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 confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Getting error in rbindlist
On 11/1/19 1:11 PM, Anshul Saravgi wrote:
Hi All
Can you help me understand the meaning of the below error message then I
will try to figure out what is going wrong:
*Input Code:*
bodlane2 <- lapply(
+ lapply(split(lctolc2, lctolc2$Item), function(x) graph.data.frame(x[,
2:3])),
+ function(x) lapply(
+ V(x)[degree(x, mode = "in") == 0],
+ function(s) all_simple_paths(x, from = s,
+ to = V(x)[degree(x, mode = "out") == 0])
%>%
+ lapply(
+ function(y) as.data.table(t(names(y))) %>% setnames(paste0("LC",
seq_along(.)))
+ ) %>%
+ rbindlist(use.names=TRUE,fill = TRUE)
+ ) %>% rbindlist(use.names=TRUE,fill = TRUE)
+ ) %>% rbindlist(use.names=TRUE,fill = TRUE, idcol = "Item")
*Error message:*
Error in rbindlist(., use.names = TRUE, fill = TRUE, idcol = "Item") :
attempt to set index 8424/8424 in SET_STRING_ELT
In addition: There were 50 or more warnings (use warnings() to see the
first 50)
I am not understanding what is in SET_STRING_ELT which it is trying to
throw an error.
Please help me
The code is trying to write beyond the end of a string vector (to an
element the vector does not have). This is typically a bug in native
code of a package.
Best
Tomas
*Regards,*
*Anshul Saravgi*
Consulting
m: 7757030307
[Rd] Getting error in rbindlist
Hi All
Can you help me understand the meaning of the below error message then I
will try to figure out what is going wrong:
*Input Code:*
> bodlane2 <- lapply(
+ lapply(split(lctolc2, lctolc2$Item), function(x) graph.data.frame(x[,
2:3])),
+ function(x) lapply(
+ V(x)[degree(x, mode = "in") == 0],
+ function(s) all_simple_paths(x, from = s,
+ to = V(x)[degree(x, mode = "out") == 0])
%>%
+ lapply(
+ function(y) as.data.table(t(names(y))) %>% setnames(paste0("LC",
seq_along(.)))
+ ) %>%
+ rbindlist(use.names=TRUE,fill = TRUE)
+ ) %>% rbindlist(use.names=TRUE,fill = TRUE)
+ ) %>% rbindlist(use.names=TRUE,fill = TRUE, idcol = "Item")
*Error message:*
Error in rbindlist(., use.names = TRUE, fill = TRUE, idcol = "Item") :
attempt to set index 8424/8424 in SET_STRING_ELT
In addition: There were 50 or more warnings (use warnings() to see the
first 50)
I am not understanding what is in SET_STRING_ELT which it is trying to
throw an error.
Please help me
*Regards,*
*Anshul Saravgi*
Consulting
m: 7757030307
Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects
Thank you all for your valuable comments.
Best,
Jan
On Fri, Nov 1, 2019 at 8:15 PM Tierney, Luke wrote:
>
> On Fri, 1 Nov 2019, Jan Gorecki wrote:
>
> > Thank you Luke.
> > That is why I don't use Rf_inherits but INHERITS which does not
> > allocate, provided in the email body.
>
> Your definition can allocate because STING_ELT can allocate.
> getAttrib can GC in general. Currently it would not GC or allocate in
> this case, but this could change.
>
> You can't assume thread-safety for calls into the R API, or any API
> for that matter, unless they are documented to be thread-safe.
>
> You would be better off using Rf_inherits as it does not make the
> assumption that you can use pointer comparisons to check for identical
> strings. CHARSXPs are almost always cached but they are not
> guaranteed to be, and the caching strategy might change in the future.
>
> Best,
>
> luke
>
> > I cannot do similarly for S4 classes, thus asking for some API for that.
> >
> > On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke wrote:
> >>
> >> On Fri, 1 Nov 2019, Jan Gorecki wrote:
> >>
> >>> Dear R developers,
> >>>
> >>> Motivated by discussion about checking inheritance of S3 and S4
> >>> objects (in head matrix/array topic) I would light to shed some light
> >>> on a minor gap about that matter in R C API.
> >>> Currently we are able to check inheritance for S3 class objects from C
> >>> in a robust way (no allocation, thread safe). This is unfortunately
> >>
> >> Your premise is not correct. Rf_inherits will not GC but it can
> >> allocate and is not thread safe.
> >>
> >> Best,
> >>
> >> luke
> >>
> >>> not possible for S4 classes. I would kindly request new function in R
> >>> C api so it can be achieved for S4 classes with no risk of allocation.
> >>> For reference mentioned functions below. Thank you.
> >>> Jan Gorecki
> >>>
> >>> // S3 inheritance
> >>> bool INHERITS(SEXP x, SEXP char_) {
> >>> SEXP klass;
> >>> if (isString(klass = getAttrib(x, R_ClassSymbol))) {
> >>>for (int i=0; i >>> if (STRING_ELT(klass, i) == char_) return true;
> >>>}
> >>> }
> >>> return false;
> >>> }
> >>> // S4 inheritance
> >>> bool Rinherits(SEXP x, SEXP char_) {
> >>> SEXP vec = PROTECT(ScalarString(char_));
> >>> SEXP call = PROTECT(lang3(sym_inherits, x, vec));
> >>> bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
> >>> UNPROTECT(2);
> >>> return ans;
> >>> }
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> --
> >> Luke Tierney
> >> Ralph E. Wareham Professor of Mathematical Sciences
> >> University of Iowa Phone: 319-335-3386
> >> Department of Statistics andFax: 319-335-3017
> >> Actuarial Science
> >> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> >> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R C api for 'inherits' S3 and S4 objects
If your goal is to perform multithreaded computations, why not perform
all necessary interactions with R upfront and then compute only on
primitives? It would help for us to understand your use case.
On Fri, Nov 1, 2019 at 4:26 AM Jan Gorecki wrote:
>
> Dear R developers,
>
> Motivated by discussion about checking inheritance of S3 and S4
> objects (in head matrix/array topic) I would light to shed some light
> on a minor gap about that matter in R C API.
> Currently we are able to check inheritance for S3 class objects from C
> in a robust way (no allocation, thread safe). This is unfortunately
> not possible for S4 classes. I would kindly request new function in R
> C api so it can be achieved for S4 classes with no risk of allocation.
> For reference mentioned functions below. Thank you.
> Jan Gorecki
>
> // S3 inheritance
> bool INHERITS(SEXP x, SEXP char_) {
> SEXP klass;
> if (isString(klass = getAttrib(x, R_ClassSymbol))) {
> for (int i=0; i if (STRING_ELT(klass, i) == char_) return true;
> }
> }
> return false;
> }
> // S4 inheritance
> bool Rinherits(SEXP x, SEXP char_) {
> SEXP vec = PROTECT(ScalarString(char_));
> SEXP call = PROTECT(lang3(sym_inherits, x, vec));
> bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
> UNPROTECT(2);
> return ans;
> }
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Michael Lawrence
Senior Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com
Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects
On Fri, 1 Nov 2019, Jan Gorecki wrote:
> Thank you Luke.
> That is why I don't use Rf_inherits but INHERITS which does not
> allocate, provided in the email body.
Your definition can allocate because STING_ELT can allocate.
getAttrib can GC in general. Currently it would not GC or allocate in
this case, but this could change.
You can't assume thread-safety for calls into the R API, or any API
for that matter, unless they are documented to be thread-safe.
You would be better off using Rf_inherits as it does not make the
assumption that you can use pointer comparisons to check for identical
strings. CHARSXPs are almost always cached but they are not
guaranteed to be, and the caching strategy might change in the future.
Best,
luke
> I cannot do similarly for S4 classes, thus asking for some API for that.
>
> On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke wrote:
>>
>> On Fri, 1 Nov 2019, Jan Gorecki wrote:
>>
>>> Dear R developers,
>>>
>>> Motivated by discussion about checking inheritance of S3 and S4
>>> objects (in head matrix/array topic) I would light to shed some light
>>> on a minor gap about that matter in R C API.
>>> Currently we are able to check inheritance for S3 class objects from C
>>> in a robust way (no allocation, thread safe). This is unfortunately
>>
>> Your premise is not correct. Rf_inherits will not GC but it can
>> allocate and is not thread safe.
>>
>> Best,
>>
>> luke
>>
>>> not possible for S4 classes. I would kindly request new function in R
>>> C api so it can be achieved for S4 classes with no risk of allocation.
>>> For reference mentioned functions below. Thank you.
>>> Jan Gorecki
>>>
>>> // S3 inheritance
>>> bool INHERITS(SEXP x, SEXP char_) {
>>> SEXP klass;
>>> if (isString(klass = getAttrib(x, R_ClassSymbol))) {
>>>for (int i=0; i>> if (STRING_ELT(klass, i) == char_) return true;
>>>}
>>> }
>>> return false;
>>> }
>>> // S4 inheritance
>>> bool Rinherits(SEXP x, SEXP char_) {
>>> SEXP vec = PROTECT(ScalarString(char_));
>>> SEXP call = PROTECT(lang3(sym_inherits, x, vec));
>>> bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
>>> UNPROTECT(2);
>>> return ans;
>>> }
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> --
>> Luke Tierney
>> Ralph E. Wareham Professor of Mathematical Sciences
>> University of Iowa Phone: 319-335-3386
>> Department of Statistics andFax: 319-335-3017
>> Actuarial Science
>> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
>> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects
Note that your desire is by definition impossible - as your example also shows
checking for S4 inheritance involves evaluation and thus allocation which
cannot be avoided by the dynamic design of S4 inheritance.
Cheers,
Simon
> On Nov 1, 2019, at 9:23 AM, Jan Gorecki wrote:
>
> Thank you Luke.
> That is why I don't use Rf_inherits but INHERITS which does not
> allocate, provided in the email body.
> I cannot do similarly for S4 classes, thus asking for some API for that.
>
> On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke wrote:
>>
>> On Fri, 1 Nov 2019, Jan Gorecki wrote:
>>
>>> Dear R developers,
>>>
>>> Motivated by discussion about checking inheritance of S3 and S4
>>> objects (in head matrix/array topic) I would light to shed some light
>>> on a minor gap about that matter in R C API.
>>> Currently we are able to check inheritance for S3 class objects from C
>>> in a robust way (no allocation, thread safe). This is unfortunately
>>
>> Your premise is not correct. Rf_inherits will not GC but it can
>> allocate and is not thread safe.
>>
>> Best,
>>
>> luke
>>
>>> not possible for S4 classes. I would kindly request new function in R
>>> C api so it can be achieved for S4 classes with no risk of allocation.
>>> For reference mentioned functions below. Thank you.
>>> Jan Gorecki
>>>
>>> // S3 inheritance
>>> bool INHERITS(SEXP x, SEXP char_) {
>>> SEXP klass;
>>> if (isString(klass = getAttrib(x, R_ClassSymbol))) {
>>> for (int i=0; i>> if (STRING_ELT(klass, i) == char_) return true;
>>> }
>>> }
>>> return false;
>>> }
>>> // S4 inheritance
>>> bool Rinherits(SEXP x, SEXP char_) {
>>> SEXP vec = PROTECT(ScalarString(char_));
>>> SEXP call = PROTECT(lang3(sym_inherits, x, vec));
>>> bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
>>> UNPROTECT(2);
>>> return ans;
>>> }
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> --
>> Luke Tierney
>> Ralph E. Wareham Professor of Mathematical Sciences
>> University of Iowa Phone: 319-335-3386
>> Department of Statistics andFax: 319-335-3017
>>Actuarial Science
>> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
>> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects
AFAIR getAttrib() can allocate as well. Also, R API functions that do
not allocate today, may allocate in the future.
Gabor
On Fri, Nov 1, 2019 at 1:24 PM Jan Gorecki wrote:
>
> Thank you Luke.
> That is why I don't use Rf_inherits but INHERITS which does not
> allocate, provided in the email body.
> I cannot do similarly for S4 classes, thus asking for some API for that.
>
> On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke wrote:
> >
> > On Fri, 1 Nov 2019, Jan Gorecki wrote:
> >
> > > Dear R developers,
> > >
> > > Motivated by discussion about checking inheritance of S3 and S4
> > > objects (in head matrix/array topic) I would light to shed some light
> > > on a minor gap about that matter in R C API.
> > > Currently we are able to check inheritance for S3 class objects from C
> > > in a robust way (no allocation, thread safe). This is unfortunately
> >
> > Your premise is not correct. Rf_inherits will not GC but it can
> > allocate and is not thread safe.
> >
> > Best,
> >
> > luke
> >
> > > not possible for S4 classes. I would kindly request new function in R
> > > C api so it can be achieved for S4 classes with no risk of allocation.
> > > For reference mentioned functions below. Thank you.
> > > Jan Gorecki
> > >
> > > // S3 inheritance
> > > bool INHERITS(SEXP x, SEXP char_) {
> > > SEXP klass;
> > > if (isString(klass = getAttrib(x, R_ClassSymbol))) {
> > >for (int i=0; i > > if (STRING_ELT(klass, i) == char_) return true;
> > >}
> > > }
> > > return false;
> > > }
> > > // S4 inheritance
> > > bool Rinherits(SEXP x, SEXP char_) {
> > > SEXP vec = PROTECT(ScalarString(char_));
> > > SEXP call = PROTECT(lang3(sym_inherits, x, vec));
> > > bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
> > > UNPROTECT(2);
> > > return ans;
> > > }
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > --
> > Luke Tierney
> > Ralph E. Wareham Professor of Mathematical Sciences
> > University of Iowa Phone: 319-335-3386
> > Department of Statistics andFax: 319-335-3017
> > Actuarial Science
> > 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Bioc-devel] merge github + bioc versions
Hello all, I am a bit confused by how git works with bioc ecosystem. I am following this guide to sync my github + bioc repos (for the first time). https://bioconductor.org/developers/how-to/git/sync-existing-repositories/ After step-6, I see following branches * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/upstream/RELEASE_3_10 remotes/upstream/master So, if I add new features to the package and commit & push to master branch, does it affect current version that is released in bioc10? Or do they go to bioc11 devel branch and generate build reports, without affecting the package in bioc10? Should I create a branch RELEASE_3_11 and commit all changes to this branch? I want the changes to be released in bioc11 and do not want to affect bioc10 version. Thank you & have a nice day! -- Best regards Venu Thatikonda https://itsvenu.github.io/ [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects
Thank you Luke.
That is why I don't use Rf_inherits but INHERITS which does not
allocate, provided in the email body.
I cannot do similarly for S4 classes, thus asking for some API for that.
On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke wrote:
>
> On Fri, 1 Nov 2019, Jan Gorecki wrote:
>
> > Dear R developers,
> >
> > Motivated by discussion about checking inheritance of S3 and S4
> > objects (in head matrix/array topic) I would light to shed some light
> > on a minor gap about that matter in R C API.
> > Currently we are able to check inheritance for S3 class objects from C
> > in a robust way (no allocation, thread safe). This is unfortunately
>
> Your premise is not correct. Rf_inherits will not GC but it can
> allocate and is not thread safe.
>
> Best,
>
> luke
>
> > not possible for S4 classes. I would kindly request new function in R
> > C api so it can be achieved for S4 classes with no risk of allocation.
> > For reference mentioned functions below. Thank you.
> > Jan Gorecki
> >
> > // S3 inheritance
> > bool INHERITS(SEXP x, SEXP char_) {
> > SEXP klass;
> > if (isString(klass = getAttrib(x, R_ClassSymbol))) {
> >for (int i=0; i > if (STRING_ELT(klass, i) == char_) return true;
> >}
> > }
> > return false;
> > }
> > // S4 inheritance
> > bool Rinherits(SEXP x, SEXP char_) {
> > SEXP vec = PROTECT(ScalarString(char_));
> > SEXP call = PROTECT(lang3(sym_inherits, x, vec));
> > bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
> > UNPROTECT(2);
> > return ans;
> > }
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects
On Fri, 1 Nov 2019, Jan Gorecki wrote:
> Dear R developers,
>
> Motivated by discussion about checking inheritance of S3 and S4
> objects (in head matrix/array topic) I would light to shed some light
> on a minor gap about that matter in R C API.
> Currently we are able to check inheritance for S3 class objects from C
> in a robust way (no allocation, thread safe). This is unfortunately
Your premise is not correct. Rf_inherits will not GC but it can
allocate and is not thread safe.
Best,
luke
> not possible for S4 classes. I would kindly request new function in R
> C api so it can be achieved for S4 classes with no risk of allocation.
> For reference mentioned functions below. Thank you.
> Jan Gorecki
>
> // S3 inheritance
> bool INHERITS(SEXP x, SEXP char_) {
> SEXP klass;
> if (isString(klass = getAttrib(x, R_ClassSymbol))) {
>for (int i=0; i if (STRING_ELT(klass, i) == char_) return true;
>}
> }
> return false;
> }
> // S4 inheritance
> bool Rinherits(SEXP x, SEXP char_) {
> SEXP vec = PROTECT(ScalarString(char_));
> SEXP call = PROTECT(lang3(sym_inherits, x, vec));
> bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
> UNPROTECT(2);
> return ans;
> }
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R C api for 'inherits' S3 and S4 objects
Dear R developers,
Motivated by discussion about checking inheritance of S3 and S4
objects (in head matrix/array topic) I would light to shed some light
on a minor gap about that matter in R C API.
Currently we are able to check inheritance for S3 class objects from C
in a robust way (no allocation, thread safe). This is unfortunately
not possible for S4 classes. I would kindly request new function in R
C api so it can be achieved for S4 classes with no risk of allocation.
For reference mentioned functions below. Thank you.
Jan Gorecki
// S3 inheritance
bool INHERITS(SEXP x, SEXP char_) {
SEXP klass;
if (isString(klass = getAttrib(x, R_ClassSymbol))) {
for (int i=0; ihttps://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] head.matrix can return 1000s of columns -- limit to n or add new argument?
> peter dalgaard
> on Thu, 31 Oct 2019 23:04:29 +0100 writes:
> Hmm, the problem I see here is that these implied classes are all
inherently one-off. We also have
>> inherits(matrix(1,1,1),"numeric")
> [1] FALSE
>> is.numeric(matrix(1,1,1))
> [1] TRUE
>> inherits(1L,"numeric")
> [1] FALSE
>> is.numeric(1L)
> [1] TRUE
> and if we start fixing one, we might need to fix all.
I disagree about "fixing all" (see also my reply to Hervé), and
the {"numeric","double","integer"} case is particularly messy,
and I don't want to open that can now.
> For method dispatch, we do have inheritance, e.g.
>> foo.numeric <- function(x) x + 1
>> foo <- function(x) UseMethod("foo")
>> foo(1)
> [1] 2
>> foo(1L)
> [1] 2
>> foo(matrix(1,1,1))
> [,1]
> [1,]2
>> foo.integer <- function(x) x + 2
>> foo(1)
> [1] 2
>> foo(1L)
> [1] 3
>> foo(matrix(1,1,1))
> [,1]
> [1,]2
>> foo(matrix(1L,1,1))
> [,1]
> [1,]3
> but these are not all automatic: "integer" implies "numeric", but
"matrix" does not imply "numeric", much less "integer".
well it should not imply in general:
Contrary to Math, we also have 'raw' or 'character' or 'logical' matrices.
> Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
good point, and that's why my usage of inherits(.,.) was not
quite to the point. [OTOH, it was to the point, as indeed from
the ?class / ?inherits docu, S3 method dispatch and inherits
must be consistent ]
> which would break -- unless we change class(x) to return the whole set of
inherited classes, which I sense that we'd rather not do
and we have something like that already with is(.)
Thank you for these important points raised!
Note again that both "matrix" and "array" are special [see ?class] as
being of __implicit class__ and I am considering that this
implicit class behavior for these two should be slightly changed
such that
foo <- function(x,...) UseMethod("foo")
foo.array <- function(x, ...)
sprintf("array of dim. %s", paste(dim(x), collapse = " x "))
should work for all arrays and not be an exception for 2D arrays :
> foo(array(pi, 1:3))
[1] "array of dim. 1 x 2 x 3"
> foo(array(pi, 1))
[1] "array of dim. 1"
> foo(array(pi, 2:7))
[1] "array of dim. 2 x 3 x 4 x 5 x 6 x 7"
> foo(array(pi, 1:2))
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "c('matrix',
'double', 'numeric')"
>
And indeed I think you are right on spot and this would mean
that indeed the implicit class
"matrix" should rather become c("matrix", "array").
BTW: The 'Details' section of ?class nicely defines things,
notably the __implicit class__ situation
(but I think should be improved) :
{numbering the paragraphs for reference}
> Details:
>
> 1. Here, we describe the so called “S3” classes (and methods). For
> “S4” classes (and methods), see ‘Formal classes’ below.
>
> 2. Many R objects have a class attribute, a character vector giving
> the names of the classes from which the object _inherits_.
> (Functions oldClass and oldClass<- get and set the attribute,
> which can also be done directly.)
>
> 3. If the object does not have a class attribute, it has an implicit
> class, notably ‘"matrix"’, ‘"array"’, ‘"function"’ or ‘"numeric"’
> or the result of ‘typeof(x)’ (which is similar to ‘mode(x)’), but
> for type ‘"language"’ and mode ‘"call"’, where the following
> extra classes exist for the corresponding function calls: if,
> while, for, =, <-, (, {, call.
So, I think clearly { for S3, not S4 ! }
"class attribute" := attr(x, "class")
"implicit class" := the class(x) of R objects that do *not*
have a class attribute
> 4. Note that NULL objects cannot have attributes (hence not
> classes) and attempting to assign a class is an error.
the above has one small flaw : "(hence not classes)" is not correct.
Of course class(NULL) is "NULL" by par. 3's typeof(x) "rule".
> 5a. When a generic function ‘fun’ is applied to an object with class
> attribute ‘c("first", "second")’, the system searches for a
> function called ‘fun.first’ and, if it finds it, applies it to the
> object. If no such function is found, a function called
> ‘fun.second’ is tried. If no class name produces a suitable
> function, the function ‘fun.default’ is used (if it exists).
> 5b. If there is no class attribute, the implicit class is tried, then the
> default method.
> 6. The function 'class' prints the vector of names of classes an
> object inherits from. Correspondingly, class<- sets the classes
> an object inherits from. Assigning NULL removes the class
> attribute.
["of course", the word "prints" above should be replaced by "returns" ! ]
> 7.
Re: [R-pkg-devel] invalid multibyte string on solaris?
On 10/31/19 12:58 AM, Toby Hocking wrote: Hi all, I am getting an "invalid multibyte string" error from one of my examples when it is run on solaris, which results in check FAILURE: https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html To fix this I guess I could just delete this example, but is there any easy/known fix? I searched the r-devel and r-package-devel lists and I did not find any relevant threads. I also see that the same package on r-hub solaris is a check PASS: https://builder.r-hub.io/status/nc_2019.10.19.tar.gz-8b46d2a02a6340bcb313eeec96e404f3 I was expecting that CRAN and r-hub solaris builds should report the same results. What could be the difference? is this a bug in CRAN or in r-hub? The configuration of the CRAN check machine is given at https://cran.r-project.org/web/checks/check_flavors.html#r-patched-solaris-x86 (see the Details section). I cannot reproduce the problem on a Solaris machine I have access to (but it is yet a different configuration, so I am not surprised). The problem is that during substring(), the C library function mbrtowc() fails to convert a multi-byte coded string to a wide character, which is needed to know how many bytes are used. I am not sure why it fails without being able to reproduce, maybe the runtime library does not support Emoji, but of course there can be a bug in R, too. From the previous issue you have run into with Emoji, we know that the machine (compiler runtime) does not declare that wchar_t is Unicode. Clearly, by using Emoji you are stress-testing R, packages, external libraries and the OS libraries, because these characters need surrogate pairs in UTF-16 but a lot of old code was written before they even existed, with all the problems of wchar_t. Pragmatically, I would avoid using Emoji for these reasons in production systems. If you, instead, wanted to stress test R or libraries to find out where surrogate pairs were still not handled properly, it would be better to look for reproducible examples on systems you have access to and you can debug on your end. Some of these problems could be found simply by code inspection as well, though. We could then fix at places where it is easy or at least document in the code. Best Tomas [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] head.matrix can return 1000s of columns -- limit to n or add new argument?
> Pages, Herve
> on Thu, 31 Oct 2019 21:02:07 + writes:
> On 10/30/19 04:29, Martin Maechler wrote:
>>> Gabriel Becker
>>> on Tue, 29 Oct 2019 12:43:15 -0700 writes:
>>
>> > Hi all,
>> > So I've started working on this and I ran into something that I didn't
>> > know, namely that for x a multi-dimensional (2+) array, head(x) and
tail(x)
>> > ignore dimension completely, treat x as an atomic vector, and return an
>> > (unclassed) atomic vector:
>>
>> Well, that's (3+), not "2+" .
>>
>> But I did write (on Sep 17 in this thread!)
>>
>> > The current source for head() and tail() and all their methods
>> > in utils is just 83 lines of code {file utils/R/head.R minus
>> > the initial mostly copyright comments}.
>>
>> and if've ever looked at these few dozen of R code lines, you'll
>> have seen that we just added two simple utilities with a few
>> reasonable simple methods. To treat non-matrix (i.e. non-2d)
>> arrays as vectors, is typically not unreasonable in R, but
>> indeed with your proposals (in this thread), such non-2d arrays
>> should be treated differently either via new head.array() /
>> tail.array() methods ((or -- only if it can be done more nicely -- by
>> the default method)).
>>
>> Note however the following historical quirk :
>>
>>> sapply(setNames(,1:5), function(K) inherits(array(pi, dim=1:K),
"array"))
>> 1 2 3 4 5
>> TRUE FALSE TRUE TRUE TRUE
>>
>> (Is this something we should consider changing for R 4.0.0 -- to
>> have it TRUE also for 2d-arrays aka matrix objects ??)
> That would be awesome! More generally I wonder how feasible it would be
> to fix all these inheritance quirks where inherits(x, "something"),
> is(x, "something"), and is.something(x) disagree. They've been such a
> nuisance for so many years...
> Thanks,
> H.
Thank you Hervé; you are right "in theory", but
no, we don't want to fix _all_ these quirks at the moment
(because we know how much this would break).
Note that ?class does mention S3 and S4, and also you know about
is(.,.) which is more "rational" than inherits insofar as it
"thinks" the S4 way about inheritance .. but then it has it's
surprises, too; e.g., note the result of is(NULL) .
I really wanted to address the relatively limited case of
{matrix, array} for now.
{{more on this in the subthread Peter opened}}
Martin
>> The consequence of that is that
>> currently, "often" foo.matrix is just a copy of foo.array in
>> the case the latter exists:
>> "base" examples: foo in {unique, duplicated, anyDuplicated}.
>>
>> So I propose you change current head.matrix and tail.matrix to
>> head.array and tail.array
>> (and then have head.matrix <- head.array etc, at least if the
>> above quirk must remain, or remains (which I currently guess to
>> be the case)).
>>
>>
>> >> x = array(100, c(4, 5, 5))
>>
>> >> dim(x)
>>
>> > [1] 4 5 5
>>
>> >> head(x, 1)
>>
>> > [1] 100
>>
>> >> class(head(x))
>>
>> > [1] "numeric"
>>
>>
>> > (For a 1d array, it does return another 1d array).
>>
>> > When extending head/tail to understand multiple dimensions as
discussed in
>> > this thread, then, should the behavior for 2+d arrays be explicitly
>> > retained, or should head and tail do the analogous thing (with a
head(<2d
array> ) behaving the same as head(), which honestly is what I
>> > expected to already be happening)?
>>
>> > Are people using/relying on this behavior in their code, and if so,
why/for
>> > what?
>>
>> > Even more generally, one way forward is to have the default methods
check
>> > for dimensions, and use length if it is null:
>>
>> > tail.default <- tail.data.frame <- function(x, n = 6L, ...)
>> > {
>> > if(any(n == 0))
>> > stop("n must be non-zero or unspecified for all dimensions")
>> > if(!is.null(dim(x)))
>> > dimsx <- dim(x)
>> > else
>> > dimsx <- length(x)
>>
>> > ## this returns a list of vectors of indices in each
>> > ## dimension, regardless of length of the the n
>> > ## argument
>> > sel <- lapply(seq_along(dimsx), function(i) {
>> > dxi <- dimsx[i]
>> > ## select all indices (full dim) if not specified
>> > ni <- if(length(n) >= i) n[i] else dxi
>> > ## handle negative ns
>> > ni <- if (ni < 0L) max(dxi + ni, 0L) else min(ni, dxi)
>> > seq.int(to = dxi, length.out = ni)
>> > })
>> > args <- c(list(x), sel, drop = FALSE)
>> > do.call("[", args)
>> > }
>>
>>
>> > I think this precludes the need for a separate data.frame method at
all,
>> > actually, though (I would think) tail.data.frame would still be
defined and
>> >
Re: [Bioc-devel] Bioconductor 3.10 is released!!
Indeed, it's amazing. Thank you, Lori and core team. Il gio 31 ott 2019, 1:11 PM Sean Davis ha scritto: > Huge kudos to the team for another successful release. > > Sean > > On Wed, Oct 30, 2019 at 4:54 PM Shepherd, Lori < > lori.sheph...@roswellpark.org> wrote: > > > Thanks to all developers and community members for contributing to the > > project! > > > > Please see the full release announcement: > > > >https://www.bioconductor.org/news/bioc_3_10_release/ > > > > The Bioconductor Team > > > > > > > > Lori Shepherd > > > > Bioconductor Core Team > > > > Roswell Park Comprehensive Cancer Center > > > > Department of Biostatistics & Bioinformatics > > > > Elm & Carlton Streets > > > > Buffalo, New York 14263 > > > > > > This email message may contain legally privileged and/or confidential > > information. If you are not the intended recipient(s), or the employee > or > > agent responsible for the delivery of this message to the intended > > recipient(s), you are hereby notified that any disclosure, copying, > > distribution, or use of this email message is prohibited. If you have > > received this message in error, please notify the sender immediately by > > e-mail and delete this email message from your computer. Thank you. > > [[alternative HTML version deleted]] > > > > ___ > > Bioc-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > > -- > 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
