Re: [R-pkg-devel] Number of cores in examples

[Uwe Ligges]

The message came from a CRAN team member, so please ask the CRAN team 
member who found that issue if you cannot work it out. Readers of this 
list cannot help unless reading the sources of your package that you 
have not shared with the list.


Note that CRAN team members may also make mistakes given there are 
dozens of new submissions on a single day.


Best,
Uwe Ligges





On 15.09.2019 19:49, John Harrold wrote:

Hello Max,

The comment I received was:

Please ensure that you do not use more than 2 cores in your examples.

I believe the only output I received was these incoming pretest results:

https://win-builder.r-project.org/incoming_pretest/ubiquity_1.0.0_20190821_023712/

Feel free to browse through them.

Thanks
John

On Sun, Sep 15, 2019 at 10:26 AM Max Turgeon 
wrote:


Hi John,


 From the R-hub output you shared with us, we can see that you don't get
the error on Ubuntu with R-devel, nor on Windows with R-3.6.1. When you
received the original email from CRAN with the check output, on which
platform did you get the error about using too many cores? Perhaps that
info could help narrow it down, or at least you would know on which
platform to test.


Max Turgeon
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca


--
*From:* R-package-devel  on behalf
of John Harrold 
*Sent:* September 15, 2019 11:31:38 AM
*To:* Uwe Ligges
*Cc:* r-package-devel@r-project.org
*Subject:* Re: [R-pkg-devel] Number of cores in examples

Howdy Folks,

I'm testing this on R-hub, and I've set option in the environment. I put
links to the Windows and Ubuntu outputs below. I've searched for the
obvious (core, parallel, etc), but I'm not really sure what I need to look
for to indicate that more than one core is being used. If someone could
point it out to me I'd be very grateful.

Windows:

https://drive.google.com/file/d/1187cRyrJLFJetaOW3WHL-mLTCTwYxOeG/view?usp=sharing

Ubuntu:

https://drive.google.com/file/d/1XhaKFpaPaRyJLvHuFcbWNyztzYpsLj8r/view?usp=sharing

Thanks
John



On Sun, Sep 15, 2019 at 12:42 AM Uwe Ligges <
lig...@statistik.tu-dortmund.de>
wrote:




On 15.09.2019 05:39, John Harrold wrote:

Thanks Uwe,

Is there a way to find out on my end where this is happening?


Yes, simply set the env var
_R_CHECK_LIMIT_CORES_=true
to reproduce.

Best,
Uwe



Thanks
john

On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges
mailto:lig...@statistik.tu-dortmund.de

>> wrote:




 On 14.09.2019 03:33, John Harrold wrote:
  > Hello,
  >
  > I recently submitted a package for consideration in CRAN. One of

the

  > comments was:
  >
  > Please ensure that you do not use more than 2 cores in your

examples.

  >
  > I do not believe my package does this. Is this a general comment
 for a
  > package that requires doParallel or was this triggered because
 one of my
  > examples actually used more than 2 cores?

 The latter. In examples, vignettes and tests you must not start

more

 than 2 workers as resources for CRAN checks are limited.

 Best,
 Uwe Ligges


  >
  > Thanks
  > John
  >



--
John
:wq





--
John
:wq

 [[alternative HTML version deleted]]

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






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

Re: [Rd] [External] REprintf could be caught by tryCatch(message)

[Tierney, Luke]

You can file it as a wishlist item in the bug trackign system. Without
a compelling case or a complete and well tested patch or both I doubt
it will rise to the top of anyone's priority list.

Best,

luke

On Sun, 15 Sep 2019, Jan Gorecki wrote:

> Thank you Luke for prompt reply.
> Is it possible then to request a new function to R C API "message"
> that would equivalent to R "message" function? Similarly as we now
> have C "warning" and C "error" functions.
>
> Best,
> Jan
>
> On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke  wrote:
>>
>> On Sun, 15 Sep 2019, Jan Gorecki wrote:
>>
>>> Dear R-devel community,
>>>
>>> There appears to be an inconsistency in R C API about the exceptions
>>> that can be raised from C code.
>>> Mapping of R C funs to corresponding R functions is as follows.
>>>
>>> error-> stop
>>> warning  -> warning
>>> REprintf -> message
>>
>> This is wrong: REpintf is like cat with file = stderr(). If this claim
>> is made somewhere in R documentation please report it a a bug.
>>
>>> Rprintf  -> cat
>>>
>>> Rprint/cat is of course not an exception, I listed it just for completeness.
>>> The inconsistency I would like to report is about REprintf. It cannot
>>> be caught by tryCatch(message). Warnings are errors are being caught
>>> as expected.
>>>
>>> Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
>>> can catch it?
>>
>> No: this is behaving as intended.
>>
>> Best,
>>
>> luke
>>
>>> So in the example below catch(Cmessage()) would behave consistently to
>>> R's catch(message("a"))?
>>>
>>> Regards,
>>> Jan Gorecki
>>>
>>> catch = function(expr) {
>>>  tryCatch(expr,
>>>message=function(m) cat("caught message\n"),
>>>warning=function(w) cat("caught warning\n"),
>>>error=function(e) cat("caught error\n")
>>>  )
>>> }
>>> library(inline)
>>> Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
>>> Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
>>> Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
>>>
>>> catch(stop("a"))
>>> #caught error
>>> catch(warning("a"))
>>> #caught warning
>>> catch(message("a"))
>>> #caught message
>>>
>>> catch(Cstop())
>>> #caught error
>>> catch(Cwarning())
>>> #caught warning
>>> catch(Cmessage())
>>> #a
>>> #NULL
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> --
>> Luke Tierney
>> Ralph E. Wareham Professor of Mathematical Sciences
>> University of Iowa  Phone: 319-335-3386
>> Department of Statistics andFax:   319-335-3017
>> Actuarial Science
>> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
>> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>

-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

Re: [Rd] Error: package or namespace load failed for ‘utils

[Laurent Gautier]

In case a search engine leads someone with the same issue here, I am
documenting the point I reached:

I can reproduce the issue with a small example when forcing R to not load
any package at startup time (using an Renviron file):
```
package <- "utils"
lib.loc <- ""
ns <- loadNamespace(package, lib.loc)
```

The code path goes through `registerS3methods(nsInfo$S3methods, package,
env)` and there to:

```
if (methods::is(genfun, "genericFunction"))
```

The evaluation of `methods::is` reaches the line triggering the error as
`.identC(class1, class2)` and `.identC(class2, "ANY")` both return `NA` and
`NA || NA` is not defined:

```
> if (NA || NA) { cat("here\n") }
Error in if (NA || NA) { : missing value where TRUE/FALSE needed
```

As I understand it `.identC()` should never return `NA`, and if the case
this would mean that R itself is an unstable state (something at the C
level that should not have happened has happened) but this was not caught
earlier.

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Number of cores in examples

[John Harrold]

Hello Max,

The comment I received was:

Please ensure that you do not use more than 2 cores in your examples.

I believe the only output I received was these incoming pretest results:

https://win-builder.r-project.org/incoming_pretest/ubiquity_1.0.0_20190821_023712/

Feel free to browse through them.

Thanks
John

On Sun, Sep 15, 2019 at 10:26 AM Max Turgeon 
wrote:

> Hi John,
>
>
> From the R-hub output you shared with us, we can see that you don't get
> the error on Ubuntu with R-devel, nor on Windows with R-3.6.1. When you
> received the original email from CRAN with the check output, on which
> platform did you get the error about using too many cores? Perhaps that
> info could help narrow it down, or at least you would know on which
> platform to test.
>
>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
> --
> *From:* R-package-devel  on behalf
> of John Harrold 
> *Sent:* September 15, 2019 11:31:38 AM
> *To:* Uwe Ligges
> *Cc:* r-package-devel@r-project.org
> *Subject:* Re: [R-pkg-devel] Number of cores in examples
>
> Howdy Folks,
>
> I'm testing this on R-hub, and I've set option in the environment. I put
> links to the Windows and Ubuntu outputs below. I've searched for the
> obvious (core, parallel, etc), but I'm not really sure what I need to look
> for to indicate that more than one core is being used. If someone could
> point it out to me I'd be very grateful.
>
> Windows:
>
> https://drive.google.com/file/d/1187cRyrJLFJetaOW3WHL-mLTCTwYxOeG/view?usp=sharing
>
> Ubuntu:
>
> https://drive.google.com/file/d/1XhaKFpaPaRyJLvHuFcbWNyztzYpsLj8r/view?usp=sharing
>
> Thanks
> John
>
>
>
> On Sun, Sep 15, 2019 at 12:42 AM Uwe Ligges <
> lig...@statistik.tu-dortmund.de>
> wrote:
>
> >
> >
> > On 15.09.2019 05:39, John Harrold wrote:
> > > Thanks Uwe,
> > >
> > > Is there a way to find out on my end where this is happening?
> >
> > Yes, simply set the env var
> > _R_CHECK_LIMIT_CORES_=true
> > to reproduce.
> >
> > Best,
> > Uwe
> >
> > >
> > > Thanks
> > > john
> > >
> > > On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges
> > >  > >  >> wrote:
> > >
> > >
> > >
> > > On 14.09.2019 03:33, John Harrold wrote:
> > >  > Hello,
> > >  >
> > >  > I recently submitted a package for consideration in CRAN. One of
> > the
> > >  > comments was:
> > >  >
> > >  > Please ensure that you do not use more than 2 cores in your
> > examples.
> > >  >
> > >  > I do not believe my package does this. Is this a general comment
> > > for a
> > >  > package that requires doParallel or was this triggered because
> > > one of my
> > >  > examples actually used more than 2 cores?
> > >
> > > The latter. In examples, vignettes and tests you must not start
> more
> > > than 2 workers as resources for CRAN checks are limited.
> > >
> > > Best,
> > > Uwe Ligges
> > >
> > >
> > >  >
> > >  > Thanks
> > >  > John
> > >  >
> > >
> > >
> > >
> > > --
> > > John
> > > :wq
> >
>
>
> --
> John
> :wq
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

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

Re: [Rd] [External] REprintf could be caught by tryCatch(message)

[Jan Gorecki]

Thank you Luke for prompt reply.
Is it possible then to request a new function to R C API "message"
that would equivalent to R "message" function? Similarly as we now
have C "warning" and C "error" functions.

Best,
Jan

On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke  wrote:
>
> On Sun, 15 Sep 2019, Jan Gorecki wrote:
>
> > Dear R-devel community,
> >
> > There appears to be an inconsistency in R C API about the exceptions
> > that can be raised from C code.
> > Mapping of R C funs to corresponding R functions is as follows.
> >
> > error-> stop
> > warning  -> warning
> > REprintf -> message
>
> This is wrong: REpintf is like cat with file = stderr(). If this claim
> is made somewhere in R documentation please report it a a bug.
>
> > Rprintf  -> cat
> >
> > Rprint/cat is of course not an exception, I listed it just for completeness.
> > The inconsistency I would like to report is about REprintf. It cannot
> > be caught by tryCatch(message). Warnings are errors are being caught
> > as expected.
> >
> > Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
> > can catch it?
>
> No: this is behaving as intended.
>
> Best,
>
> luke
>
> > So in the example below catch(Cmessage()) would behave consistently to
> > R's catch(message("a"))?
> >
> > Regards,
> > Jan Gorecki
> >
> > catch = function(expr) {
> >  tryCatch(expr,
> >message=function(m) cat("caught message\n"),
> >warning=function(w) cat("caught warning\n"),
> >error=function(e) cat("caught error\n")
> >  )
> > }
> > library(inline)
> > Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
> > Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
> > Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
> >
> > catch(stop("a"))
> > #caught error
> > catch(warning("a"))
> > #caught warning
> > catch(message("a"))
> > #caught message
> >
> > catch(Cstop())
> > #caught error
> > catch(Cwarning())
> > #caught warning
> > catch(Cmessage())
> > #a
> > #NULL
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

Re: [R-pkg-devel] Number of cores in examples

[John Harrold]

Howdy Folks,

I'm testing this on R-hub, and I've set option in the environment. I put
links to the Windows and Ubuntu outputs below. I've searched for the
obvious (core, parallel, etc), but I'm not really sure what I need to look
for to indicate that more than one core is being used. If someone could
point it out to me I'd be very grateful.

Windows:
https://drive.google.com/file/d/1187cRyrJLFJetaOW3WHL-mLTCTwYxOeG/view?usp=sharing

Ubuntu:
https://drive.google.com/file/d/1XhaKFpaPaRyJLvHuFcbWNyztzYpsLj8r/view?usp=sharing

Thanks
John



On Sun, Sep 15, 2019 at 12:42 AM Uwe Ligges 
wrote:

>
>
> On 15.09.2019 05:39, John Harrold wrote:
> > Thanks Uwe,
> >
> > Is there a way to find out on my end where this is happening?
>
> Yes, simply set the env var
> _R_CHECK_LIMIT_CORES_=true
> to reproduce.
>
> Best,
> Uwe
>
> >
> > Thanks
> > john
> >
> > On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges
> >  > > wrote:
> >
> >
> >
> > On 14.09.2019 03:33, John Harrold wrote:
> >  > Hello,
> >  >
> >  > I recently submitted a package for consideration in CRAN. One of
> the
> >  > comments was:
> >  >
> >  > Please ensure that you do not use more than 2 cores in your
> examples.
> >  >
> >  > I do not believe my package does this. Is this a general comment
> > for a
> >  > package that requires doParallel or was this triggered because
> > one of my
> >  > examples actually used more than 2 cores?
> >
> > The latter. In examples, vignettes and tests you must not start more
> > than 2 workers as resources for CRAN checks are limited.
> >
> > Best,
> > Uwe Ligges
> >
> >
> >  >
> >  > Thanks
> >  > John
> >  >
> >
> >
> >
> > --
> > John
> > :wq
>


-- 
John
:wq

[[alternative HTML version deleted]]

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

Re: [Rd] [External] REprintf could be caught by tryCatch(message)

[Tierney, Luke]

On Sun, 15 Sep 2019, Jan Gorecki wrote:

> Dear R-devel community,
>
> There appears to be an inconsistency in R C API about the exceptions
> that can be raised from C code.
> Mapping of R C funs to corresponding R functions is as follows.
>
> error-> stop
> warning  -> warning
> REprintf -> message

This is wrong: REpintf is like cat with file = stderr(). If this claim
is made somewhere in R documentation please report it a a bug.

> Rprintf  -> cat
>
> Rprint/cat is of course not an exception, I listed it just for completeness.
> The inconsistency I would like to report is about REprintf. It cannot
> be caught by tryCatch(message). Warnings are errors are being caught
> as expected.
>
> Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
> can catch it?

No: this is behaving as intended.

Best,

luke

> So in the example below catch(Cmessage()) would behave consistently to
> R's catch(message("a"))?
>
> Regards,
> Jan Gorecki
>
> catch = function(expr) {
>  tryCatch(expr,
>message=function(m) cat("caught message\n"),
>warning=function(w) cat("caught warning\n"),
>error=function(e) cat("caught error\n")
>  )
> }
> library(inline)
> Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
> Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
> Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
>
> catch(stop("a"))
> #caught error
> catch(warning("a"))
> #caught warning
> catch(message("a"))
> #caught message
>
> catch(Cstop())
> #caught error
> catch(Cwarning())
> #caught warning
> catch(Cmessage())
> #a
> #NULL
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

Re: [Bioc-devel] R environment variable which indicates "running in the bioc build system"?

[Paul Shannon]

On Sep 12, 2019, at 4:28 PM, Pages, Herve  wrote:
> 
> However things seem to work as expected on the Linux builders:
> 
>   library(igvR)
>   igv <- igvR()
>   # attempting to open websocket connection on port 15000
>   # BrowserViz websocket ready after   1.20 seconds
>   ping(igv)
>   # [1] "pong"

Very promising - thanks, Herve.

I just tried this on one of my own ubuntu machines.  I see that no web browsers 
are yet installed.
Do you know which one is installed on the bioc Linux builders?  Is one of them 
headless?

> igv <- igvR()
attempting to open websocket connection on port 15000
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: x-www-browser: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: firefox: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: iceweasel: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: seamonkey: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: mozilla: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: epiphany: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: konqueror: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: chromium-browser: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: google-chrome: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 'http://localhost:15000'

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

[Rd] REprintf could be caught by tryCatch(message)

[Jan Gorecki]

Dear R-devel community,

There appears to be an inconsistency in R C API about the exceptions
that can be raised from C code.
Mapping of R C funs to corresponding R functions is as follows.

error-> stop
warning  -> warning
REprintf -> message
Rprintf  -> cat

Rprint/cat is of course not an exception, I listed it just for completeness.
The inconsistency I would like to report is about REprintf. It cannot
be caught by tryCatch(message). Warnings are errors are being caught
as expected.

Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
can catch it?
So in the example below catch(Cmessage()) would behave consistently to
R's catch(message("a"))?

Regards,
Jan Gorecki

catch = function(expr) {
  tryCatch(expr,
message=function(m) cat("caught message\n"),
warning=function(w) cat("caught warning\n"),
error=function(e) cat("caught error\n")
  )
}
library(inline)
Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')

catch(stop("a"))
#caught error
catch(warning("a"))
#caught warning
catch(message("a"))
#caught message

catch(Cstop())
#caught error
catch(Cwarning())
#caught warning
catch(Cmessage())
#a
#NULL

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

Re: [Rd] head.matrix can return 1000s of columns -- limit to n or add new argument?

[Michael Chirico]

Finally read in detail your response Gabe. Looks great, and I agree it's
quite intuitive, as well as agree against non-recycling.

Once the length(n) == length(dim(x)) behavior is enabled, I don't think
there's any need/desire to have head() do x[1:6,1:6] anymore. head(x, c(6,
6)) is quite clear for those familiar with head(x, 6), it would seem to me.

Mike C

On Sat, Jul 13, 2019 at 8:35 AM Gabriel Becker 
wrote:

> Hi Michael and Abby,
>
> So one thing that could happen that would be backwards compatible (with
> the exception of something that was an error no longer being an error) is
> head and tail could take vectors of length (dim(x)) rather than integers of
> length for n, with the default being n=6 being equivalent to n = c(6,
> dim(x)[2], <...>, dim(x)[k]), at least for the deprecation cycle, if not
> permanently. It not recycling would be unexpected based on the behavior of
> many R functions but would preserve the current behavior while granting
> more fine-grained control to users that feel they need it.
>
> A rapidly thrown-together prototype of such a method for the head of a
> matrix case is as follows:
>
> head2 = function(x, n = 6L, ...) {
> indvecs = lapply(seq_along(dim(x)), function(i) {
> if(length(n) >= i) {
> ni = n[i]
> } else {
> ni =  dim(x)[i]
> }
> if(ni < 0L)
> ni = max(nrow(x) + ni, 0L)
> else
> ni = min(ni, dim(x)[i])
> seq_len(ni)
> })
> lstargs = c(list(x),indvecs, drop = FALSE)
> do.call("[", lstargs)
> }
>
>
> > mat = matrix(1:100, 10, 10)
>
> > *head(mat)*
>
>  [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
>
> [1,]1   11   21   31   41   51   61   71   8191
>
> [2,]2   12   22   32   42   52   62   72   8292
>
> [3,]3   13   23   33   43   53   63   73   8393
>
> [4,]4   14   24   34   44   54   64   74   8494
>
> [5,]5   15   25   35   45   55   65   75   8595
>
> [6,]6   16   26   36   46   56   66   76   8696
>
> > *head2(mat)*
>
>  [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
>
> [1,]1   11   21   31   41   51   61   71   8191
>
> [2,]2   12   22   32   42   52   62   72   8292
>
> [3,]3   13   23   33   43   53   63   73   8393
>
> [4,]4   14   24   34   44   54   64   74   8494
>
> [5,]5   15   25   35   45   55   65   75   8595
>
> [6,]6   16   26   36   46   56   66   76   8696
>
> > *head2(mat, c(2, 3))*
>
>  [,1] [,2] [,3]
>
> [1,]1   11   21
>
> [2,]2   12   22
>
> > *head2(mat, c(2, -9))*
>
>  [,1]
>
> [1,]1
>
> [2,]2
>
>
> Now one thing to keep in mind here, is that I think we'd  either a) have
> to make the non-recycling  behavior permanent, or b) have head treat
> data.frames and matrices different with respect to the subsets they grab
> (which strikes me as a  *Bad Plan *(tm)).
>
> So I don't think the default behavior would ever be mat[1:6, 1:6],  not
> because of backwards compatibility, but because at least in my intuition
> that is just not what head on a data.frame should do by default, and I
> think the behaviors for the basic rectangular datatypes should "stick
> together". I mean, also because of backwards compatibility, but that could  
> *in
> theory* change across a long enough deprecation cycle, but  the
> conceptually right thing to do with a data.frame probably won't.
>
> All of that said, is head(mat, c(6, 6)) really that much  easier to
> type/better than just mat[1:6, 1:6, drop=FALSE] (I know this will behave
> differently if any of the dims of mat are less than 6, but if so why are
> you heading it in the first place ;) )? I don't really have a strong
> feeling on the answer to that.
>
> I'm happy to put a patch for head.matrix, head.data.frame, tail.matrix and
> tail.data.frame, plus documentation, if people on R-core are interested in
> this.
>
> Note, as most here probably know, and as alluded to above,  length(n) > 1
> for head or tail currently give an error, so  this would  be an extension
> of the existing functionality in the mathematical extension sense, where
> all existing behavior would remain identical, but the support/valid
> parameter space would grow.
>
> Best,
> ~G
>
>
> On Fri, Jul 12, 2019 at 4:03 PM Abby Spurdle  wrote:
>
>> > I assume there are lots of backwards-compatibility issues as well as
>> valid
>> > use cases for this behavior, so I guess defaulting to M[1:6, 1:6] is out
>> of
>> > the question.
>>
>> Agree.
>>
>> > Is there any scope for adding a new argument to head.matrix that would
>> > allow this flexibility?
>>
>> I agree with what you're trying to achieve.
>> However, I'm not sure this is as simple as you're suggesting.
>>
>> What if the user wants "head" in rows but "tail" in columns.
>> Or "head" in rows, and both "head" and "tail" in columns.
>> With head and tail alone, there's a combinatorial explosion.
>>
>> Also, when using tail on an unnamed 

Re: [R-pkg-devel] Number of cores in examples

[Uwe Ligges]

On 15.09.2019 05:39, John Harrold wrote:

Thanks Uwe,

Is there a way to find out on my end where this is happening?


Yes, simply set the env var
_R_CHECK_LIMIT_CORES_=true
to reproduce.

Best,
Uwe



Thanks
john

On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges 
> wrote:




On 14.09.2019 03:33, John Harrold wrote:
 > Hello,
 >
 > I recently submitted a package for consideration in CRAN. One of the
 > comments was:
 >
 > Please ensure that you do not use more than 2 cores in your examples.
 >
 > I do not believe my package does this. Is this a general comment
for a
 > package that requires doParallel or was this triggered because
one of my
 > examples actually used more than 2 cores?

The latter. In examples, vignettes and tests you must not start more
than 2 workers as resources for CRAN checks are limited.

Best,
Uwe Ligges


 >
 > Thanks
 > John
 >



--
John
:wq


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