Re: [R-pkg-devel] CRAN review

[Ralf Stubner]

On 29.03.19 17:05, William Dunlap wrote:
> It looks like it is not boost but RcppEigen that has the call to
> std::rand() that volesti/src/rotating.cpp contains.
> 
> RcppEigen/include/Eigen/src/Core/MathFunctions.h:
>   static inline Scalar run(const Scalar& x, const Scalar& y)
>   {
> return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
>   }

The link between the two seems to be rounding.h which contains:

  // pick a random rotation
  MT R = MT::Random(n,n);

cheerio
ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] CRAN review

[William Dunlap]

One can use 'g++ -E' to find the which include file is the culprit.  E.g.,

% g++ -c -E -I`R RHOME`/include -I`R RHOME`/site-library/Rcpp/include -I`R
RHOME`/site-library/RcppEigen/include -Iexternal/LPsolve_src/run_headers
-Iexternal/minimum_ellipsoid -Iinclude -Iinclude/volume
-Iinclude/generators -Iinclude/samplers -Iinclude/annealing
-Iinclude/convex_bodies -std=gnu++11 rotating.cpp | egrep '\|^#
*[0-9]+' | grep -C 1 '\'
# 315 "/usr/include/stdlib.h" 2 3 4
extern int rand (void) throw ();
# 1 "/usr/include/alloca.h" 1 3 4
--
# 114 "/usr/include/c++/4.8.2/cstdlib" 3
  using ::rand;
# 196 "/usr/include/c++/4.8.2/cstdlib" 3
--
# 5185 "/usr/include/c++/4.8.2/bits/stl_algo.h" 3
 + std::rand() % ((__i - __first) + 1);
# 5218 "/usr/include/c++/4.8.2/bits/stl_algo.h" 3
--
# 455
"/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/src/Core/MathFunctions.h"
return x + (y-x) * Scalar(std::rand()) / Scalar(2147483647);
  offset = (std::size_t(std::rand()) * multiplier) / divisor;
return Scalar((std::rand() >> shift) - offset);
# 689
"/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/src/Core/MathFunctions.h"
--
# 295
"/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/src/Core/arch/CUDA/Half.h"
return x + (y-x) * half(float(std::rand()) / float(2147483647));
# 412 "/home/R/R-3.5.2/lib64/R/site-library/RcppEigen/include/Eigen/Core" 2

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 9:37 AM William Dunlap  wrote:

> Oops, RcppEigen does contain compiled code, but its header files include
> much more code that doesn't get checked because it is not used in
> RcppEigen.so.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 9:35 AM William Dunlap  wrote:
>
>> The check only looks at compiled code.  BH contains only headers, no
>> compiled code.
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>> On Fri, Mar 29, 2019 at 9:27 AM Maxime Turgeon <
>> maxime.turg...@mail.mcgill.ca> wrote:
>>
>>> Hi Bill,
>>>
>>> Maybe I'm missing something, but if RcppEigen were the cause of the
>>> NOTE, wouldn't RcppEigen also get the same NOTE? However, it does not:
>>> https://cran.r-project.org/web/checks/check_results_RcppEigen.html
>>>
>>> And for what it's worth, neither does BH:
>>> https://cran.r-project.org/web/checks/check_results_BH.html
>>>
>>> Max
>>> --
>>> *From:* R-package-devel  on
>>> behalf of William Dunlap 
>>> *Sent:* March 29, 2019 12:05 PM
>>> *To:* Vissarion Fisikopoulos
>>> *Cc:* R Package Development
>>> *Subject:* Re: [R-pkg-devel] CRAN review
>>>
>>> It looks like it is not boost but RcppEigen that has the call to
>>> std::rand() that volesti/src/rotating.cpp contains.
>>>
>>> RcppEigen/include/Eigen/src/Core/MathFunctions.h:
>>>   static inline Scalar run(const Scalar& x, const Scalar& y)
>>>   {
>>> return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
>>>   }
>>>
>>>
>>> Bill Dunlap
>>> TIBCO Software
>>> wdunlap tibco.com
>>>
>>>
>>> On Fri, Mar 29, 2019 at 8:43 AM William Dunlap 
>>> wrote:
>>>
>>> > > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
>>> > > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
>>> > > R’s internal random number generation routines as it is proposed in
>>> > > `Writing R Extensions`. Moreover if you run in folder `/src`:
>>> > > $ grep -r 'rand()'
>>> > > You just get:
>>> > > `utils.c:  range *= (LPSREAL) unif_rand();`
>>> > > which is our replacement. If you replace `rand()` with `srand` in
>>> grep
>>> > > search you get a null result.
>>> > > This NOTE appears because of our functions in `/src/include/samplers`
>>> > > where word `rand` appears a lot of times, for example
>>> > > `rand_point_generator()`.
>>> >
>>> > I don't think the note about using 'rand' comes from looking at strings
>>> > in the source code.  It is probably looking at undefined symbols in the
>>> > symbol table of the compiled and linked code with something like the
>>> > following
>>> >
>>> > % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' |
>>> grep
>>> > rand
>>> > volesti/src/lp_solve/lp_rlp.o: U storevarandweight
>>> > volesti/src/lp_solve/lp_price.o: U rand_uniform
>>> > volesti/src/lp_solve/lp_utils.o: U unif_rand
>>> > volesti/src/lp_solve/lp_lib.o: U rand_uniform
>>> > volesti/src/rotating.o: U rand
>>> > volesti/src/volesti.so: U rand@@GLIBC_2.2.5
>>> > volesti/src/volesti.so: U unif_rand
>>> >
>>> > You will have to poke through the boost headers or docs to see how to
>>> avoid
>>> > using rand in volesti/src/rotating.cpp.
>>> >
>>> > Bill Dunlap
>>> > TIBCO Software
>>> > wdunlap tibco.com
>>> >
>>> >
>>> > On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos <
>>> fisi...@gmail.com>
>>> > wrote:
>>> >
>>> >> Dear all,
>>> >>
>>> >> @Henrik: thanks a lot for your 

Re: [R-pkg-devel] CRAN review

[William Dunlap]

The check only looks at compiled code.  BH contains only headers, no
compiled code.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 9:27 AM Maxime Turgeon <
maxime.turg...@mail.mcgill.ca> wrote:

> Hi Bill,
>
> Maybe I'm missing something, but if RcppEigen were the cause of the NOTE,
> wouldn't RcppEigen also get the same NOTE? However, it does not:
> https://cran.r-project.org/web/checks/check_results_RcppEigen.html
>
> And for what it's worth, neither does BH:
> https://cran.r-project.org/web/checks/check_results_BH.html
>
> Max
> --
> *From:* R-package-devel  on behalf
> of William Dunlap 
> *Sent:* March 29, 2019 12:05 PM
> *To:* Vissarion Fisikopoulos
> *Cc:* R Package Development
> *Subject:* Re: [R-pkg-devel] CRAN review
>
> It looks like it is not boost but RcppEigen that has the call to
> std::rand() that volesti/src/rotating.cpp contains.
>
> RcppEigen/include/Eigen/src/Core/MathFunctions.h:
>   static inline Scalar run(const Scalar& x, const Scalar& y)
>   {
> return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
>   }
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 8:43 AM William Dunlap  wrote:
>
> > > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> > > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> > > R’s internal random number generation routines as it is proposed in
> > > `Writing R Extensions`. Moreover if you run in folder `/src`:
> > > $ grep -r 'rand()'
> > > You just get:
> > > `utils.c:  range *= (LPSREAL) unif_rand();`
> > > which is our replacement. If you replace `rand()` with `srand` in grep
> > > search you get a null result.
> > > This NOTE appears because of our functions in `/src/include/samplers`
> > > where word `rand` appears a lot of times, for example
> > > `rand_point_generator()`.
> >
> > I don't think the note about using 'rand' comes from looking at strings
> > in the source code.  It is probably looking at undefined symbols in the
> > symbol table of the compiled and linked code with something like the
> > following
> >
> > % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' |
> grep
> > rand
> > volesti/src/lp_solve/lp_rlp.o: U storevarandweight
> > volesti/src/lp_solve/lp_price.o: U rand_uniform
> > volesti/src/lp_solve/lp_utils.o: U unif_rand
> > volesti/src/lp_solve/lp_lib.o: U rand_uniform
> > volesti/src/rotating.o: U rand
> > volesti/src/volesti.so: U rand@@GLIBC_2.2.5
> > volesti/src/volesti.so: U unif_rand
> >
> > You will have to poke through the boost headers or docs to see how to
> avoid
> > using rand in volesti/src/rotating.cpp.
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> >
> > On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos <
> fisi...@gmail.com>
> > wrote:
> >
> >> Dear all,
> >>
> >> @Henrik: thanks a lot for your reply.
> >>
> >> I did one more submission (the third) and I am posting below my answer
> >> to the automatic cran email with 2 NOTES.
> >>
> >> Looking forward to your feedback.
> >>
> >> Best regards,
> >> Vissarion.
> >>
> >> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos  >
> >> wrote:
> >> >
> >> > Dear all,
> >> >
> >> > We got the results from the automated check for our package. There are
> >> > two NOTEs in both checks in Windows and Debian. We are sure that the
> >> > rejections are false positive, so with this e-mail we try to explain
> >> > why. Please find our explanations below.
> >> >
> >> > On Thu, 28 Mar 2019 at 16:40, 
> wrote:
> >> > >
> >> > > Dear maintainer,
> >> > >
> >> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
> >> automatically, please see the following pre-tests:
> >> > > Windows: <
> >>
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
> >> >
> >> > > Status: 2 NOTEs
> >> > > Debian: <
> >>
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
> >> >
> >> > > Status: 2 NOTEs
> >> > >
> >> > >
> >> > >
> >> > > Please fix all problems and resubmit a fixed version via the
> webform.
> >> > > If you are not sure how to fix the problems shown, please ask for
> >> help on the R-package-devel mailing list:
> >> > > 
> >> > > If you are fairly certain the rejection is a false positive, please
> >> reply-all to this message and explain.
> >> > >
> >> > > More details are given in the directory:
> >> > > <
> >>
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/
> >> >
> >> > > The files will be removed after roughly 7 days.
> >> > >
> >> > > No strong reverse dependencies to be checked.
> >> > >
> >> > > Best regards,
> >> > > CRAN teams' auto-check service
> >> > > Flavor: r-devel-linux-x86_64-debian-gcc, 

Re: [R-pkg-devel] CRAN review

[Ralf Stubner]

On 29.03.19 17:27, Maxime Turgeon wrote:
> Maybe I'm missing something, but if RcppEigen were the cause of the NOTE, 
> wouldn't RcppEigen also get the same NOTE? However, it does not: 
> https://cran.r-project.org/web/checks/check_results_RcppEigen.html
> 
> And for what it's worth, neither does BH: 
> https://cran.r-project.org/web/checks/check_results_BH.html

Both RcppEigen and BH provide header only libraries which are only
compiled by packages making use of it. And the rand symbol is only
searched for in the resulting/compiled libraries.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] CRAN review

[Maxime Turgeon]

Hi Bill,

Maybe I'm missing something, but if RcppEigen were the cause of the NOTE, 
wouldn't RcppEigen also get the same NOTE? However, it does not: 
https://cran.r-project.org/web/checks/check_results_RcppEigen.html

And for what it's worth, neither does BH: 
https://cran.r-project.org/web/checks/check_results_BH.html

Max

From: R-package-devel  on behalf of 
William Dunlap 
Sent: March 29, 2019 12:05 PM
To: Vissarion Fisikopoulos
Cc: R Package Development
Subject: Re: [R-pkg-devel] CRAN review

It looks like it is not boost but RcppEigen that has the call to
std::rand() that volesti/src/rotating.cpp contains.

RcppEigen/include/Eigen/src/Core/MathFunctions.h:
  static inline Scalar run(const Scalar& x, const Scalar& y)
  {
return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
  }


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 8:43 AM William Dunlap  wrote:

> > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> > R’s internal random number generation routines as it is proposed in
> > `Writing R Extensions`. Moreover if you run in folder `/src`:
> > $ grep -r 'rand()'
> > You just get:
> > `utils.c:  range *= (LPSREAL) unif_rand();`
> > which is our replacement. If you replace `rand()` with `srand` in grep
> > search you get a null result.
> > This NOTE appears because of our functions in `/src/include/samplers`
> > where word `rand` appears a lot of times, for example
> > `rand_point_generator()`.
>
> I don't think the note about using 'rand' comes from looking at strings
> in the source code.  It is probably looking at undefined symbols in the
> symbol table of the compiled and linked code with something like the
> following
>
> % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' | grep
> rand
> volesti/src/lp_solve/lp_rlp.o: U storevarandweight
> volesti/src/lp_solve/lp_price.o: U rand_uniform
> volesti/src/lp_solve/lp_utils.o: U unif_rand
> volesti/src/lp_solve/lp_lib.o: U rand_uniform
> volesti/src/rotating.o: U rand
> volesti/src/volesti.so: U rand@@GLIBC_2.2.5
> volesti/src/volesti.so: U unif_rand
>
> You will have to poke through the boost headers or docs to see how to avoid
> using rand in volesti/src/rotating.cpp.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos 
> wrote:
>
>> Dear all,
>>
>> @Henrik: thanks a lot for your reply.
>>
>> I did one more submission (the third) and I am posting below my answer
>> to the automatic cran email with 2 NOTES.
>>
>> Looking forward to your feedback.
>>
>> Best regards,
>> Vissarion.
>>
>> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos 
>> wrote:
>> >
>> > Dear all,
>> >
>> > We got the results from the automated check for our package. There are
>> > two NOTEs in both checks in Windows and Debian. We are sure that the
>> > rejections are false positive, so with this e-mail we try to explain
>> > why. Please find our explanations below.
>> >
>> > On Thu, 28 Mar 2019 at 16:40,  wrote:
>> > >
>> > > Dear maintainer,
>> > >
>> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
>> automatically, please see the following pre-tests:
>> > > Windows: <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
>> >
>> > > Status: 2 NOTEs
>> > > Debian: <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
>> >
>> > > Status: 2 NOTEs
>> > >
>> > >
>> > >
>> > > Please fix all problems and resubmit a fixed version via the webform.
>> > > If you are not sure how to fix the problems shown, please ask for
>> help on the R-package-devel mailing list:
>> > > 
>> > > If you are fairly certain the rejection is a false positive, please
>> reply-all to this message and explain.
>> > >
>> > > More details are given in the directory:
>> > > <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/
>> >
>> > > The files will be removed after roughly 7 days.
>> > >
>> > > No strong reverse dependencies to be checked.
>> > >
>> > > Best regards,
>> > > CRAN teams' auto-check service
>> > > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
>> > > Check: CRAN incoming feasibility, Result: NOTE
>> > >   Maintainer: 'Vissarion Fisikopoulos <
>> vissarion.fisikopou...@gmail.com>'
>> > >
>> > >   New submission
>> > >
>> > >   Possibly mis-spelled words in DESCRIPTION:
>> > > Minkowski (9:17)
>> > > Polytopes (4:49)
>> > > Volesti (7:71)
>> > > polytopes (8:39, 10:83)
>> > > volesti (7:50)
>> > > zonotopes (9:44)
>> > These words, except of 'volesti' (which is the name of our package),
>> > describe 

Re: [R-pkg-devel] CRAN review

[William Dunlap]

It looks like it is not boost but RcppEigen that has the call to
std::rand() that volesti/src/rotating.cpp contains.

RcppEigen/include/Eigen/src/Core/MathFunctions.h:
  static inline Scalar run(const Scalar& x, const Scalar& y)
  {
return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);
  }


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 8:43 AM William Dunlap  wrote:

> > Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> > R’s internal random number generation routines as it is proposed in
> > `Writing R Extensions`. Moreover if you run in folder `/src`:
> > $ grep -r 'rand()'
> > You just get:
> > `utils.c:  range *= (LPSREAL) unif_rand();`
> > which is our replacement. If you replace `rand()` with `srand` in grep
> > search you get a null result.
> > This NOTE appears because of our functions in `/src/include/samplers`
> > where word `rand` appears a lot of times, for example
> > `rand_point_generator()`.
>
> I don't think the note about using 'rand' comes from looking at strings
> in the source code.  It is probably looking at undefined symbols in the
> symbol table of the compiled and linked code with something like the
> following
>
> % find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' | grep
> rand
> volesti/src/lp_solve/lp_rlp.o: U storevarandweight
> volesti/src/lp_solve/lp_price.o: U rand_uniform
> volesti/src/lp_solve/lp_utils.o: U unif_rand
> volesti/src/lp_solve/lp_lib.o: U rand_uniform
> volesti/src/rotating.o: U rand
> volesti/src/volesti.so: U rand@@GLIBC_2.2.5
> volesti/src/volesti.so: U unif_rand
>
> You will have to poke through the boost headers or docs to see how to avoid
> using rand in volesti/src/rotating.cpp.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos 
> wrote:
>
>> Dear all,
>>
>> @Henrik: thanks a lot for your reply.
>>
>> I did one more submission (the third) and I am posting below my answer
>> to the automatic cran email with 2 NOTES.
>>
>> Looking forward to your feedback.
>>
>> Best regards,
>> Vissarion.
>>
>> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos 
>> wrote:
>> >
>> > Dear all,
>> >
>> > We got the results from the automated check for our package. There are
>> > two NOTEs in both checks in Windows and Debian. We are sure that the
>> > rejections are false positive, so with this e-mail we try to explain
>> > why. Please find our explanations below.
>> >
>> > On Thu, 28 Mar 2019 at 16:40,  wrote:
>> > >
>> > > Dear maintainer,
>> > >
>> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
>> automatically, please see the following pre-tests:
>> > > Windows: <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
>> >
>> > > Status: 2 NOTEs
>> > > Debian: <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
>> >
>> > > Status: 2 NOTEs
>> > >
>> > >
>> > >
>> > > Please fix all problems and resubmit a fixed version via the webform.
>> > > If you are not sure how to fix the problems shown, please ask for
>> help on the R-package-devel mailing list:
>> > > 
>> > > If you are fairly certain the rejection is a false positive, please
>> reply-all to this message and explain.
>> > >
>> > > More details are given in the directory:
>> > > <
>> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/
>> >
>> > > The files will be removed after roughly 7 days.
>> > >
>> > > No strong reverse dependencies to be checked.
>> > >
>> > > Best regards,
>> > > CRAN teams' auto-check service
>> > > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
>> > > Check: CRAN incoming feasibility, Result: NOTE
>> > >   Maintainer: 'Vissarion Fisikopoulos <
>> vissarion.fisikopou...@gmail.com>'
>> > >
>> > >   New submission
>> > >
>> > >   Possibly mis-spelled words in DESCRIPTION:
>> > > Minkowski (9:17)
>> > > Polytopes (4:49)
>> > > Volesti (7:71)
>> > > polytopes (8:39, 10:83)
>> > > volesti (7:50)
>> > > zonotopes (9:44)
>> > These words, except of 'volesti' (which is the name of our package),
>> > describe geometrical concepts.
>> >
>> > > Flavor: r-devel-windows-ix86+x86_64
>> > > Check: compiled code, Result: NOTE
>> > >   File 'volesti/libs/i386/volesti.dll':
>> > > Found 'rand', possibly from 'rand' (C)
>> > >   Object: 'rotating.o'
>> > >   File 'volesti/libs/x64/volesti.dll':
>> > > Found 'rand', possibly from 'rand' (C)
>> > >   Object: 'rotating.o'
>> > >
>> > >   Compiled code should not call entry points which might terminate R
>> nor
>> > >   write to stdout/stderr instead of to the console, nor use 

Re: [R-pkg-devel] CRAN review

[William Dunlap]

> Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> R’s internal random number generation routines as it is proposed in
> `Writing R Extensions`. Moreover if you run in folder `/src`:
> $ grep -r 'rand()'
> You just get:
> `utils.c:  range *= (LPSREAL) unif_rand();`
> which is our replacement. If you replace `rand()` with `srand` in grep
> search you get a null result.
> This NOTE appears because of our functions in `/src/include/samplers`
> where word `rand` appears a lot of times, for example
> `rand_point_generator()`.

I don't think the note about using 'rand' comes from looking at strings
in the source code.  It is probably looking at undefined symbols in the
symbol table of the compiled and linked code with something like the
following

% find volesti -iname "*o" | xargs nm -A -g --demangle | grep ' U ' | grep
rand
volesti/src/lp_solve/lp_rlp.o: U storevarandweight
volesti/src/lp_solve/lp_price.o: U rand_uniform
volesti/src/lp_solve/lp_utils.o: U unif_rand
volesti/src/lp_solve/lp_lib.o: U rand_uniform
volesti/src/rotating.o: U rand
volesti/src/volesti.so: U rand@@GLIBC_2.2.5
volesti/src/volesti.so: U unif_rand

You will have to poke through the boost headers or docs to see how to avoid
using rand in volesti/src/rotating.cpp.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Mar 29, 2019 at 2:12 AM Vissarion Fisikopoulos 
wrote:

> Dear all,
>
> @Henrik: thanks a lot for your reply.
>
> I did one more submission (the third) and I am posting below my answer
> to the automatic cran email with 2 NOTES.
>
> Looking forward to your feedback.
>
> Best regards,
> Vissarion.
>
> On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos 
> wrote:
> >
> > Dear all,
> >
> > We got the results from the automated check for our package. There are
> > two NOTEs in both checks in Windows and Debian. We are sure that the
> > rejections are false positive, so with this e-mail we try to explain
> > why. Please find our explanations below.
> >
> > On Thu, 28 Mar 2019 at 16:40,  wrote:
> > >
> > > Dear maintainer,
> > >
> > > package volesti_0.0.0.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> > > Windows: <
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Windows/00check.log
> >
> > > Status: 2 NOTEs
> > > Debian: <
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/Debian/00check.log
> >
> > > Status: 2 NOTEs
> > >
> > >
> > >
> > > Please fix all problems and resubmit a fixed version via the webform.
> > > If you are not sure how to fix the problems shown, please ask for help
> on the R-package-devel mailing list:
> > > 
> > > If you are fairly certain the rejection is a false positive, please
> reply-all to this message and explain.
> > >
> > > More details are given in the directory:
> > > <
> https://win-builder.r-project.org/incoming_pretest/volesti_0.0.0_20190328_151546/
> >
> > > The files will be removed after roughly 7 days.
> > >
> > > No strong reverse dependencies to be checked.
> > >
> > > Best regards,
> > > CRAN teams' auto-check service
> > > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> > > Check: CRAN incoming feasibility, Result: NOTE
> > >   Maintainer: 'Vissarion Fisikopoulos <
> vissarion.fisikopou...@gmail.com>'
> > >
> > >   New submission
> > >
> > >   Possibly mis-spelled words in DESCRIPTION:
> > > Minkowski (9:17)
> > > Polytopes (4:49)
> > > Volesti (7:71)
> > > polytopes (8:39, 10:83)
> > > volesti (7:50)
> > > zonotopes (9:44)
> > These words, except of 'volesti' (which is the name of our package),
> > describe geometrical concepts.
> >
> > > Flavor: r-devel-windows-ix86+x86_64
> > > Check: compiled code, Result: NOTE
> > >   File 'volesti/libs/i386/volesti.dll':
> > > Found 'rand', possibly from 'rand' (C)
> > >   Object: 'rotating.o'
> > >   File 'volesti/libs/x64/volesti.dll':
> > > Found 'rand', possibly from 'rand' (C)
> > >   Object: 'rotating.o'
> > >
> > >   Compiled code should not call entry points which might terminate R
> nor
> > >   write to stdout/stderr instead of to the console, nor use Fortran I/O
> > >   nor system RNGs.
> > >
> > >   See 'Writing portable packages' in the 'Writing R Extensions' manual.
> > >
> > > Flavor: r-devel-linux-x86_64-debian-gcc
> > > Check: compiled code, Result: NOTE
> > >   File 'volesti/libs/volesti.so':
> > > Found 'rand', possibly from 'rand' (C)
> > >   Object: 'rotating.o'
> > >
> > >   Compiled code should not call entry points which might terminate R
> nor
> > >   write to stdout/stderr instead of to the console, nor use Fortran I/O
> > >   nor system RNGs.
> >
> > Library lpSolveAPI uses rand() 

Re: [R-pkg-devel] CRAN review

[Vissarion Fisikopoulos]

Dear all,

@Henrik: thanks a lot for your reply.

I did one more submission (the third) and I am posting below my answer
to the automatic cran email with 2 NOTES.

Looking forward to your feedback.

Best regards,
Vissarion.

On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos  wrote:
>
> Dear all,
>
> We got the results from the automated check for our package. There are
> two NOTEs in both checks in Windows and Debian. We are sure that the
> rejections are false positive, so with this e-mail we try to explain
> why. Please find our explanations below.
>
> On Thu, 28 Mar 2019 at 16:40,  wrote:
> >
> > Dear maintainer,
> >
> > package volesti_0.0.0.tar.gz does not pass the incoming checks 
> > automatically, please see the following pre-tests:
> > Windows: 
> > 
> > Status: 2 NOTEs
> > Debian: 
> > 
> > Status: 2 NOTEs
> >
> >
> >
> > Please fix all problems and resubmit a fixed version via the webform.
> > If you are not sure how to fix the problems shown, please ask for help on 
> > the R-package-devel mailing list:
> > 
> > If you are fairly certain the rejection is a false positive, please 
> > reply-all to this message and explain.
> >
> > More details are given in the directory:
> > 
> > The files will be removed after roughly 7 days.
> >
> > No strong reverse dependencies to be checked.
> >
> > Best regards,
> > CRAN teams' auto-check service
> > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> > Check: CRAN incoming feasibility, Result: NOTE
> >   Maintainer: 'Vissarion Fisikopoulos '
> >
> >   New submission
> >
> >   Possibly mis-spelled words in DESCRIPTION:
> > Minkowski (9:17)
> > Polytopes (4:49)
> > Volesti (7:71)
> > polytopes (8:39, 10:83)
> > volesti (7:50)
> > zonotopes (9:44)
> These words, except of 'volesti' (which is the name of our package),
> describe geometrical concepts.
>
> > Flavor: r-devel-windows-ix86+x86_64
> > Check: compiled code, Result: NOTE
> >   File 'volesti/libs/i386/volesti.dll':
> > Found 'rand', possibly from 'rand' (C)
> >   Object: 'rotating.o'
> >   File 'volesti/libs/x64/volesti.dll':
> > Found 'rand', possibly from 'rand' (C)
> >   Object: 'rotating.o'
> >
> >   Compiled code should not call entry points which might terminate R nor
> >   write to stdout/stderr instead of to the console, nor use Fortran I/O
> >   nor system RNGs.
> >
> >   See 'Writing portable packages' in the 'Writing R Extensions' manual.
> >
> > Flavor: r-devel-linux-x86_64-debian-gcc
> > Check: compiled code, Result: NOTE
> >   File 'volesti/libs/volesti.so':
> > Found 'rand', possibly from 'rand' (C)
> >   Object: 'rotating.o'
> >
> >   Compiled code should not call entry points which might terminate R nor
> >   write to stdout/stderr instead of to the console, nor use Fortran I/O
> >   nor system RNGs.
>
> Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace
> both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from
> R’s internal random number generation routines as it is proposed in
> `Writing R Extensions`. Moreover if you run in folder `/src`:
> $ grep -r 'rand()'
> You just get:
> `utils.c:  range *= (LPSREAL) unif_rand();`
> which is our replacement. If you replace `rand()` with `srand` in grep
> search you get a null result.
> This NOTE appears because of our functions in `/src/include/samplers`
> where word `rand` appears a lot of times, for example
> `rand_point_generator()`.
>
> Best regards,
> Vissarion Fisikopoulos

On Fri, 22 Mar 2019 at 22:03, Henrik Bengtsson
 wrote:
>
> Not a CRAN maintainer, but from my experience, it sounds like you're
> hitting some very unusual hiccup here - that's unfortunate.  I just
> had a look around at ftp://cran.r-project.org/incoming/ and your
> package is not there anymore. Just a wild guess but I wonder if your
> email reply back to CRAN ends up in their spam folders?
>
> BTW, what are the two NOTEs you're getting?  Maybe they're avoidable.
> Since packages with all OKs can go straight through the CRAN incoming
> checks and be published automatically (at least if the package is
> already on CRAN), I try to walk an extra mile just avoid NOTEs in my
> packages even if I know they're false positives.
>
> My $.02
>
> /Henrik
>
> On Fri, Mar 22, 2019 at 6:28 AM Vissarion Fisikopoulos
>  wrote:
> >
> > Hello,
> >
> > we have resubmitted the package 'volesti'. I got the email and
> > confirmed submission. Later I got the confirmation email starting:
> > "The following package was uploaded to CRAN:..." and then the email on
> > automated check complaining about the same 2 notes as in the previous
> > submission. I