[R-pkg-devel] Need help building packages to track down ASAN error

[Steven Scott]

One of my packages (bsts) appears to have a memory error identified by ASAN.
I'm trying to build an ASAN-enabled R+bsts so that I can debug the error.

I'm using the rocker image rocker/r-devel-ubsan-clang, loaded and run as
follows:

docker run --cap-add SYS_PTRACE -e PASSWORD= --rm -p 8787:8787 -v
/home/steve/code/BOOM:/home/steve/code/BOOM -it rocker/r-devel-ubsan-clang
/bin/bash

This launches me into a bash shell.  At this point I think I need to build
and
install my package.  On this image the home directory is /root, and under
/root
I have installed /root/.R/Makevars with the following content (per section
4.3
of WRE).

CC = clang -std=c99 -fsanitize=address -fno-omit-frame-pointer
CXX = clang++ -std=c++11 -fsanitize=address -fno-omit-frame-pointer
FC = gfortran -fsanitize=address

When I run the scripts to build and install my packages (bsts + 2
dependencies,
named Boom and BoomSpikeSlab), I get output that looks like

g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-I`/usr/lib/R/bin/Rscript -e "cat(system.file(package='Boom'))"`/include
-DADD_ -DR_NO_REMAP -DRLANGUAGE
-I"/usr/local/lib/R/site-library/Boom/include"   -fpic  -g -O2
-fdebug-prefix-map=/build/r-base-MP6Q4u/r-base-3.6.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c boom_spike_slab_init.cc -o boom_spike_slab_init.o
g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-I`/usr/lib/R/bin/Rscript -e "cat(system.file(package='Boom'))"`/include
-DADD_ -DR_NO_REMAP -DRLANGUAGE
-I"/usr/local/lib/R/site-library/Boom/include"   -fpic  -g -O2
-fdebug-prefix-map=/build/r-base-MP6Q4u/r-base-3.6.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g  -c logit_spike_slab_wrapper.cc -o
logit_spike_slab_wrapper.o


Here g++ is being used instad of the requested clang++ (I'm assuming R on
this
image was built with clang), and the important -fsanitize=address flag is
not
present.  So it seems that ~/.R/Makevars is being ignored.

The goal is to produce an ASAN-enabled package so that I can test for the
error.
Am I on the correct path to producing such a package, and if so what else
do I
need to do to get there?

Thank you.

[[alternative HTML version deleted]]

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

[Bioc-devel] Request for activating Bioconductor repository account for Lumi and methyAnalysis package

[Huang, Lei [CRI]]

Dear Bioconductor team,

We are the maintainers of Bioconductor packages Lumi 
(https://bioconductor.org/packages/release/bioc/html/lumi.html) and 
methyAnalysis 
(https://bioconductor.org/packages/release/bioc/html/methyAnalysis.html). We 
were trying to obtain Bioconductor Git credentials by activating the account 
associated to those packages at 
https://git.bioconductor.org/BiocCredentials/account_activation/ but got the 
following error message instead.


"lhu...@bsd.uchicago.edu is not associated with 
a maintainer of a Bioconductor package. Please check the spelling or contact 
bioc-devel@r-project.org for help."

Would you please help us on this?

Best,
Lei


Lei Huang, Ph.D.
Senior Bioinformatician
Center for Research Informatics
University of Chicago
Email: lhuang at bsd.uchicago.edu




[[alternative HTML version deleted]]

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

Re: [Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Simon Urbanek]

Ben,

yes, you have to store the result into a variable, then unprotect, then return.

Cheers,
S


> On 24/03/2020, at 10:07 AM, Ben Bolker  wrote:
> 
> 
> Thanks, that's really useful.  One more question for you, or someone
> else here:
> 
> const ArrayXd glmLink::linkFun(const ArrayXd& mu) const {
>return as(::Rf_eval(::Rf_lang2(as(d_linkFun),
> 
> as(Rcpp::NumericVector(mu.data(),
> 
> mu.data() + mu.size()))
>   ), d_rho);
>}
> 
> 
> I guess I need that to read
> PROTECT(::Rf_eval(PROTECT(::Rf_lang2(...),...) , but as written it
> doesn't seem I have anywhere to squeeze in an UNPROTECT(2).  Do I need
> to define a temporary variable so I can UNPROTECT(2) before I return the
> value?
> 
> Or is there a way I can use Shield() since this an Rcpp-based project
> anyway?
> 
>  Sorry for all the very basic questions, but I'm flying nearly blind
> here ...
> 
>  cheers
>   Ben Bolker
> 
> 
> 
> On 2020-03-23 4:01 p.m., Tomas Kalibera wrote:
>> On 3/23/20 8:39 PM, Ben Bolker wrote:
>>> Dear r-devel folks,
>>> 
>>>[if this is more appropriate for r-pkg-devel please let me know and
>>> I'll repost it over there ...]
>>> 
>>> I'm writing to ask for help with some R/C++ integration idioms that are
>>> used in a package I'm maintaining, that are unfamilar to me, and that
>>> are now being flagged as problematic by Tomas Kalibera's 'rchk'
>>> machinery (https://github.com/kalibera/rchk); results are here
>>> https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out
>>> 
>>> 
>>> The problem is with constructions like
>>> 
>>> ::Rf_eval(::Rf_lang2(fun, arg), d_rho)
>>> 
>>> I *think* this means "construct a two-element pairlist from fun and arg,
>>> then evaluate it within expression d_rho"
>>> 
>>> This leads to warnings like
>>> 
>>> "calling allocating function Rf_eval with argument allocated using
>>> Rf_lang2"
>>> 
>>> Is this a false positive or ... ? Can anyone help interpret this?
>> This is a true error. You need to protect the argument of eval() before
>> calling eval, otherwise eval() could destroy it before using it. This is
>> a common rule: whenever passing an argument to a function, that argument
>> must be protected (directly or indirectly). Rchk tries to be smart and
>> doesn't report a warning when it can be sure that in that particular
>> case, for that particular function, it is safe. This is easy to fix,
>> just protect the result of lang2() before the call and unprotect (some
>> time) after.
>>> Not sure why this idiom was used in the first place: speed? (e.g., see
>>> https://stat.ethz.ch/pipermail/r-devel/2019-June/078020.html ) Should I
>>> be rewriting to avoid Rf_eval entirely in favor of using a Function?
>>> (i.e., as commented in
>>> https://stackoverflow.com/questions/37845012/rcpp-function-slower-than-rf-eval
>>> 
>>> : "Also, calling Rf_eval() directly from a C++ context is dangerous as R
>>> errors (ie, C longjmps) will bypass the destructors of C++ objects and
>>> leak memory / cause undefined behavior in general. Rcpp::Function tries
>>> to make sure that doesn't happen.")
>> 
>> Yes, eval (as well as lang2) can throw an error, this error has to be
>> caught via R API and handled (e.g. by throwing as exception or something
>> else, indeed that exception then needs to be caught and possibly
>> converted back when leaving again to C stack frames). An R/C API you can
>> use here is R_UnwindProtect. This is of course a bit of a pain, and one
>> does not have to worry when programming in plain C.
>> 
>> I suppose Rcpp provides some wrapper around R_UnwindProtect, that would
>> be a question for Rcpp experts/maintainers.
>> 
>> Best
>> Tomas
>> 
>>> 
>>>   Any tips, corrections, pointers to further documentation, etc. would be
>>> most welcome ... Web searching for this stuff hasn't gotten me very far,
>>> and it seems to be deeper than most of the introductory material I can
>>> find (including the Rcpp vignettes) ...
>>> 
>>>cheers
>>> Ben Bolker
>>> 
>>> __
>>> 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
> 

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

Re: [Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Martin Maechler]

> Ben Bolker 
> on Mon, 23 Mar 2020 17:07:36 -0400 writes:

> Thanks, that's really useful.  One more question for you, or someone
> else here:

> const ArrayXd glmLink::linkFun(const ArrayXd& mu) const {
> return as(::Rf_eval(::Rf_lang2(as(d_linkFun),

> as(Rcpp::NumericVector(mu.data(),

> mu.data() + mu.size()))
> ), d_rho);
> }


> I guess I need that to read
> PROTECT(::Rf_eval(PROTECT(::Rf_lang2(...),...) , but as written it
> doesn't seem I have anywhere to squeeze in an UNPROTECT(2).  Do I need
> to define a temporary variable so I can UNPROTECT(2) before I return the
> value?

Ben, as co-author of the package, I could try .. I have lots of
experience with (nice and clean) C API using PROTECT ...
which I could try to apply here.

I'm busy teaching tomorrow (with the extra time of setting up
remote teaching ..)  but could look into it later {and try using
non-Rcpp C code}.

> Or is there a way I can use Shield() since this an Rcpp-based project
> anyway?

> Sorry for all the very basic questions, but I'm flying nearly blind
> here ...

> cheers
> Ben Bolker



> On 2020-03-23 4:01 p.m., Tomas Kalibera wrote:
>> On 3/23/20 8:39 PM, Ben Bolker wrote:
>>> Dear r-devel folks,
>>> 
>>>    [if this is more appropriate for r-pkg-devel please let me know and
>>> I'll repost it over there ...]
>>> 
>>> I'm writing to ask for help with some R/C++ integration idioms that are
>>> used in a package I'm maintaining, that are unfamilar to me, and that
>>> are now being flagged as problematic by Tomas Kalibera's 'rchk'
>>> machinery (https://github.com/kalibera/rchk); results are here
>>> 
https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out
>>> 
>>> 
>>> The problem is with constructions like
>>> 
>>> ::Rf_eval(::Rf_lang2(fun, arg), d_rho)
>>> 
>>> I *think* this means "construct a two-element pairlist from fun and arg,
>>> then evaluate it within expression d_rho"
>>> 
>>> This leads to warnings like
>>> 
>>> "calling allocating function Rf_eval with argument allocated using
>>> Rf_lang2"
>>> 
>>> Is this a false positive or ... ? Can anyone help interpret this?
>> This is a true error. You need to protect the argument of eval() before
>> calling eval, otherwise eval() could destroy it before using it. This is
>> a common rule: whenever passing an argument to a function, that argument
>> must be protected (directly or indirectly). Rchk tries to be smart and
>> doesn't report a warning when it can be sure that in that particular
>> case, for that particular function, it is safe. This is easy to fix,
>> just protect the result of lang2() before the call and unprotect (some
>> time) after.
>>> Not sure why this idiom was used in the first place: speed? (e.g., see
>>> https://stat.ethz.ch/pipermail/r-devel/2019-June/078020.html ) Should I
>>> be rewriting to avoid Rf_eval entirely in favor of using a Function?
>>> (i.e., as commented in
>>> 
https://stackoverflow.com/questions/37845012/rcpp-function-slower-than-rf-eval
>>> 
>>> : "Also, calling Rf_eval() directly from a C++ context is dangerous as R
>>> errors (ie, C longjmps) will bypass the destructors of C++ objects and
>>> leak memory / cause undefined behavior in general. Rcpp::Function tries
>>> to make sure that doesn't happen.")
>> 
>> Yes, eval (as well as lang2) can throw an error, this error has to be
>> caught via R API and handled (e.g. by throwing as exception or something
>> else, indeed that exception then needs to be caught and possibly
>> converted back when leaving again to C stack frames). An R/C API you can
>> use here is R_UnwindProtect. This is of course a bit of a pain, and one
>> does not have to worry when programming in plain C.
>> 
>> I suppose Rcpp provides some wrapper around R_UnwindProtect, that would
>> be a question for Rcpp experts/maintainers.
>> 
>> Best
>> Tomas
>> 
>>> 
>>>   Any tips, corrections, pointers to further documentation, etc. would 
be
>>> most welcome ... Web searching for this stuff hasn't gotten me very far,
>>> and it seems to be deeper than most of the introductory material I can
>>> find (including the Rcpp vignettes) ...
>>> 
>>>    cheers
>>>     Ben Bolker
>>> 
>>> __
>>> 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

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

Re: [Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Ben Bolker]

 Thanks, that's really useful.  One more question for you, or someone
else here:

const ArrayXd glmLink::linkFun(const ArrayXd& mu) const {
return as(::Rf_eval(::Rf_lang2(as(d_linkFun),

as(Rcpp::NumericVector(mu.data(),

 mu.data() + mu.size()))
), d_rho);
}


I guess I need that to read
PROTECT(::Rf_eval(PROTECT(::Rf_lang2(...),...) , but as written it
doesn't seem I have anywhere to squeeze in an UNPROTECT(2).  Do I need
to define a temporary variable so I can UNPROTECT(2) before I return the
value?

Or is there a way I can use Shield() since this an Rcpp-based project
anyway?

  Sorry for all the very basic questions, but I'm flying nearly blind
here ...

  cheers
   Ben Bolker



On 2020-03-23 4:01 p.m., Tomas Kalibera wrote:
> On 3/23/20 8:39 PM, Ben Bolker wrote:
>> Dear r-devel folks,
>>
>>    [if this is more appropriate for r-pkg-devel please let me know and
>> I'll repost it over there ...]
>>
>> I'm writing to ask for help with some R/C++ integration idioms that are
>> used in a package I'm maintaining, that are unfamilar to me, and that
>> are now being flagged as problematic by Tomas Kalibera's 'rchk'
>> machinery (https://github.com/kalibera/rchk); results are here
>> https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out
>>
>>
>> The problem is with constructions like
>>
>> ::Rf_eval(::Rf_lang2(fun, arg), d_rho)
>>
>> I *think* this means "construct a two-element pairlist from fun and arg,
>> then evaluate it within expression d_rho"
>>
>> This leads to warnings like
>>
>> "calling allocating function Rf_eval with argument allocated using
>> Rf_lang2"
>>
>> Is this a false positive or ... ? Can anyone help interpret this?
> This is a true error. You need to protect the argument of eval() before
> calling eval, otherwise eval() could destroy it before using it. This is
> a common rule: whenever passing an argument to a function, that argument
> must be protected (directly or indirectly). Rchk tries to be smart and
> doesn't report a warning when it can be sure that in that particular
> case, for that particular function, it is safe. This is easy to fix,
> just protect the result of lang2() before the call and unprotect (some
> time) after.
>> Not sure why this idiom was used in the first place: speed? (e.g., see
>> https://stat.ethz.ch/pipermail/r-devel/2019-June/078020.html ) Should I
>> be rewriting to avoid Rf_eval entirely in favor of using a Function?
>> (i.e., as commented in
>> https://stackoverflow.com/questions/37845012/rcpp-function-slower-than-rf-eval
>>
>> : "Also, calling Rf_eval() directly from a C++ context is dangerous as R
>> errors (ie, C longjmps) will bypass the destructors of C++ objects and
>> leak memory / cause undefined behavior in general. Rcpp::Function tries
>> to make sure that doesn't happen.")
> 
> Yes, eval (as well as lang2) can throw an error, this error has to be
> caught via R API and handled (e.g. by throwing as exception or something
> else, indeed that exception then needs to be caught and possibly
> converted back when leaving again to C stack frames). An R/C API you can
> use here is R_UnwindProtect. This is of course a bit of a pain, and one
> does not have to worry when programming in plain C.
> 
> I suppose Rcpp provides some wrapper around R_UnwindProtect, that would
> be a question for Rcpp experts/maintainers.
> 
> Best
> Tomas
> 
>>
>>   Any tips, corrections, pointers to further documentation, etc. would be
>> most welcome ... Web searching for this stuff hasn't gotten me very far,
>> and it seems to be deeper than most of the introductory material I can
>> find (including the Rcpp vignettes) ...
>>
>>    cheers
>>     Ben Bolker
>>
>> __
>> 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] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Tomas Kalibera]

On 3/23/20 8:39 PM, Ben Bolker wrote:

Dear r-devel folks,

   [if this is more appropriate for r-pkg-devel please let me know and
I'll repost it over there ...]

I'm writing to ask for help with some R/C++ integration idioms that are
used in a package I'm maintaining, that are unfamilar to me, and that
are now being flagged as problematic by Tomas Kalibera's 'rchk'
machinery (https://github.com/kalibera/rchk); results are here
https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out

The problem is with constructions like

::Rf_eval(::Rf_lang2(fun, arg), d_rho)

I *think* this means "construct a two-element pairlist from fun and arg,
then evaluate it within expression d_rho"

This leads to warnings like

"calling allocating function Rf_eval with argument allocated using Rf_lang2"

Is this a false positive or ... ? Can anyone help interpret this?
This is a true error. You need to protect the argument of eval() before 
calling eval, otherwise eval() could destroy it before using it. This is 
a common rule: whenever passing an argument to a function, that argument 
must be protected (directly or indirectly). Rchk tries to be smart and 
doesn't report a warning when it can be sure that in that particular 
case, for that particular function, it is safe. This is easy to fix, 
just protect the result of lang2() before the call and unprotect (some 
time) after.

Not sure why this idiom was used in the first place: speed? (e.g., see
https://stat.ethz.ch/pipermail/r-devel/2019-June/078020.html ) Should I
be rewriting to avoid Rf_eval entirely in favor of using a Function?
(i.e., as commented in
https://stackoverflow.com/questions/37845012/rcpp-function-slower-than-rf-eval
: "Also, calling Rf_eval() directly from a C++ context is dangerous as R
errors (ie, C longjmps) will bypass the destructors of C++ objects and
leak memory / cause undefined behavior in general. Rcpp::Function tries
to make sure that doesn't happen.")


Yes, eval (as well as lang2) can throw an error, this error has to be 
caught via R API and handled (e.g. by throwing as exception or something 
else, indeed that exception then needs to be caught and possibly 
converted back when leaving again to C stack frames). An R/C API you can 
use here is R_UnwindProtect. This is of course a bit of a pain, and one 
does not have to worry when programming in plain C.


I suppose Rcpp provides some wrapper around R_UnwindProtect, that would 
be a question for Rcpp experts/maintainers.


Best
Tomas



  Any tips, corrections, pointers to further documentation, etc. would be
most welcome ... Web searching for this stuff hasn't gotten me very far,
and it seems to be deeper than most of the introductory material I can
find (including the Rcpp vignettes) ...

   cheers
Ben Bolker

__
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: [Bioc-devel] Issue Reproducing BioC 3.11 COHCAP Error Message

[Charles Warden]

Hi Everybody,

Thank you again for your help!

I think the issue for the COHCAP devel package has now been resolved:

http://bioconductor.org/checkResults/release/bioc-LATEST/COHCAP/

I had somewhat similar error messages for sRAP (which is different than 
COHCAP), but I am OK with sRAP being removed from the next version of 
Bioconductor (since it is no longer being maintained).  If you can please let 
me know if there is a contact that I should e-mail (beyond this mailing list, 
or not fixing the error), then I would appreciate that.

Thanks Again,
Charles

-Original Message-
From: Charles Warden 
Sent: Friday, March 20, 2020 1:40 PM
To: Martin Morgan ; Alexey Sergushichev 

Cc: bioc-devel@r-project.org
Subject: RE: [Bioc-devel] Issue Reproducing BioC 3.11 COHCAP Error Message

Hi Martin,

That is probably what happened.

Thank you again for your help!

Sincerely,
Charles

-Original Message-
From: Martin Morgan  
Sent: Friday, March 20, 2020 1:38 PM
To: Charles Warden ; Alexey Sergushichev 
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Issue Reproducing BioC 3.11 COHCAP Error Message

yes, use 1.33.1. Maybe you had a space between the '.' and the '1' or similar, 
'1.33. 1' ? This generates an error

** using staged installation
Error : Invalid DESCRIPTION file

Malformed package version.

See section 'The DESCRIPTION file' in the 'Writing R Extensions'
manual.

ERROR: installing package DESCRIPTION failed for package ...

Martin


On 3/20/20, 4:28 PM, "Charles Warden"  wrote:

Hi Martin,

I am currently having difficulty reproducing my earlier error (which I 
think didn’t even get to the step of testing the demo code).  So, I think the 
short answer is that I should just use version 1.33.1.

In my search history, I can tell that I Googled "R Malformed package 
version," so I think that was part of the earlier message that I got.

For what is worth, I think this is what gave me the idea to change the 
version numbering system:


https://urldefense.com/v3/__https://cran.r-project.org/doc/manuals/r-release/R-exts.html*The-DESCRIPTION-file__;Iw!!Fou38LsQmgU!54yJgFhe0LVN6Sfb91X3m3HjH3zyeO6TroDujXtNKpwV4g0kwCruJ9yJaP_S$
 

However, if I am not currently getting an error message, then I won't worry 
about it.

Thank you very much for your help!

Sincerely,
Charles

-Original Message-
From: Martin Morgan  
Sent: Friday, March 20, 2020 1:09 PM
To: Charles Warden ; Alexey Sergushichev 

Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Issue Reproducing BioC 3.11 COHCAP Error Message

Can you be precise about the concern about 1.33.1 as a version number (what 
precise note / error / warning you received)? This scheme is very standard for 
package versions, and as you see enforced (for many years!) by Bioconductor.

Martin

On 3/20/20, 4:03 PM, "Bioc-devel on behalf of Charles Warden" 
 wrote:

Hi Everybody,

I think changing that read.table() parameter fixed the main issue.

However, when I tested my code, R used a different way to note versions 
in R-v.4.0.0.

For example, in order to clear a message from “R CMD check” or “R CMD 
build”, I had to say the version was 1.33-1 (instead of 1.33.1).

I uploaded those changes to GitHub and tested an R-3.6 installation, 
and that was OK.

However, when I am working on merging the GitHub and Bioconductor 
branches, I get the following error message:

“Remote: Error: Illegal version bump from ‘1.33.0’ to ‘1.33-1’“

Is this going to be changed in Bioconductor, or should I see if this is 
only a NOTE or WARNING (and submit the package as version 1.33.1)?

Thank You,
Charles

From: Alexey Sergushichev 
Sent: Thursday, March 19, 2020 3:00 PM
To: Charles Warden 
Cc: Shepherd, Lori ; 
bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Issue Reproducing BioC 3.11 COHCAP Error 
Message

I think one of the major changes recently is setting stringsAsFactors 
option to FALSE by default.

Best,
Alexey

On Fri, Mar 20, 2020 at 12:48 AM Charles Warden 
mailto:cwar...@coh.org>> wrote:
Hi Lori,

Thank you very much.

If I use R-4.0 (instead of R-3.6), then I can reproduce the error 
message.

I will work in figuring out why the code works with R-3.6 but not 
R-4.0, but it seems like this might affect other packages as well (since I 
received error messages for 2 out of 2 of the Bioconductor packages that I 
contributed to).

Do you have any general suggestions of what types of new errors might 
be encountered from using R-4.0?

Thanks Again,
Charles

From: Shepherd, Lori 

[Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Ben Bolker]

Dear r-devel folks,

  [if this is more appropriate for r-pkg-devel please let me know and
I'll repost it over there ...]

I'm writing to ask for help with some R/C++ integration idioms that are
used in a package I'm maintaining, that are unfamilar to me, and that
are now being flagged as problematic by Tomas Kalibera's 'rchk'
machinery (https://github.com/kalibera/rchk); results are here
https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out

The problem is with constructions like

::Rf_eval(::Rf_lang2(fun, arg), d_rho)

I *think* this means "construct a two-element pairlist from fun and arg,
then evaluate it within expression d_rho"

This leads to warnings like

"calling allocating function Rf_eval with argument allocated using Rf_lang2"

Is this a false positive or ... ? Can anyone help interpret this?

Not sure why this idiom was used in the first place: speed? (e.g., see
https://stat.ethz.ch/pipermail/r-devel/2019-June/078020.html ) Should I
be rewriting to avoid Rf_eval entirely in favor of using a Function?
(i.e., as commented in
https://stackoverflow.com/questions/37845012/rcpp-function-slower-than-rf-eval
: "Also, calling Rf_eval() directly from a C++ context is dangerous as R
errors (ie, C longjmps) will bypass the destructors of C++ objects and
leak memory / cause undefined behavior in general. Rcpp::Function tries
to make sure that doesn't happen.")

 Any tips, corrections, pointers to further documentation, etc. would be
most welcome ... Web searching for this stuff hasn't gotten me very far,
and it seems to be deeper than most of the introductory material I can
find (including the Rcpp vignettes) ...

  cheers
   Ben Bolker

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

Re: [R-pkg-devel] OpenMP variable not specified in enclosing 'parallel'

[Ivan Krylov]

On Mon, 23 Mar 2020 15:29:20 +0100
Emil Sjørup  wrote:

> const int iMaxLag = 20;

> error: ‘iMaxLag’ not specified in enclosing ‘parallel’

> error: ‘iMaxLag’ is predetermined ‘shared’ for ‘shared’

This looks like a compiler bug to me. g++ seems to forget the rule that
"const" variables are supposed to be shared despite the default(none)
clause.

In a similar situation (g++ being confused about the sharing
status of a hidden temporary variable it had internally created) I had
to remove default(none) and leave a comment explaining that the code
would not compile otherwise.

-- 
Best regards,
Ivan

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

Re: [Rd] unlink() on "~" removes the home directory

[Gábor Csárdi]

Thanks,

I saw the commit, and it seems like a great fix to me!

Best,
Gabor

On Mon, Mar 23, 2020 at 5:04 PM Tomas Kalibera  wrote:
>
> To clarify, these issues are about deleting the contents of the home
> directory, not the directory itself, which cannot be deleted by ordinary
> users on today's systems. Unfortunately this has to be fixed in the code
> that calls unlink(), such code must be aware of the expansions. The "R
> CMD build" case as you write has been fixed, if anyone finds any other
> instance of this problem in base R, please report, it will be fixed as
> well. The new argument "expand" has been added to unlink() to make these
> fixes easier.
>
> A variation on what you propose: tilde ("~") is now treated the same way
> as "." and ".." have already been by unlink(), which means it will never
> be considered for deletion (not even with expand=TRUE). There are still
> a number of ways to delete the contents of one's home directory,
> including tilde expansion with user name, with directory separators,
> etc.  This special treatment of "~" will prevent only one pattern of the
> problem. One should always be careful when recursively/programmatically
> deleting files.
>
> Also, the new behavior can cause trouble in some cases when a file or
> directory named tilde exists, but hopefully not as bad as deleting the
> contents of user home directory. In principle, such file can still be
> deleted from R using a combination of tilde and wildcards with wildcard
> expansion enabled.
>
> Best
> Tomas
>
> On 2/26/20 11:47 PM, Gábor Csárdi wrote:
> > !!! DON'T TRY THE CODE IN THIS EMAIL AT HOME !!!
> >
> > Well, unlink() does what it is supposed to do, so you could argue that
> > there is nothing wrong with it. Also, nobody would call unlink() on
> > "~", right?
> >
> > The situation is not so simple, however. E.g. if you happen to have a
> > directory called "~", and you iterate over all files and directories
> > to selectively remove some of them, then your code might end up
> > calling unlink on the local "~" directory, and then your home is gone.
> >
> > But you would not create a directory named "~", that is just asking
> > for trouble. Well, surely, _intentionally_ you would not do that.
> > Unintentionally, you might. E.g. something like this is enough:
> >
> > # Create a subpath within a base directory
> > badfun <- function(base = ".", path) {
> >dir.create(file.path(base, path), recursive = TRUE, showWarnings = FALSE)
> > }
> > badfun(path = "~/foo")
> >
> > (If you did run this, be very careful how you remove the directory called 
> > "~"!)
> >
> > A real example is `R CMD build` which deletes the home directory of
> > the current user if the root of the package contains a non-empty "~"
> > directory. Luckily this is now fixed in R-devel, so R 4.0.0 will do
> > better. (R 3.6.3 will not.) See
> > https://github.com/wch/r-source/commit/1d4f7aa1dac427ea2213d1f7cd7b5c16e896af22
> >
> > I have seen several bug reports about various packages (that call R
> > CMD build) removing the home directory, so this indeed happens in
> > practice to a number of people. The commit above will fix `R CMD
> > build`, but it would be great to "fix" this in general.
> >
> > It seems pretty hard to prevent users from creating of a "~"
> > directory. But preventing unlink() from deleting "~" does not actually
> > seem too hard. If unlink() could just refuse removing "~" (when expand
> > = TRUE), that would be great. It seems to me that the current behavior
> > is very-very rarely intended, and its consequences are potentially
> > disastrous.
> >
> > If unlink("~", recursive = TRUE) errors, you can still remove a local
> > "~" file/dir with unlink("./~", ...). And you can still remove your
> > home directory if you really want to do that, with
> > unlink(path.expand("~"), ...). So no functionality is lost.
> >
> > Also, if anyone is aware of packages/functions that tend to create "~"
> > directories or files, please let me know.
> >
> > I would be happy to submit a patch for the new unlink("~") behavior.
> >
> > Thanks,
> > Gabor
> >
> > __
> > 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] unlink() on "~" removes the home directory

[Tomas Kalibera]

To clarify, these issues are about deleting the contents of the home 
directory, not the directory itself, which cannot be deleted by ordinary 
users on today's systems. Unfortunately this has to be fixed in the code 
that calls unlink(), such code must be aware of the expansions. The "R 
CMD build" case as you write has been fixed, if anyone finds any other 
instance of this problem in base R, please report, it will be fixed as 
well. The new argument "expand" has been added to unlink() to make these 
fixes easier.


A variation on what you propose: tilde ("~") is now treated the same way 
as "." and ".." have already been by unlink(), which means it will never 
be considered for deletion (not even with expand=TRUE). There are still 
a number of ways to delete the contents of one's home directory, 
including tilde expansion with user name, with directory separators, 
etc.  This special treatment of "~" will prevent only one pattern of the 
problem. One should always be careful when recursively/programmatically 
deleting files.


Also, the new behavior can cause trouble in some cases when a file or 
directory named tilde exists, but hopefully not as bad as deleting the 
contents of user home directory. In principle, such file can still be 
deleted from R using a combination of tilde and wildcards with wildcard 
expansion enabled.


Best
Tomas

On 2/26/20 11:47 PM, Gábor Csárdi wrote:

!!! DON'T TRY THE CODE IN THIS EMAIL AT HOME !!!

Well, unlink() does what it is supposed to do, so you could argue that
there is nothing wrong with it. Also, nobody would call unlink() on
"~", right?

The situation is not so simple, however. E.g. if you happen to have a
directory called "~", and you iterate over all files and directories
to selectively remove some of them, then your code might end up
calling unlink on the local "~" directory, and then your home is gone.

But you would not create a directory named "~", that is just asking
for trouble. Well, surely, _intentionally_ you would not do that.
Unintentionally, you might. E.g. something like this is enough:

# Create a subpath within a base directory
badfun <- function(base = ".", path) {
   dir.create(file.path(base, path), recursive = TRUE, showWarnings = FALSE)
}
badfun(path = "~/foo")

(If you did run this, be very careful how you remove the directory called "~"!)

A real example is `R CMD build` which deletes the home directory of
the current user if the root of the package contains a non-empty "~"
directory. Luckily this is now fixed in R-devel, so R 4.0.0 will do
better. (R 3.6.3 will not.) See
https://github.com/wch/r-source/commit/1d4f7aa1dac427ea2213d1f7cd7b5c16e896af22

I have seen several bug reports about various packages (that call R
CMD build) removing the home directory, so this indeed happens in
practice to a number of people. The commit above will fix `R CMD
build`, but it would be great to "fix" this in general.

It seems pretty hard to prevent users from creating of a "~"
directory. But preventing unlink() from deleting "~" does not actually
seem too hard. If unlink() could just refuse removing "~" (when expand
= TRUE), that would be great. It seems to me that the current behavior
is very-very rarely intended, and its consequences are potentially
disastrous.

If unlink("~", recursive = TRUE) errors, you can still remove a local
"~" file/dir with unlink("./~", ...). And you can still remove your
home directory if you really want to do that, with
unlink(path.expand("~"), ...). So no functionality is lost.

Also, if anyone is aware of packages/functions that tend to create "~"
directories or files, please let me know.

I would be happy to submit a patch for the new unlink("~") behavior.

Thanks,
Gabor

__
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] Inconsistant result for normalizePath on Windows

[William Dunlap via R-devel]

Re the trailing path separator - should file.path() be changed to not
produce doubled path separators when an argument has a trailing path
separator?

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Mar 23, 2020 at 9:24 AM Tomas Kalibera 
wrote:

>
> Hi Jiefei,
>
> the change in handling trailing path separators is not on purpose, but
> is a byproduct of a new implementation of normalizePath, which now
> handles symbolic links and normalizes case in long path names. It is not
> documented what happens to trailing separators, and hence portable
> programs should not depend on it. I don't think it is a property that
> should be documented/specified. The behavior of normalizePath is way too
> complicated already and it's result is OS-specific anyway.
>
> In R-devel as well as in 3.6, the trailing separator is preserved when
> the path does not exist - simply, the original path is returned. When
> the path does exist, R-devel removes the trailing separator but R 3.6
> does not, which is because the underlying Windows API call to implement
> it is now different. The new behavior reflects what
> GetFinalPathNameByHandle returns, which is a function now used for
> normalization also in other language runtimes on Windows. I think the
> new behavior is better: paths differing only in the trailing separator
> will be normalized to the same path.
>
> Best
> Tomas
>
> On 3/23/20 4:39 PM, Wang Jiefei wrote:
> > Hi all,
> >
> > I saw a quite surprising result in the devel R when using the function
> > *normalizePath*. If the input is a path to a folder, the function returns
> > an absolute path with/without a slash at the end depending on the
> existence
> > of the folder. I know both results are valid on Windows but this behavior
> > is different than R3.6, I do not know if the change in the devel version
> is
> > made on purpose. Here is a minimal example, suppose that the folder
> > `C:/windows1/` does not exist.
> >
> >> normalizePath("C:/windows/", mustWork = FALSE)
> > [1] "C:\\Windows"
> >> normalizePath("C:/windows1/", mustWork = FALSE)
> > [1] "C:\\windows1\\"
> >
> >
> > In R 3.6, the return value always ends with a slash if the input ends
> with
> > a slash. From the NEWS file, It seems like there are some changes to
> > *normalizePath* but none of them should be relevant, it might be an
> > unintentional result introduced by the update.
> >
> > Best,
> > Jiefei
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] Inconsistant result for normalizePath on Windows

[Tomas Kalibera]

Hi Jiefei,

the change in handling trailing path separators is not on purpose, but 
is a byproduct of a new implementation of normalizePath, which now 
handles symbolic links and normalizes case in long path names. It is not 
documented what happens to trailing separators, and hence portable 
programs should not depend on it. I don't think it is a property that 
should be documented/specified. The behavior of normalizePath is way too 
complicated already and it's result is OS-specific anyway.


In R-devel as well as in 3.6, the trailing separator is preserved when 
the path does not exist - simply, the original path is returned. When 
the path does exist, R-devel removes the trailing separator but R 3.6 
does not, which is because the underlying Windows API call to implement 
it is now different. The new behavior reflects what 
GetFinalPathNameByHandle returns, which is a function now used for 
normalization also in other language runtimes on Windows. I think the 
new behavior is better: paths differing only in the trailing separator 
will be normalized to the same path.


Best
Tomas

On 3/23/20 4:39 PM, Wang Jiefei wrote:

Hi all,

I saw a quite surprising result in the devel R when using the function
*normalizePath*. If the input is a path to a folder, the function returns
an absolute path with/without a slash at the end depending on the existence
of the folder. I know both results are valid on Windows but this behavior
is different than R3.6, I do not know if the change in the devel version is
made on purpose. Here is a minimal example, suppose that the folder
`C:/windows1/` does not exist.

   > normalizePath("C:/windows/", mustWork = FALSE)
[1] "C:\\Windows"

normalizePath("C:/windows1/", mustWork = FALSE)

[1] "C:\\windows1\\"


In R 3.6, the return value always ends with a slash if the input ends with
a slash. From the NEWS file, It seems like there are some changes to
*normalizePath* but none of them should be relevant, it might be an
unintentional result introduced by the update.

Best,
Jiefei

[[alternative HTML version deleted]]

__
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

[Rd] Inconsistant result for normalizePath on Windows

[Wang Jiefei]

Hi all,

I saw a quite surprising result in the devel R when using the function
*normalizePath*. If the input is a path to a folder, the function returns
an absolute path with/without a slash at the end depending on the existence
of the folder. I know both results are valid on Windows but this behavior
is different than R3.6, I do not know if the change in the devel version is
made on purpose. Here is a minimal example, suppose that the folder
`C:/windows1/` does not exist.

  > normalizePath("C:/windows/", mustWork = FALSE)
[1] "C:\\Windows"
> normalizePath("C:/windows1/", mustWork = FALSE)
[1] "C:\\windows1\\"


In R 3.6, the return value always ends with a slash if the input ends with
a slash. From the NEWS file, It seems like there are some changes to
*normalizePath* but none of them should be relevant, it might be an
unintentional result introduced by the update.

Best,
Jiefei

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Problems with BiocCredentials

[Turaga, Nitesh]

Hi Saskia,

The email it is registered to is freyta...@wehi.edu.au.

So, you'll first have to "activate" your account before you can do anything 
else.

https://git.bioconductor.org/BiocCredentials/account_activation/

Once you activate your account, please add your SSH keys. You will then be able 
to access your package.

Nitesh 

> On Mar 22, 2020, at 8:45 PM, Saskia Freytag  wrote:
> 
> Hi,
> 
> I am trying to push changes to the development release for my package 
> RUVcorr. Unfortunately, when I set it up, I used SVN. Now I am unable to 
> access my package. I have tried to log in to the BiocCredentials app, but 
> have also been unsuccessful. It does not seem to remember me (I cannot get 
> the password reset). Is there anyone who could help me?
> 
> Cheers,
> 
> Saskia
> 
> ___
> 
> The information in this email is confidential and =\ i...{{dropped:17}}

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

Re: [R-pkg-devel] Problem with Check --as-cran

[Tomas Kalibera]

The problem is with

if (class(data) != "matrix") stop("The data field should be an array or 
a data frame")


Please use inherits() instead of checking class(), see this for more details
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again

Best
Tomas



On 3/23/20 3:30 PM, LUIS ALFONSO PEREZ MARTOS wrote:



El 23 mar 2020, a las 15:05, LUIS ALFONSO PEREZ MARTOS  
escribió:

Good morning, everyone,

I am developing an R-package and when I check package I get this right. 
Attached image.



But when I upload the package to cran they tell me the next error and I don't 
know how to fix it.

https://win-builder.r-project.org/incoming_pretest/Clustering_1.0.0_20200322_181919/Windows/00check.log
 


Best regards

__
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: [R-pkg-devel] Problem with Check --as-cran

[LUIS ALFONSO PEREZ MARTOS]

> El 23 mar 2020, a las 15:05, LUIS ALFONSO PEREZ MARTOS  
> escribió:
> 
> Good morning, everyone,
> 
> I am developing an R-package and when I check package I get this right. 
> Attached image.
> 
> 
> 
> But when I upload the package to cran they tell me the next error and I don't 
> know how to fix it.
> 
> https://win-builder.r-project.org/incoming_pretest/Clustering_1.0.0_20200322_181919/Windows/00check.log
>  
> 
> 
> Best regards

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

[R-pkg-devel] OpenMP variable not specified in enclosing 'parallel'

[Emil Sjørup]

Hi,


I am getting an error message during pre-checks when I upload a new 
version of my package to CRAN, and I need help.


See: 
https://win-builder.r-project.org/incoming_pretest/DriftBurstHypothesis_0.3.0.1_20200322_134148/Debian/00install.out 




The package installs just fine on windows, and on my system.


It seems to me that the message tells me that I have an undeclared 
variable in the parallel setup.


So, if I add the variable to the shared variables in the setup, I get 
the following error message:



error: ‘iMaxLag’ is predetermined ‘shared’ for ‘shared’


Passing the variable to the private variable in the setup doesn't work 
either.


Am I misunderstanding the error or is something weird going on?



For the interested, the source being uploaded can be found in:

ftp://cran.r-project.org/incoming/archive/

under DriftBurstHypothesis_0.3.0.1.tar.gz


Best,

Emil

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

[R-pkg-devel] CRAN upload checks

[Christopher Jones]

Chasing up a longstanding issue 
 with 
getting a package patch update 
uploaded to CRAN. We've never raised any reply to emails sent to 
cran-submissi...@r-project.org. The most recent mail was on 17th March. Is 
there a 
better email address to use?

The package is https://cran.r-project.org/web/packages/ROracle/index.html This 
needs a 3rd party (i.e. Oracle provided) SDK package to compile. Since 
that original thread, the SDK package is now available via wget or curl without 
login or click-through.

Chris

-- 
https://twitter.com/ghrd


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor package IMMAN

[Shepherd, Lori]

I would do a

git fetch --all   # get all branches
git pull upstream master   # pulls changes from Bioconductor git server

# resolve any merge conflicts that arise.

It is good practice to always pull from origin and upstream before making any 
changes to code to make sure the code base is updated.

Let us know if you have any further trouble.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: minoo ashtiani 
Sent: Monday, March 23, 2020 6:26 AM
To: Shepherd, Lori ; bioc-devel@r-project.org 

Subject: Re: Bioconductor package IMMAN

Hi Lori,

Thanks for the update. I edited the vignette in which the platform error comes 
from that. I updated the by using

  1.

 git push origin master


  2.

command and it was OK, however when I wanted to run the second command line

  1.

git push upstream master


  2.

I faced error and I have no idea how to fix it. Here is a summary of the output 
of the two commands line:

$ git push origin master
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 409 bytes | 136.00 KiB/s, done.
Total 5 (delta 3), reused 0 (delta 0)
To git.bioconductor.org:packages/IMMAN.git
   05b59cb..01a56eb  master -> master

$ git push upstream master
To https://github.com/Minoo-ASTY/IMMAN.git
 ! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/Minoo-ASTY/IMMAN.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Is there any problem with or getting the output of "git push original master" 
is enough?

All the bests,
Minoo

On Mon, Mar 16, 2020 at 2:50 PM Shepherd, Lori 
mailto:lori.sheph...@roswellpark.org>> wrote:
Dear package maintainer,

Please be aware your package continues to fail on Bioconductor devel 3.11.   
Bioconductor release is scheduled for Tuesday April 28th. We appreciate
your quick response in this matter. If your package remains broken we will begin
the deprecation process to remove the package from Bioconductor.

http://bioconductor.org/checkResults/devel/bioc-LATEST/IMMAN/





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.


--
Minoo Ashtiani,

Research Assistant @ Russell Lab, Heidelberg University
+491605667176 Germany
minoo.ashti...@bioquant.uni-heidelberg.de

for accessing papers: 
https://scholar.google.com/citations?user=nnCwxpEJ=en



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] Grid pmax Unusual Result In Alpha Version

[Dario Strbenac]

Sorry, I was dragging the laptop's cursor towards the Discard button but it 
activated on Send instead. Please ignore or delete from mailing archive.


From: Martin Maechler 
Sent: Monday, 23 March 2020 11:10 PM
To: Dario Strbenac
Subject: Re: [Rd] Grid pmax Unusual Result In Alpha Version

> Dario Strbenac
> on Mon, 23 Mar 2020 10:19:46 + writes:

> Hello,
> I find that the width of a plot is zero when three grobs are input but is 
as expected when any subset of two of the three grobs are used.

Please Dario,
do send reproducible code  with almost *EVERY* posting to R-devel !


> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia

> __
> R-devel@r-project.org mailing list
> 
https://protect-au.mimecast.com/s/SBS7CwV1vMf0xJVOUVR_hV?domain=stat.ethz.ch

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

Re: [Bioc-devel] Bioconductor package IMMAN

[minoo ashtiani]

Hi Lori,

Thanks for the update. I edited the vignette in which the platform error
comes from that. I updated the by using

   1.

git push origin master

   2.

command and it was OK, however when I wanted to run the second command line

   1.

   git push upstream master

   2.

I faced error and I have no idea how to fix it. Here is a summary of the
output of the two commands line:

$ git push origin master
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 409 bytes | 136.00 KiB/s, done.
Total 5 (delta 3), reused 0 (delta 0)
To git.bioconductor.org:packages/IMMAN.git
   05b59cb..01a56eb  master -> master

$ git push upstream master
To https://github.com/Minoo-ASTY/IMMAN.git
 ! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/Minoo-ASTY/IMMAN.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Is there any problem with or getting the output of "git push original
master" is enough?

All the bests,
Minoo

On Mon, Mar 16, 2020 at 2:50 PM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> Dear package maintainer,
>
> Please be aware your package continues to fail on Bioconductor devel
> 3.11.   Bioconductor release is scheduled for Tuesday April 28th. We
> appreciate
> your quick response in this matter. If your package remains broken we will
> begin
> the deprecation process to remove the package from Bioconductor.
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/IMMAN/
>
>
>
>
> 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.



-- 
Minoo Ashtiani,

Research Assistant @ Russell Lab, Heidelberg University
+491605667176 Germany
minoo.ashti...@bioquant.uni-heidelberg.de

for accessing papers:
https://scholar.google.com/citations?user=nnCwxpEJ=en

[[alternative HTML version deleted]]

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

[Rd] Grid pmax Unusual Result In Alpha Version

[Dario Strbenac]

Hello,

I find that the width of a plot is zero when three grobs are input but is as 
expected when any subset of two of the three grobs are used.



--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia

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