Re: [R-pkg-devel] Compilation used the "non-portable flag"

[Goldfeld, Keith]

That definitely makes it easy. Thanks.

-Original Message-
From: R-package-devel  On Behalf Of Ralf 
Stubner
Sent: Friday, May 10, 2019 4:41 PM
To: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Compilation used the "non-portable flag"

On 10.05.19 22:32, Goldfeld, Keith wrote:
> I am submitting an update to my package ‘simstudy’, and the ran the rhub 
> checks. I received a note from one of the four platforms (the other three 
> passed). The Ubuntu Linux 16.04 objected to the compilation flags:
> 
> * checking compilation flags used ... NOTE Compilation used the 
> following non-portable flag(s):
>   ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’

You can ignore these messages, c.f. 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_r-2Dhub_rhub_issues_264=DwIFaQ=j5oPpO0eBH1iio48DtsedeElZfc04rx3ExJHeIIZuCs=fPRk5fx5iys38LPukC4wczPXS5KI6iyvPUM-ICDfxh8=Y22gFyc69PfyQYs7TnMqsYGg7I65FrV3X2JPEm6_gqM=pAEaTHOVB2wL09DSdHLlPHHV1rTEZlSeraj4ENBsUsk=

> I did some searching and someone suggested I create a ‘Makevars’ in the ~/.R 
> directory (which is different from my package directory). This is what I 
> included in the Makevars file:

You cannot remove these compiler flags in a package's Makevars file.
Either ignore the warning (that's what I am doing when using rhub), or ask the 
rhub maintainer to add a suitable ~/.R/Makevars file.

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



This email message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is proprietary, 
confidential, and exempt from disclosure under applicable law. Any unauthorized 
review, use, disclosure, or distribution is prohibited. If you have received 
this email in error please notify the sender by return email and delete the 
original message. Please note, the recipient should check this email and any 
attachments for the presence of viruses. The organization accepts no liability 
for any damage caused by any virus transmitted by this email.
=
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Compilation used the "non-portable flag"

[Dirk Eddelbuettel]

On 10 May 2019 at 20:32, Goldfeld, Keith wrote:
| Good afternoon –
| 
| I am submitting an update to my package ‘simstudy’, and the ran the rhub 
checks. I received a note from one of the four platforms (the other three 
passed). The Ubuntu Linux 16.04 objected to the compilation flags:
| 
| * checking compilation flags used ... NOTE
| Compilation used the following non-portable flag(s):
|   ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
| 
| I did some searching and someone suggested I create a ‘Makevars’ in the ~/.R 
directory (which is different from my package directory). This is what I 
included in the Makevars file:
| 
| # Settings from /etc/R/Makeconf with "non-portable flag(s):"
| # ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’ replaced by -Wall 
-pedantic
| # and without -fdebug-prefix-map=...
| CFLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong -D_FORTIFY_SOURCE=2 
$(LTO)
| CXXFLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 $(LTO)
| CXX98FLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong 
-D_FORTIFY_SOURCE=2
| CXX11FLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong 
-D_FORTIFY_SOURCE=2
| CXX14FLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong 
-D_FORTIFY_SOURCE=2
| 
| I ran devtools::check(), and it seemed to find the Makevars file. However, 
when I reran devtools::check_rhub(), I still received a NOTE. Does anyone have 
any advice on what I might not be getting right?

"A change is gonna come."

This was arguably something I should have taken care of earlier.  The long
story is that

 - Debian (and thus Ubuntu) impose ‘-Wdate-time -Werror=format-security
   -Wformat’ for security reasons, and have for a few years
 - as an OS default these become active on Debian and Ubuntu when R is
   compiled (see /etc/R/Makeconf)
 - this confuses people, and what pushed me over the edge was that I had to
   explain it to one of my STAT 430 students a week or two ago

As discussed on r-sig-debian we currently have another good reason to update
our R 3.6.0-1 package, and I will add this too.  In the meantime try this on
local system (and I don't think you can influence the rhub build): just add

   _R_CHECK_COMPILATION_FLAGS_KNOWN_=-Wformat -Werror=format-security 
-Wdate-time

to any one of $RHOME/etc/Renviron, $RHOME/etc/Renviron.site (and those two
can be accessed via /etc/R/ for convenience), your ~/.Renviron, your working
directory's .Renviron (if any), your ~/.R/check.Renviron.

Or wait a couple of days.

Hope this helps,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Compilation used the "non-portable flag"

[Ralf Stubner]

On 10.05.19 22:32, Goldfeld, Keith wrote:
> I am submitting an update to my package ‘simstudy’, and the ran the rhub 
> checks. I received a note from one of the four platforms (the other three 
> passed). The Ubuntu Linux 16.04 objected to the compilation flags:
> 
> * checking compilation flags used ... NOTE
> Compilation used the following non-portable flag(s):
>   ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’

You can ignore these messages, c.f. https://github.com/r-hub/rhub/issues/264

> I did some searching and someone suggested I create a ‘Makevars’ in the ~/.R 
> directory (which is different from my package directory). This is what I 
> included in the Makevars file:

You cannot remove these compiler flags in a package's Makevars file.
Either ignore the warning (that's what I am doing when using rhub), or
ask the rhub maintainer to add a suitable ~/.R/Makevars file.

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

[R-pkg-devel] Compilation used the "non-portable flag"

[Goldfeld, Keith]

Good afternoon –

I am submitting an update to my package ‘simstudy’, and the ran the rhub 
checks. I received a note from one of the four platforms (the other three 
passed). The Ubuntu Linux 16.04 objected to the compilation flags:

* checking compilation flags used ... NOTE
Compilation used the following non-portable flag(s):
  ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’

I did some searching and someone suggested I create a ‘Makevars’ in the ~/.R 
directory (which is different from my package directory). This is what I 
included in the Makevars file:

# Settings from /etc/R/Makeconf with "non-portable flag(s):"
# ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’ replaced by -Wall -pedantic
# and without -fdebug-prefix-map=...
CFLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong -D_FORTIFY_SOURCE=2 
$(LTO)
CXXFLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong -D_FORTIFY_SOURCE=2 
$(LTO)
CXX98FLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong -D_FORTIFY_SOURCE=2
CXX11FLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong -D_FORTIFY_SOURCE=2
CXX14FLAGS = -g -O2 -Wall -pedantic -fstack-protector-strong -D_FORTIFY_SOURCE=2

I ran devtools::check(), and it seemed to find the Makevars file. However, when 
I reran devtools::check_rhub(), I still received a NOTE. Does anyone have any 
advice on what I might not be getting right?

- Keith


Keith S. Goldfeld, DrPH
Assistant Professor

NYU Langone Health
Division of Biostatistics
Department of Population Health
180 Madison Avenue, # 551
New York, NY 10016

T 646-501-3650
M 646-423-9005
keith.goldf...@nyumc.org

Blog: ouR data generation


This email message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is proprietary, 
confidential, and exempt from disclosure under applicable law. Any unauthorized 
review, use, disclosure, or distribution is prohibited. If you have received 
this email in error please notify the sender by return email and delete the 
original message. Please note, the recipient should check this email and any 
attachments for the presence of viruses. The organization accepts no liability 
for any damage caused by any virus transmitted by this email.
=

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Wang, Zhu]

Thanks Ivan for the tip. Are there any examples or links for me to follow 
through more closely?

Thanks,

Zhu

-Original Message-
From: Ivan Krylov  
Sent: Monday, May 6, 2019 4:14 AM
To: Wang, Zhu 
Cc: R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in 
Fortran?

On Sat, 4 May 2019 22:41:16 +
"Wang, Zhu"  wrote:

> In an R package I would like to compute intercept for an 
> intercept-only GLM in a Fortran subroutine.

If all else fails, you could use R API [*] to call coef(glm.fit(...)), though 
it might require writing a C or C++ wrapper to avoid translating all function 
prototypes from Rinternals.h into Fortran 2003 C interoperability syntax.

--
Best regards,
Ivan

[*]:
https://cran.r-project.org/doc/manuals/R-exts.html#Evaluating-R-expressions-from-C

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

Re: [R-pkg-devel] Problem with using parallel runtime system with R

[Iñaki Ucar]

On Fri, 10 May 2019 at 17:38, Sameh M. Abdulah
 wrote:
>
> I will try to talk to my team to fork it for more investigation from your 
> side.

Disclaimer: I'm not saying that I'll have time to have a look. Just
that somebody might help if you provide more information, especially
the actual code, beyond stating that it is not working.

Iñaki

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

Re: [R-pkg-devel] Problem with using parallel runtime system with R

[Sameh M. Abdulah]

I meant for anyone who can help :).

—Sameh


Get Outlook for iOS



On Fri, May 10, 2019 at 6:48 PM +0300, "Iñaki Ucar" 
mailto:iu...@fedoraproject.org>> wrote:


On Fri, 10 May 2019 at 17:38, Sameh M. Abdulah
 wrote:
>
> I will try to talk to my team to fork it for more investigation from your 
> side.

Disclaimer: I'm not saying that I'll have time to have a look. Just
that somebody might help if you provide more information, especially
the actual code, beyond stating that it is not working.

Iñaki


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Problem with using parallel runtime system with R

[Sameh M. Abdulah]

I will try to talk to my team to fork it for more investigation from your side.

However, this is the story.  We have a C package which uses a STARPU runtime 
system (http://starpu.gforge.inria.fr/doc/starpu.pdf) to facility the 
parallelization through a set of task-based parallel algorithms. Once you 
execute
Your program StarPU created several threads to parallelize your tasks based on 
a specific scheduling mechanism. 

In the case of R, R is used only one process and if I used the default behavior 
without any modification, all the StarPU threads are using the same physical 
core which is used by the default R process. We added
A simple modification which helps to well spawn the threads to the other 
available physical cores by disabling the KMP_AFFINITY 
(Sys.setenv(KMP_AFFINITY= "disabled")). However,
Even the performance is improved, the R package is about 5X slow up compared to 
the C version. The difference we found that In case of R different threads is 
controlled by R which means that we can see from top 
Command that R is using n threads on n cores. In the case of C package, StarPU 
is using these threads.  One more difference from htop command that the virtual 
memory usage of the R package is doubled which we cannot 
Understand or even know if it is related to the performance issue or not 



--Sameh



On 5/10/19, 6:12 PM, "Iñaki Ucar"  wrote:

On Fri, 10 May 2019 at 17:06, Sameh M. Abdulah
 wrote:
>
> Actually not yet. It is on Github but in a private repo. If it helps I 
can fork it for public access for now.

Providing the code always improves your chances of getting help.
Otherwise, the information is probably too limited.

Iñaki


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

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Iñaki Ucar]

On Fri, 10 May 2019 at 17:30, Dirk Eddelbuettel  wrote:
>
>
> On 10 May 2019 at 16:49, Iñaki Ucar wrote:
> | On Fri, 10 May 2019 at 15:42, Wang, Zhu  wrote:
> | >
> | > 00install.out
> | >
> | > ** testing if installed package can be loaded from temporary location
> | >  ** checking absolute paths in shared objects and dynamic libraries
> | >  mv: cannot move 
> '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/00LOCK-cts/00new/cts' to 
> '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts': File exists
> | >  ERROR:   moving to final location failed
> | >  * removing '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts'
> |
> | I believe this has something to do with the new staged installation.
> | Reported here:
> |
> | https://stat.ethz.ch/pipermail/r-devel/2019-May/077736.html
> |
> | Try to disable it with by setting the environment variable
> | R_INSTALL_STAGED=false
>
> Are you sure it is not just a permissions issue?  Same thing happens when you
> mix running R CMD check as you and/or as root (ie via a Docker container).

Not completely sure, but /media/sf_* is the typical mount point of a
VirtualBox machine.

Iñaki

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

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Dirk Eddelbuettel]

On 10 May 2019 at 16:49, Iñaki Ucar wrote:
| On Fri, 10 May 2019 at 15:42, Wang, Zhu  wrote:
| >
| > 00install.out
| >
| > ** testing if installed package can be loaded from temporary location
| >  ** checking absolute paths in shared objects and dynamic libraries
| >  mv: cannot move 
'/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/00LOCK-cts/00new/cts' to 
'/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts': File exists
| >  ERROR:   moving to final location failed
| >  * removing '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts'
| 
| I believe this has something to do with the new staged installation.
| Reported here:
| 
| https://stat.ethz.ch/pipermail/r-devel/2019-May/077736.html
| 
| Try to disable it with by setting the environment variable
| R_INSTALL_STAGED=false

Are you sure it is not just a permissions issue?  Same thing happens when you
mix running R CMD check as you and/or as root (ie via a Docker container).

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Wang, Zhu]

Thanks Iñaki for the tip that helps!

Best,

Zhu

-Original Message-
From: Iñaki Ucar  
Sent: Friday, May 10, 2019 9:50 AM
To: Wang, Zhu 
Cc: Ivan Krylov ; R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check ERROR (strange to me)

On Fri, 10 May 2019 at 15:42, Wang, Zhu  wrote:
>
> 00install.out
>
> ** testing if installed package can be loaded from temporary location
>  ** checking absolute paths in shared objects and dynamic libraries
>  mv: cannot move 
> '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/00LOCK-cts/00new/cts' to 
> '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts': File exists
>  ERROR:   moving to final location failed
>  * removing '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts'

I believe this has something to do with the new staged installation.
Reported here:

https://stat.ethz.ch/pipermail/r-devel/2019-May/077736.html

Try to disable it with by setting the environment variable 
R_INSTALL_STAGED=false

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

Re: [R-pkg-devel] Problem with using parallel runtime system with R

[Iñaki Ucar]

On Fri, 10 May 2019 at 17:06, Sameh M. Abdulah
 wrote:
>
> Actually not yet. It is on Github but in a private repo. If it helps I can 
> fork it for public access for now.

Providing the code always improves your chances of getting help.
Otherwise, the information is probably too limited.

Iñaki

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

Re: [R-pkg-devel] Problem with using parallel runtime system with R

[Sameh M. Abdulah]

Actually not yet. It is on Github but in a private repo. If it helps I can fork 
it for public access for now.

Sameh


Get Outlook for iOS



On Fri, May 10, 2019 at 5:55 PM +0300, "Iñaki Ucar" 
mailto:iu...@fedoraproject.org>> wrote:


On Fri, 10 May 2019 at 13:48, Sameh M. Abdulah
 wrote:
> Hi,
>
> I have a C package which includes the usage of the StarPU runtime system to 
> allow running my code on different HW architectures. I included this to an 
> R-package and I found that R is using only one core and all the thread
> initiated by the runtime system is assigned to a single core which impacted 
> the performance.  I used  Sys.setenv(KMP_AFFINITY= "disabled") to disable the 
> default affinity and this helps to allow the runtime system to use
> all available cores. However, even I gained speedup, the R package is still 
> 5X slower than the C package. Could anyone help me to understand the problem 
> better?

Is this package publicly available somewhere?

Iñaki


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Problem with using parallel runtime system with R

[Iñaki Ucar]

On Fri, 10 May 2019 at 13:48, Sameh M. Abdulah
 wrote:
> Hi,
>
> I have a C package which includes the usage of the StarPU runtime system to 
> allow running my code on different HW architectures. I included this to an 
> R-package and I found that R is using only one core and all the thread
> initiated by the runtime system is assigned to a single core which impacted 
> the performance.  I used  Sys.setenv(KMP_AFFINITY= "disabled") to disable the 
> default affinity and this helps to allow the runtime system to use
> all available cores. However, even I gained speedup, the R package is still 
> 5X slower than the C package. Could anyone help me to understand the problem 
> better?

Is this package publicly available somewhere?

Iñaki

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

Re: [R-pkg-devel] "unable to verify current time" in R CMD check

[Iñaki Ucar]

On Fri, 10 May 2019 at 13:22, Juhee Lee  wrote:
>
> Hi, I'm checking my package for CRAN.
>
> In fact, I already complete checking CMD in 3.5.3ver.
> but for the latest ver., 3.6.0, I get  '1 note' when checking CMD.
>
> I wonder how I can solve this note.
>
> > checking for future file timestamps ... NOTE
>   unable to verify current time

Where do you get this NOTE? On CRAN? On your computer? Did you try on
win-builder and/or r-hub?

Iñaki

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

Re: [R-pkg-devel] Change in normal random numbers between R 3.5.3 and R 3.6.0

[Duncan Murdoch]

On 10/05/2019 8:55 a.m., Martin Maechler wrote:

Ulrike Grömping
 on Fri, 10 May 2019 06:39:39 +0200 writes:


 > Mark,
 > I used

 > if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")

 > And that works. Actually, using rnorm afterwards also
 > yields the same random numbers.

Yes, "of course",  'sample.kind' was only introduced into 3.6.0.
We had always recommended

RNGversion("3.5.0")

possibly wrapped in  suppressWarnings().
That *does* work in old and new versions of R.

Note that in R >= 3.6.0 , e.g., inside your if(.) { ** }
you could also use  set.seed(, sample.kind="Rounding")


That's good advice.  There's a couple of other things I'd add:

 - Be sure to do this only in test code with saved results.  Functions 
should never need to do this, and you really don't want to leave that 
setting in place after an example.


 - At some point in the future (maybe in a year or so), update your 
package to depend on "R (>= 3.6.0)", remove the RNGversion() line and 
update saved test results.


Duncan Murdoch



Martin


 > My question arose from the fact that I confused myself about the noLD 
output I was supposed to reproduce. Therefore, my problem should be entirely 
explained by Duncan Murdoch's initial explanation: the sample() change does not 
only lead to different results in discrete sampling but also to different results 
from random number calls for other functions (like rnorm)

*IFF* callled after sample() [etc].
So yes, do call   RNGversion("3.5.0")
before set.seed() before the first call to sample() / sample.int()
or functions using those [or 'rwilcox()', see its help in R >= 3.6.0!].

Martin


 > Best, Ulrike

 > Am 10.05.2019 um 04:58 schrieb R. Mark Sharp:
 >> I was dealing with a similar issue but in the context of getting the same 
unit test code to work on multiple versions of R in a Travis-CI build. It seems 
RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so I resorted to 
using version dependent construction of the argument list to set.seed() in do.call().
 >>
 >> I better solution will be greatly appreciated.
 >>
 >> #' Work around for unit tests using sample()
 >> #'
 >> #' @param seed argument to \code{set.seed}
 >> set_seed <- function(seed = 1) {
 >> version <- as.integer(R.Version()$major) + 
(as.numeric(R.Version()$minor) / 10.0)
 >> if (version >= 3.6) {
 >> args <- list(seed, sample.kind = "Rounding")
 >> } else {
 >> args <- list(seed)
 >> }
 >> suppressWarnings(do.call(set.seed, args))
 >> }
 >>
 >> Mark
 >>
 >> R. Mark Sharp, Ph.D.
 >> Data Scientist and Biomedical Statistical Consultant
 >> 7526 Meadow Green St.
 >> San Antonio, TX 78251
 >> mobile: 210-218-2868
 >> rmsh...@me.com
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>> On May 9, 2019, at 12:45 PM, Duncan Murdoch  
wrote:
 >>>
 >>> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
  Hmmmh, but does that also apply if the sample.kind has been set to the
  old version? I.e., would
  if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
  val <- 10
  set.seed(val)
  discard <- sample(1000, 100)
  rnorm(36)
  produce the same normal random numbers in 3.5.3 and 3.6.0? I would 
have
  expected it to, but it seems to produce the same normal random numbers
  as R version 3.6.0 in the previous version of the test code without 
the
  RNGkind call.
 >>> I'm not seeing that, but I'm not using the exact versions you tested. If I run your code 
in  "R version 3.5.2 (2018-12-20)" and "R Under development (unstable) (2019-05-02 
r76454)" I get this output from both:
 >>>
  if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
  val <- 10
  set.seed(val)
  discard <- sample(1000, 100)
  rnorm(36)
 >>> [1] -0.4006375 -0.3345566  1.3679540  2.1377671  0.5058193  0.7863424 
-0.9022119  0.5328970 -0.6458943  0.2909875 -1.2375945
 >>> [12] -0.4561763 -0.8303227  0.3401156  1.0663764  1.2161258  0.7356907 
-0.4812086  0.5627448 -1.2463197  0.3809222 -1.4304273
 >>> [23] -1.0484455 -0.2185036 -1.4899362  1.1727063 -1.4798270 -0.4303878 
-1.0516386  1.5225863  0.5928281 -0.2226615  0.7128943
 >>> [34]  0.7166008  0.4402419  0.1588306
 >>>
 >>> Okay, I just installed 3.6.0, and I get the same values there.  I 
don't see a Mac binary for 3.5.3, so I can't test that one.
 >>>
 >>> Duncan Murdoch
 >>>
 >>> __
 >>> R-package-devel@r-project.org mailing list
 >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel


 > --
 > ##
 > ## Prof. Ulrike Groemping
 > ## FB II
 > ## Beuth University of Applied Sciences Berlin
 > 

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Wang, Zhu]

00install.out

** testing if installed package can be loaded from temporary location
 ** checking absolute paths in shared objects and dynamic libraries
 mv: cannot move 
'/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/00LOCK-cts/00new/cts' to 
'/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts': File exists
 ERROR:   moving to final location failed
 * removing '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts'

-Original Message-
From: Ivan Krylov  
Sent: Friday, May 10, 2019 1:12 AM
To: Wang, Zhu 
Cc: R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check ERROR (strange to me)

On Thu, 9 May 2019 23:19:46 +
"Wang, Zhu"  wrote:

> I have encountered some strange error (see 00install.out).

It seems to have been stripped by the attachment filter, and there are no 
compilation errors on my system. Can you include the relevant lines from 
00install.out inline?

--
Best regards,
Ivan

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

Re: [R-pkg-devel] Change in normal random numbers between R 3.5.3 and R 3.6.0

[Martin Maechler]

> Ulrike Grömping 
> on Fri, 10 May 2019 06:39:39 +0200 writes:

> Mark,
> I used

> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")

> And that works. Actually, using rnorm afterwards also
> yields the same random numbers.

Yes, "of course",  'sample.kind' was only introduced into 3.6.0.
We had always recommended

   RNGversion("3.5.0")

possibly wrapped in  suppressWarnings().
That *does* work in old and new versions of R.

Note that in R >= 3.6.0 , e.g., inside your if(.) { ** }
you could also use  set.seed(, sample.kind="Rounding")

Martin


> My question arose from the fact that I confused myself about the noLD 
output I was supposed to reproduce. Therefore, my problem should be entirely 
explained by Duncan Murdoch's initial explanation: the sample() change does not 
only lead to different results in discrete sampling but also to different 
results from random number calls for other functions (like rnorm)

*IFF* callled after sample() [etc].
So yes, do call   RNGversion("3.5.0")
before set.seed() before the first call to sample() / sample.int()
or functions using those [or 'rwilcox()', see its help in R >= 3.6.0!].

Martin


> Best, Ulrike

> Am 10.05.2019 um 04:58 schrieb R. Mark Sharp:
>> I was dealing with a similar issue but in the context of getting the 
same unit test code to work on multiple versions of R in a Travis-CI build. It 
seems RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so I 
resorted to using version dependent construction of the argument list to 
set.seed() in do.call().
>> 
>> I better solution will be greatly appreciated.
>> 
>> #' Work around for unit tests using sample()
>> #'
>> #' @param seed argument to \code{set.seed}
>> set_seed <- function(seed = 1) {
>> version <- as.integer(R.Version()$major) + 
(as.numeric(R.Version()$minor) / 10.0)
>> if (version >= 3.6) {
>> args <- list(seed, sample.kind = "Rounding")
>> } else {
>> args <- list(seed)
>> }
>> suppressWarnings(do.call(set.seed, args))
>> }
>> 
>> Mark
>> 
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On May 9, 2019, at 12:45 PM, Duncan Murdoch  
wrote:
>>> 
>>> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
 Hmmmh, but does that also apply if the sample.kind has been set to the
 old version? I.e., would
 if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
 val <- 10
 set.seed(val)
 discard <- sample(1000, 100)
 rnorm(36)
 produce the same normal random numbers in 3.5.3 and 3.6.0? I would have
 expected it to, but it seems to produce the same normal random numbers
 as R version 3.6.0 in the previous version of the test code without the
 RNGkind call.
>>> I'm not seeing that, but I'm not using the exact versions you tested. 
If I run your code in  "R version 3.5.2 (2018-12-20)" and "R Under development 
(unstable) (2019-05-02 r76454)" I get this output from both:
>>> 
 if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
 val <- 10
 set.seed(val)
 discard <- sample(1000, 100)
 rnorm(36)
>>> [1] -0.4006375 -0.3345566  1.3679540  2.1377671  0.5058193  0.7863424 
-0.9022119  0.5328970 -0.6458943  0.2909875 -1.2375945
>>> [12] -0.4561763 -0.8303227  0.3401156  1.0663764  1.2161258  0.7356907 
-0.4812086  0.5627448 -1.2463197  0.3809222 -1.4304273
>>> [23] -1.0484455 -0.2185036 -1.4899362  1.1727063 -1.4798270 -0.4303878 
-1.0516386  1.5225863  0.5928281 -0.2226615  0.7128943
>>> [34]  0.7166008  0.4402419  0.1588306
>>> 
>>> Okay, I just installed 3.6.0, and I get the same values there.  I don't 
see a Mac binary for 3.5.3, so I can't test that one.
>>> 
>>> Duncan Murdoch
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel


> -- 
> ##
> ## Prof. Ulrike Groemping
> ## FB II
> ## Beuth University of Applied Sciences Berlin
> ##
> ## prof.beuth-hochschule.de/groemping
> ## Phone: +49(0)30 4504 5127
> ## Fax:   +49(0)30 4504 66 5127
> ## Home office: +49(0)30 394 04 863
> ##

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

Re: [R-pkg-devel] Change in normal random numbers between R 3.5.3 and R 3.6.0

[R. Mark Sharp]

Ulrike,

RNGkind() worked on 3.4.1 and 3.6.0 but generated a warning on R 3.5.3. The 
message follows:

 checking whether package ‘nprcmanager’ can be installed ... WARNING
Found the following significant warnings:
  Note: possible error in 'RNGkind(sample.kind = "Rounding")': unused argument 
(sample.kind = "Rounding") 
See ‘/tmp/RtmpA4S3Ki/file32b81c218ac8/nprcmanager.Rcheck/00install.out’ for 
details.
Information on the location(s) of code generating the ‘Note’s can be
obtained by re-running with environment variable R_KEEP_PKG_SOURCE set
to ‘yes’.

Mark
R. Mark Sharp
rmsh...@me.com



> On May 9, 2019, at 11:39 PM, Ulrike Grömping  
> wrote:
> 
> Mark,
> 
> I used
> 
> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
> 
> And that works. Actually, using rnorm afterwards also yields the same random 
> numbers.
> My question arose from the fact that I confused myself about the noLD output 
> I was supposed to reproduce. Therefore, my problem should be entirely 
> explained by Duncan Murdoch's initial explanation: the sample() change does 
> not only lead to different results in discrete sampling but also to different 
> results from random number calls for other functions (like rnorm).
> 
> Best, Ulrike
> 
> Am 10.05.2019 um 04:58 schrieb R. Mark Sharp:
>> I was dealing with a similar issue but in the context of getting the same 
>> unit test code to work on multiple versions of R in a Travis-CI build. It 
>> seems RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so 
>> I resorted to using version dependent construction of the argument list to 
>> set.seed() in do.call().
>> 
>> I better solution will be greatly appreciated.
>> 
>> #' Work around for unit tests using sample()
>> #'
>> #' @param seed argument to \code{set.seed}
>> set_seed <- function(seed = 1) {
>>   version <- as.integer(R.Version()$major) + (as.numeric(R.Version()$minor) 
>> / 10.0)
>>   if (version >= 3.6) {
>> args <- list(seed, sample.kind = "Rounding")
>>   } else {
>> args <- list(seed)
>>   }
>>   suppressWarnings(do.call(set.seed, args))
>> }
>> 
>> Mark
>> 
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On May 9, 2019, at 12:45 PM, Duncan Murdoch  
>>> wrote:
>>> 
>>> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
 Hmmmh, but does that also apply if the sample.kind has been set to the
 old version? I.e., would
 if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
 val <- 10
 set.seed(val)
 discard <- sample(1000, 100)
 rnorm(36)
 produce the same normal random numbers in 3.5.3 and 3.6.0? I would have
 expected it to, but it seems to produce the same normal random numbers
 as R version 3.6.0 in the previous version of the test code without the
 RNGkind call.
>>> I'm not seeing that, but I'm not using the exact versions you tested. If I 
>>> run your code in  "R version 3.5.2 (2018-12-20)" and "R Under development 
>>> (unstable) (2019-05-02 r76454)" I get this output from both:
>>> 
 if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
 val <- 10
 set.seed(val)
 discard <- sample(1000, 100)
 rnorm(36)
>>> [1] -0.4006375 -0.3345566  1.3679540  2.1377671  0.5058193  0.7863424 
>>> -0.9022119  0.5328970 -0.6458943  0.2909875 -1.2375945
>>> [12] -0.4561763 -0.8303227  0.3401156  1.0663764  1.2161258  0.7356907 
>>> -0.4812086  0.5627448 -1.2463197  0.3809222 -1.4304273
>>> [23] -1.0484455 -0.2185036 -1.4899362  1.1727063 -1.4798270 -0.4303878 
>>> -1.0516386  1.5225863  0.5928281 -0.2226615  0.7128943
>>> [34]  0.7166008  0.4402419  0.1588306
>>> 
>>> Okay, I just installed 3.6.0, and I get the same values there.  I don't see 
>>> a Mac binary for 3.5.3, so I can't test that one.
>>> 
>>> Duncan Murdoch
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
> -- 
> ##
> ## Prof. Ulrike Groemping
> ## FB II
> ## Beuth University of Applied Sciences Berlin
> ##
> ## prof.beuth-hochschule.de/groemping
> ## Phone: +49(0)30 4504 5127
> ## Fax:   +49(0)30 4504 66 5127
> ## Home office: +49(0)30 394 04 863
> ##
> 

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

[R-pkg-devel] Problem with using parallel runtime system with R

[Sameh M. Abdulah]

Hi,

I have a C package which includes the usage of the StarPU runtime system to 
allow running my code on different HW architectures. I included this to an 
R-package and I found that R is using only one core and all the thread
initiated by the runtime system is assigned to a single core which impacted the 
performance.  I used  Sys.setenv(KMP_AFFINITY= "disabled") to disable the 
default affinity and this helps to allow the runtime system to use
all available cores. However, even I gained speedup, the R package is still 5X 
slower than the C package. Could anyone help me to understand the problem 
better?


--Sameh

[[alternative HTML version deleted]]

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

[R-pkg-devel] "unable to verify current time" in R CMD check

[Juhee Lee]

Hi, I'm checking my package for CRAN.

In fact, I already complete checking CMD in 3.5.3ver.
but for the latest ver., 3.6.0, I get  '1 note' when checking CMD.

I wonder how I can solve this note.

> checking for future file timestamps ... NOTE
  unable to verify current time


Waiting your reply,

Juhee Lee.

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Ivan Krylov]

On Thu, 9 May 2019 23:19:46 +
"Wang, Zhu"  wrote:

> I have encountered some strange error (see 00install.out).

It seems to have been stripped by the attachment filter, and there are
no compilation errors on my system. Can you include the relevant lines
from 00install.out inline?

-- 
Best regards,
Ivan

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