Re: [Rd] Fixing a CRAN note

[Kurt Hornik]

> Therneau, Terry M , Ph D via R-devel writes:

> I am trying to clear up all the "NOTE"s before a CRAN submission, but am a 
> bit confused 
> about this one.   What is it complaining about -- that it doesn't like my 
> name?

> ...
> * checking for file ‘deming/DESCRIPTION’ ... OK
> * this is package ‘deming’ version ‘1.4-1’
> * checking CRAN incoming feasibility ... [7s/18s] NOTE
> Maintainer: ‘Terry Therneau ’

> Found the following \keyword or \concept entries
> which likely give several index terms:
>    File ‘deming.Rd’:
>      \keyword{models, regression}

Use

  \keyword{models}
  \keyword{regression}

Hth
-k

> * checking package namespace information ... OK
> * checking package dependencies ... OK
> ...

> -- 
> Terry M Therneau, PhD
> Department of Quantitative Health Sciences
> Mayo Clinic
> thern...@mayo.edu

> "TERR-ree THUR-noh"

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] rbind() on zero row matrices is inconsistent

[Kurt Hornik]

> Duncan Murdoch writes:

> The help for cbind() and rbind() says
> "For cbind (rbind), vectors of zero length (including NULL) are ignored 
> unless the result would have zero rows (columns), for S compatibility. 
> (Zero-extent matrices do not occur in S3 and are not ignored in R.)"

> This leads to an inconsistency.


>M <- matrix(NA, 0, 0)  # Make a 0x0 matrix
>N <- matrix(NA, 0, 1)  # Make a 0x1 matrix


>dim(rbind(M, NULL, NULL)) # adds 2 rows to M
>#> [1] 2 0
>dim(rbind(N, NULL, NULL)) # leaves N unchanged
>#> [1] 0 1


> You get an extra row on the 0x0 matrix for each NULL value that is bound 
> to it, but the 0xn matrix is unchanged for n > 0.

> Clearly from the help this is intentional, but is it desirable?
> Wouldn't it make more sense for NULL to be ignored by rbind() and
> cbind()?

I would agree :-)

Best
-k

> Duncan Murdoch

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

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

Re: [Rd] Fields used by available.packages

[Kurt Hornik]

>>>>> Lluís Revilla writes:

> Yes, I think that would be enough. 

Thanks.  And of course add documentation ...

Will try to get this in in the next few days.

Best
-k

> Thank you, Kurt!


> Lluís

> On Wed, 12 Jun 2024 at 16:35, Kurt Hornik  wrote:

>>>>>> Lluís Revilla writes:
   
> Lluis,
   
> So in available.packages() I could replace
   
>     if (is.null(fields))
>         fields <- requiredFields
>     else {
>         stopifnot(is.character(fields))
>         fields <- unique(c(requiredFields, fields))
>     }
   
> by someting like
   
>     if(is.null(fields))
>         fields <- getOption("available_packages_fields")
>     if(is.null(fields))
>         fields <- requiredFields
>     else {
>         stopifnot(is.character(fields))
>         fields <- unique(c(requiredFields, fields))
>     }
   
> ?
   
> Best
> -k

>> Hi all,
>> I have recently been researching how available.packages and
>> install.packages filter packages from repositories with additional
> fields
>> in their PACKAGES file.
   
>> Currently there are some default filters, but users (and R admins) can
> set
>> up their own filters by passing a list to the fields argument or adding
>> them to the "available_packages_filters" option.
>> But if the fields used by the filters are not read by default, then
> users
>> must manually add the required fields to each call to
> available.packages.
   
>> This makes it difficult to use new fields and to control what is
> installed
>> in highly regulated systems which want to use more fields to select
> what is
>> installed.
   
>> Current workarounds considered are:
>>   1) The filtering function requiring new fields intercepts the call to
>> available.packages and adds the desired fields via eval in
>> parent.environment and then adds the filters again.
>>   2) Import new data (remote or local) when filtering packages, merge
> them
>> and filter accordingly.
>>   3) Suggestions?
   
>> The first solution is complicated, while the second doesn't use the R
>> machinery of tools::write_PACKAGES to set up the repository with all
> the
>> fields (although how to add more fields to the repository file is a
>> different issue).
   
>> Would it be possible to add a new option to add fields to be read by
>> available.packages, similar to filters?
>> The same approach for fields as for filters would avoid the two
> workarounds
>> mentioned. To match it, the new option could be named
>> "available_packages_fields".
   
>> I look forward to hearing from you,
   
>> Lluís
   
>>        [[alternative HTML version deleted]]
   
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Fields used by available.packages

[Kurt Hornik]

> Lluís Revilla writes:

Lluis,

So in available.packages() I could replace

if (is.null(fields))
fields <- requiredFields
else {
stopifnot(is.character(fields))
fields <- unique(c(requiredFields, fields))
}

by someting like

if(is.null(fields))
fields <- getOption("available_packages_fields")
if(is.null(fields))
fields <- requiredFields
else {
stopifnot(is.character(fields))
fields <- unique(c(requiredFields, fields))
}

?

Best
-k



> Hi all,
> I have recently been researching how available.packages and
> install.packages filter packages from repositories with additional fields
> in their PACKAGES file.

> Currently there are some default filters, but users (and R admins) can set
> up their own filters by passing a list to the fields argument or adding
> them to the "available_packages_filters" option.
> But if the fields used by the filters are not read by default, then users
> must manually add the required fields to each call to available.packages.

> This makes it difficult to use new fields and to control what is installed
> in highly regulated systems which want to use more fields to select what is
> installed.

> Current workarounds considered are:
>  1) The filtering function requiring new fields intercepts the call to
> available.packages and adds the desired fields via eval in
> parent.environment and then adds the filters again.
>  2) Import new data (remote or local) when filtering packages, merge them
> and filter accordingly.
>  3) Suggestions?

> The first solution is complicated, while the second doesn't use the R
> machinery of tools::write_PACKAGES to set up the repository with all the
> fields (although how to add more fields to the repository file is a
> different issue).

> Would it be possible to add a new option to add fields to be read by
> available.packages, similar to filters?
> The same approach for fields as for filters would avoid the two workarounds
> mentioned. To match it, the new option could be named
> "available_packages_fields".

> I look forward to hearing from you,

> Lluís

>   [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> Kurt,

> Could you do me a favour and run on that clang18-using machine in question
> the following one-liner (provided your session has access to a .libPaths()
> including Rcpp) and, in the case of success, the resulting function?

I can: 

R> Rcpp::cppFunction("int ompconfigtest() { return omp_get_num_threads(); }", 
includes="#include ", plugin="openmp")
Warning in Rcpp::cppFunction("int ompconfigtest() { return 
omp_get_num_threads(); }",  :
  partial argument match of 'plugin' to 'plugins'
R>  ompconfigtest()
[1] 1

The system has OpenMP, but R was configured not to use it.

In general, packages should leave the decision to use OpenMP to the
*user*, who can use their own Makevars files to override the R system
Makevars SHLIB_OPENMP_* settings as desired.  

Best
-k


>> Rcpp::cppFunction("int ompconfigtest() { return omp_get_num_threads(); }", 
>> includes="#include ", plugin="openmp")
>> ompconfigtest()
>   [1] 1
>> 

> On a "normal" development machine such as mine here it works.

> Presumably it will fail at your end because -fopenmp will not be / cannot be
> substituted in from the openmp plugin defined by Rcpp:

>   ## built-in OpenMP plugin
>   .plugins[["openmp"]] <- function() {
>   list(env = list(PKG_CXXFLAGS="-fopenmp",
>   PKG_LIBS="-fopenmp"))
>   }

> but it would be nice to know if that does indeed fail.

> Thanks,  Dirk

> -- 
> 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] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> On 23 May 2024 at 20:02, Ivan Krylov wrote:
> | On Wed, 22 May 2024 09:18:13 -0500
> | Dirk Eddelbuettel  wrote:
> | 
> | > Testing via 'nm' as you show is possible but not exactly 'portable'.
> | > So any suggestions as to what to condition on here?
> | 
> | (My apologies if you already got an answer from Kurt. I think we're not
> | seeing his mails to the list.)
> | 
> | Perhaps take the configure test a bit further and try to dyn.load() the
> | resulting shared object? To be extra sure, call the function that uses
> | the OpenMP features? (Some weird systems may have lazy binding enabled,
> | making dyn.load() succeed but crashing the process on invocation of a
> | missing function.)
> | 
> | On GNU/Linux, the linker will happily leave undefined symbols in when
> | creating a shared library (unlike on, say, Windows, where extern void
> | foo(void); foo(); is a link-time error unless an object file or an
> | import library providing foo() is also present). When loading such a
> | library, the operation fails unless the missing symbols are already
> | present in the address space of the process (e.g. from a different
> | shared library).
> | 
> | A fresh process of R built without OpenMP support will neither link in
> | the OpenMP runtime while running SHLIB nor have the OpenMP runtime
> | loaded and so should successfully fail the test.
> | 
> | I also wouldn't call the entry point "main" just in case some future
> | compiler considers this a violation of the rules™ [*] and breaks the
> | code. extern "C" void configtest(int*) would be compatible with .C()
> | without having to talk to R's memory manager:
> | 
> | # The configure script:
> | cat > test-omp.cpp < | #include 
> | extern "C" void configtest(int * arg) {
> |   *arg = omp_get_num_threads();
> | }
> | EOF
> | # Without the following you're relying on the GNU/Linux-like behaviour
> | # w.r.t. undefined symbols (see WRE 1.2.1.1):
> | cat > Makevars < | PKG_CXXFLAGS = \$(SHLIB_OPENMP_CXXFLAGS)
> | PKG_LIBS = \$(SHLIB_OPENMP_CXXFLAGS)
> | EOF
> | R CMD SHLIB test-omp.cpp
> | 
> | # And then in R:
> | dyn.load(paste0("test-omp", .Platform$dynlib.ext))
> | # There's probably no need to test the return value, right?
> | .C("configtest", arg = integer(1))$arg

That seems a very nice way of following WRE's 

  If you do use your own checks, make sure that OpenMP support is
  complete by compiling and linking an OpenMP-using program

Modulo not hard-wiring 'R' in the configure code, and instead doing the
usual

  : ${R_HOME=`R RHOME`}
  if test -z "${R_HOME}"; then
echo "could not determine R_HOME"
exit 1
  fi
  
  "${R_HOME}/bin/R" CMD SHLIB .

etc.

Best
-k

> Given that comes from RcppArmadillo we can rely on Rcpp::cppFunction() or
> Rcpp::sourceCpp() which should make that dance a little simpler.

> I had forgotten this was in fact a home-grown shell snippet (per `git blame`
> last polished by Kevin, now CC'ed, in 2020).  That should make an explicit
> load -- and noticing when we fail to load -- feasible.

> Maybe someone has time and appetite for contributing a PR?

> Cheers, Dirk

> | -- 
> | Best regards,
> | Ivan
> | 
> | [*]
> | In C++, main() is the function-that-must-not-be-named:
> | https://en.cppreference.com/w/cpp/language/main_function

> -- 
> 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: [Rd] max on numeric_version with long components

[Kurt Hornik]

>>>>> Kurt Hornik writes:

Should be fixed now.

Best
-k

>>>>> Ivan Krylov via R-devel writes:
> Indeed, apparently using which.min/which.max on the string encoding is
> not good enough.  ? which.min says that x can also be

>   an R object for which the internal coercion to ‘double’ works 

> and I guess we found a case where it does not work.

> I'll look into fixing this, but perhaps we should re-open
> <https://bugs.r-project.org/show_bug.cgi?id=18697> ?

> -k

>> В Sat, 27 Apr 2024 13:56:58 -0500
>> Jonathan Keane  пишет:

>>> In devel:
>>> > max(numeric_version(c("1.0.1.1", "1.0.3.1",  
>>> "1.0.2.1")))
>>> [1] ‘1.0.1.1’
>>> > max(numeric_version(c("1.0.1.1000", "1.0.3.1000",  
>>> "1.0.2.1000")))
>>> [1] ‘1.0.3.1000’

>> Thank you Jon for spotting this!

>> This is an unintended consequence of
>> https://bugs.r-project.org/show_bug.cgi?id=18697.

>> The old behaviour of max() was to call
>> which.max(xtfrm(x)), which first produced a permutation that sorted the
>> entire .encode_numeric_version(x). The new behavioiur is to call
>> which.max directly on .encode_numeric_version(x), which is faster (only
>> O(length(x)) instead of a sort).

>> What do the encoded version strings look like?

>> x <- numeric_version(c(
>> "1.0.1.1", "1.0.3.1", "1.0.2.1"
>> ))
>> # Ignore the attributes
>> (e <- as.vector(.encode_numeric_version(x)))
>> # [1] "101575360400"
>> # [2] "103575360400"
>> # [3] "102575360400"

>> # order(), xtfrm(), sort() all agree that e[2] is the maximum:
>> order(e)
>> # [1] 1 3 2
>> xtfrm(e)
>> # [1] 1 3 2
>> sort(e)
>> # [1] "101575360400"
>> # [2] "102575360400"
>> # [3] "103575360400"

>> # but not which.max:
>> which.max(e)
>> # [1] 1

>> This happens because which.max() converts its argument to double, which
>> loses precision:

>> (n <- as.numeric(e))
>> # [1] 1e+27 1e+27 1e+27
>> identical(n[1], n[2])
>> # [1] TRUE
>> identical(n[3], n[2])
>> # [1] TRUE

>> Will be curious to know if there is a clever way to keep both the O(N)
>> complexity and the full arbitrary precision.

>> -- 
>> Best regards,
>> Ivan

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

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

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

Re: [Rd] Petition to set warnPartialMatch* options to TRUE

[Kurt Hornik]

> Therneau, Terry M , Ph D writes:

> Let me give partial assent to Michael's suggestion:  a) have an easy way to
> turn this on and b) add a strong suggestion to do so to the WRE manual.   
> Kurt's example in the email shows how to do (a);  but I just looked in the
> WRE manual and don't see any reference to it, nor any mention from R CMD
> check --help, so I don't know where I would have found out about it.

> I have gotton warnings about partial matches from CRAN  wrt the survival
> package --- I suspect at the benefit of Kurt  --- and though I muttered under
> my breath about it at the time there is no doubt that it was a good idea to
> fix all of them, and I'm glad for the nudge.

> Kurt: does that envionment variable contain the options string itself, or
> does it point to a file containing the options?

The latter: one can use _R_CHECK_EXAMPLES_PROFILE_ to point to a profile
containing e.g.

options(warnPartialMatchArgs = TRUE,
warnPartialMatchAttr = TRUE,
warnPartialMatchDollar = TRUE,
showErrorCalls = TRUE,
showWarnCalls = TRUE)

Best
-k

> I appreciate partial matching when typing code at the terminal so want the
> feature to remain in that context.

> Terry T

> -- 
> Terry M Therneau, PhD
> Department of Quantitative Health Sciences
> Mayo Clinic
> thern...@mayo.edu

> "TERR-ree THUR-noh"

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

Re: [Rd] max on numeric_version with long components

[Kurt Hornik]

> Ivan Krylov via R-devel writes:

Indeed, apparently using which.min/which.max on the string encoding is
not good enough.  ? which.min says that x can also be

  an R object for which the internal coercion to ‘double’ works 

and I guess we found a case where it does not work.

I'll look into fixing this, but perhaps we should re-open
 ?

-k

> В Sat, 27 Apr 2024 13:56:58 -0500
> Jonathan Keane  пишет:

>> In devel:
>> > max(numeric_version(c("1.0.1.1", "1.0.3.1",  
>> "1.0.2.1")))
>> [1] ‘1.0.1.1’
>> > max(numeric_version(c("1.0.1.1000", "1.0.3.1000",  
>> "1.0.2.1000")))
>> [1] ‘1.0.3.1000’

> Thank you Jon for spotting this!

> This is an unintended consequence of
> https://bugs.r-project.org/show_bug.cgi?id=18697.

> The old behaviour of max() was to call
> which.max(xtfrm(x)), which first produced a permutation that sorted the
> entire .encode_numeric_version(x). The new behavioiur is to call
> which.max directly on .encode_numeric_version(x), which is faster (only
> O(length(x)) instead of a sort).

> What do the encoded version strings look like?

> x <- numeric_version(c(
>  "1.0.1.1", "1.0.3.1", "1.0.2.1"
> ))
> # Ignore the attributes
> (e <- as.vector(.encode_numeric_version(x)))
> # [1] "101575360400"
> # [2] "103575360400"
> # [3] "102575360400"

> # order(), xtfrm(), sort() all agree that e[2] is the maximum:
> order(e)
> # [1] 1 3 2
> xtfrm(e)
> # [1] 1 3 2
> sort(e)
> # [1] "101575360400"
> # [2] "102575360400"
> # [3] "103575360400"

> # but not which.max:
> which.max(e)
> # [1] 1

> This happens because which.max() converts its argument to double, which
> loses precision:

> (n <- as.numeric(e))
> # [1] 1e+27 1e+27 1e+27
> identical(n[1], n[2])
> # [1] TRUE
> identical(n[3], n[2])
> # [1] TRUE

> Will be curious to know if there is a clever way to keep both the O(N)
> complexity and the full arbitrary precision.

> -- 
> Best regards,
> Ivan

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

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

>>>>> Hervé Pagès writes:

> On 4/24/24 23:07, Kurt Hornik wrote:
>>>>>>> Hervé Pagès writes:
>>> Hi Kurt,
>>> Is it intended that numeric_version() returns an error by default on
>>> non-character input in R 4.4.0?
>> Dear Herve, yes, that's the intention.
>> 
>>> It seems that I can turn this into a warning by setting
>>> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
>>> seem to be able to find any of this mentioned in the NEWS file.
>> That's what I added for smoothing the transition: it will be removed
>> from the trunk shortly.

> Thanks for clarifying.  Could this be documented in the NEWS file? This 
> is a breaking change (it breaks a couple of Bioconductor packages) and 
> people are not going to set this environment variable if they are not 
> aware of it.

Sure, I'll look into adding something.  (Too late for 4.4.0, of course.)

Best
-k

> Thanks again,

> H.

>> 
>> Best
>> -k
>> 
>>> Thanks,
>>> H.
>>> On 4/1/24 05:28, Kurt Hornik wrote:
>>> Andrea Gilardi via R-devel writes:
>> 
>>> Thanks: should be fixed now in the trunk.
>> 
>>> Best
>>> -k
>>> Thank you very much Dirk for your kind words and for confirming the bug.
>>> Next week I will open a new issue on Bugzilla adding the related patch.
>> 
>>> Kind regards
>> 
>>> Andrea
>> 
>>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>> 
>>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>> | Dear all,
>>> |
>>> | I have a question regarding the R-devel version of 
>>> .make_numeric_version() function. As far as I can understand, the current 
>>> code 
>>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>>  runs the following steps in case of non-character input:
>>> |
>>> | 1. It creates a message named msg using gettextf.
>>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>>> the following condition
>>> |
>>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>>> "false")
>>> |
>>> | However, I don't understand the previous code since the output of 
>>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
>>> is just a boolean value and tolower() will just return "true" or "false". 
>>> Maybe the intended code is 
>>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>>> "false" ? Or am I missing something?
>> 
>>> Yes, agreed -- good catch.  In full, the code is (removing leading
>>> whitespace, and putting it back onto single lines)
>> 
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") 
>>> != "false"))
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>>> where msg is constant (but reflecting language settings via standard i18n)
>>> and as you not the parentheses appear wrong.  What was intended is likely
>> 
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>>> != "false")
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>>> If you use bugzilla before and have a handle, maybe file a bug report with
>>> this as patch athttps://bugs.r-project.org/
>> 
>>> Dirk
>>> __
>>> R-devel@r-project.org  mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>>> __
>>> R-devel@r-project.org  mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>>> -- 
>>> Hervé Pagès
>>> Bioconductor Core Team
>>> hpages.on.git...@gmail.com

> -- 
> Hervé Pagès

> Bioconductor Core Team
> hpages.on.git...@gmail.com

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

>>>>> Dirk Eddelbuettel writes:

> Hi Kurt,

> On 25 April 2024 at 08:07, Kurt Hornik wrote:
> | >>>>> Hervé Pagès writes:
> | 
> | > Hi Kurt,
> | > Is it intended that numeric_version() returns an error by default on
> | > non-character input in R 4.4.0? 
> | 
> | Dear Herve, yes, that's the intention.
> | 
> | > It seems that I can turn this into a warning by setting
> | > _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> | > seem to be able to find any of this mentioned in the NEWS file.
> | 
> | That's what I added for smoothing the transition: it will be removed
> | from the trunk shortly.

> I would actually be nice to have a more robust variant for non-CRAN
> versions. For example I just had to do a local hack to be able to use
> what the QuantLib 'rc' 1.34-rc reported (when I then used to R
> facilities to condition code and tests on whether I was dealing with
> code before or after an API transition).  So as a wishlist: could you
> envision an extension to package_version() casting that, say, removes
> all [a-zA-Z]+ first (if opted into) ?

Well, if I could turn back time and start again, I'd implement package
versions in the Debian way, and not numeric only.  As you know, the
current approach does not conveniently allow for handling binary
revisions or NMUs.

Currently, package_version extends numeric_version, but in principle
that could be changed: we would of course have to ensure that we go on
using numeric-only package versions for source packages so that older
versions of R can handle these.

One could in principle also enhance the 'strict' argument so that
e.g. strict = NA says drop all non-numeric non-sep parts, but it would
be better to first figure out whether it wouldn't be better to make
things work for non-numeric version components too :-)

Best
-k



> Dirk

> -- 
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

>>>>> Hervé Pagès writes:

> Hi Kurt,
> Is it intended that numeric_version() returns an error by default on
> non-character input in R 4.4.0? 

Dear Herve, yes, that's the intention.

> It seems that I can turn this into a warning by setting
> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> seem to be able to find any of this mentioned in the NEWS file.

That's what I added for smoothing the transition: it will be removed
from the trunk shortly.

Best
-k

> Thanks,

> H.

> On 4/1/24 05:28, Kurt Hornik wrote:

> Andrea Gilardi via R-devel writes:

> Thanks: should be fixed now in the trunk.

> Best
> -k

> Thank you very much Dirk for your kind words and for confirming the 
> bug. 
> Next week I will open a new issue on Bugzilla adding the related 
> patch.

> Kind regards

> Andrea

> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:

> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
> | Dear all,
> |
> | I have a question regarding the R-devel version of 
> .make_numeric_version() function. As far as I can understand, the current 
> code 
> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>  runs the following steps in case of non-character input:
> |
> | 1. It creates a message named msg using gettextf.
> | 2. Such object is then passed to stop(msg) or warning(msg) 
> according to the following condition
> |
> | 
> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
> "false")
> |
> | However, I don't understand the previous code since the output 
> of Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
> is just a boolean value and tolower() will just return "true" or "false". 
> Maybe the intended code is 
> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
> "false" ? Or am I missing something?

> Yes, agreed -- good catch.  In full, the code is (removing leading
> whitespace, and putting it back onto single lines)

> msg <- gettextf("invalid non-character version specification 'x' 
> (type: %s)", typeof(x))
> 
> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
> "false"))
> stop(msg, domain = NA)
> else
> warning(msg, domain = NA, immediate. = TRUE)

> where msg is constant (but reflecting language settings via 
> standard i18n)
> and as you not the parentheses appear wrong.  What was intended 
> is likely

> msg <- gettextf("invalid non-character version specification 'x' 
> (type: %s)", typeof(x))
> 
> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
> "false")
> stop(msg, domain = NA)
> else
> warning(msg, domain = NA, immediate. = TRUE)

> If you use bugzilla before and have a handle, maybe file a bug 
> report with
> this as patch at https://bugs.r-project.org/

> Dirk

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

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

> -- 
> Hervé Pagès

> Bioconductor Core Team
> hpages.on.git...@gmail.com

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

Re: [Rd] Petition to set warnPartialMatch* options to TRUE during R CMD check by default

[Kurt Hornik]

> Michael Chirico writes:

Michael,

You may have seen that some time ago I added

check.R:cprof <- Sys.getenv("_R_CHECK_EXAMPLES_PROFILE_", "")

etc so one can use the _R_CHECK_EXAMPLES_PROFILE_ env var to specify a
profile to use when running the examples, e.g.

options(warnPartialMatchArgs = TRUE,
warnPartialMatchAttr = TRUE,
warnPartialMatchDollar = TRUE)

In principle one could do this by default, because it has no effect:
such warnings in the output will not be seen in the check log by
default.  One could change that, but then the problem is that there is
no way to filter the warnings according to where they come from.

I had used the mechanism to eliminate partial matches from the base R
packages.  I had also tried using it for my own CRAN packages, and fixed
the ones under my control, and reported the others, most of which never
got fixed ...

Best
-k

> Hi all,
> What it says in the title. This is likely to cause a lot of CRAN packages
> to fail (I can try and quantify this if seen fit), but I think it's for the
> best. Packages should not (IMHO) be relying on partial matching in package
> code / tests. One might be more permissive for vignette/examples code,
> though I still find it poor practice.

> Among many reasons why package authors should resist using partial
> matching, today I saw this:

> upstream package A adds a new argument 'nb' to its print method, now there
> are two arguments 'na' and 'nb' starting with 'n'
> downstream package B importing A starts failing because it was using
> print(n=...) and relying on that resolving to na= but now it's ambiguous

> This feels like an unnecessary risk for considerate package A authors to
> need to take into account when designing their API. Yes, downstream package
> B "should" be broken & resubmitted to CRAN, but (1) there is some perceived
> "blame" for package A "causing B to be removed" and (2) the re-submitted
> package is by no means assured to be "safe" -- time-constrained B authors
> may just fix the minimum set of partially-matched calls while leaving
> potentially many other similar at-risk call sites unchanged.

> Better to enforce exact matching in package code globally, I think.

> It seems likely (given how options work in R) that committed authors will
> be able to sidestep the issue by disabling the PartialMatch warnings, but
> better to make this inconvenient with a stricter default.

> Mike C

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Andrea Gilardi via R-devel writes:

Thanks: should be fixed now in the trunk.

Best
-k

> Thank you very much Dirk for your kind words and for confirming the bug. 
> Next week I will open a new issue on Bugzilla adding the related patch.

> Kind regards

> Andrea

> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>> | Dear all,
>> |
>> | I have a question regarding the R-devel version of .make_numeric_version() 
>> function. As far as I can understand, the current code 
>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>  runs the following steps in case of non-character input:
>> |
>> | 1. It creates a message named msg using gettextf.
>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>> the following condition
>> |
>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false")
>> |
>> | However, I don't understand the previous code since the output of 
>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" is 
>> just a boolean value and tolower() will just return "true" or "false". Maybe 
>> the intended code is 
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>> "false" ? Or am I missing something?
>> 
>> Yes, agreed -- good catch.  In full, the code is (removing leading
>> whitespace, and putting it back onto single lines)
>> 
>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>> %s)", typeof(x))
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false"))
>> stop(msg, domain = NA)
>> else
>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>> where msg is constant (but reflecting language settings via standard i18n)
>> and as you not the parentheses appear wrong.  What was intended is likely
>> 
>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>> %s)", typeof(x))
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>> != "false")
>> stop(msg, domain = NA)
>> else
>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>> If you use bugzilla before and have a handle, maybe file a bug report with
>> this as patch at https://bugs.r-project.org/
>> 
>> Dirk
>> 

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

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

Re: [Rd] as.roman upper limit

[Kurt Hornik]

> Jonathan Carroll writes:

Thanks.

Fascinating ... I strongly suspect that when I wrote the code in 2006
the docs said the largest possible number was 3899.  Of course, I should
have added a comment on this with a pointer to the docs ...

In any case, clearly  etc
say that we can do up to 3999, so this should be looked into.

Can you please file a PR so that this does not get forgotten?

Ideally perhaps also with a patch? :-)

Best
-k

> I was recently participating in a coding challenge which involved
> converting integers to Roman numerals. I knew R offers this
> functionality already via as.roman() and hoped to leverage that for a
> quick solution, but was surprised that one of the challenge's tests
> failed; conversion of the number 3999, which should result in
> "MMMCMXCIX". In R, that produces NA.

> I looked into the source and documentation and it's clear that an
> upper limit of 3899 is enforced in several places, and documented as
> such. I detailed some of these explorations on my blog [0]. Ben Bolker
> traced the first implementation (or at the least the creation of
> src/library/utils/R/roman.R) in the (GitHub cloned) source [1] dating
> back to 2006 and this uses the 3899 hard limit.

> Wikipedia [2] claims the largest uniquely representable Roman numeral is 3999.

> Other languages appear to use 3999 as the largest input value, e.g.
> the python-cookbook [3].

> Common lisp's "~@r" format errors with values larger than 3999

> ```
> (print (format nil "~@r" 4000))
> *** - The ~@R format directive requires an integer in the range 1 -
> 3999, not 4000
> ```

> Is 3899 enforced as the largest valid input in R for some other
> reason, or is this a long-standing oversight?

> Perhaps tangentially... while exploring I did notice the unexported
> utils:::.as.roman() takes a check.range argument that is not available
> from as.roman (which is simply an exported wrapper without that
> argument) but setting this to FALSE does not enable circumvention of
> enforcement of the upper limit (which appears to occur during the
> setting of the "roman" class), it simply performs an earlier
> conversion to NA when set (potentially for simplification when used in
> Ops dispatch). Enforcement of the limit of 3899 happens deeper within
> the code, e.g. within the unexported utils:::.numeric2roman which
> implements the conversion, but without a way to avoid setting the
> result to NA for larger values. Given that other languages strictly
> limit the input to an upper bound, perhaps this is not unexpected
> behaviour.

> Regards,

> - Jonathan.

> [0]: https://jcarroll.xyz/2024/02/10/friends-romans-countrymen.html
> [1]: 
> https://github.com/r-devel/r-svn/commit/ba30f3dc716effe22489bf88511bd1d60272f6de
> [2]: https://en.wikipedia.org/wiki/Roman_numerals
> [3]: 
> https://www.oreilly.com/library/view/python-cookbook/0596001673/ch03s24.html

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

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

Re: [Rd] Small typo in Sweave.Rnw

[Kurt Hornik]

> Enrico Schumann writes:

Great, thanks: changed now.

Best
-k

> In the first paragraph of Sweave.Rnw
> (./src/library/utils/vignettes/Sweave.Rnw), it reads

>   for literate programming \cite{fla:Knuth:1984}.

> but probably should be

>   for literate programming \citep{fla:Knuth:1984}.
> ^

> kind regards
> Enrico

> -- 
> Enrico Schumann
> Lucerne, Switzerland
> http://enricoschumann.net

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

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

Re: [Rd] [R-pkg-devel] Problem with "compacting" pdf files.

[Kurt Hornik]

> Ivan Krylov writes:

Thanks: committed now.

Best
-k

> Dear Rolf,
> (Moving this one to R-devel...)

> On Sun,  1 Oct 2023 21:01:13 +
> Rolf Turner  wrote:

>> I *really* think that the instructions from CRAN could have been
>> clearer!  Without your guidance I'd have been at a total loss.

> Since the CRAN e-mails quote the R CMD check messages verbatim, would
> it have been enough if R CMD check suggested using --compact-vignettes?

> Index: src/library/tools/R/check.R
> ===
> --- src/library/tools/R/check.R   (revision 85249)
> +++ src/library/tools/R/check.R   (working copy)
> @@ -3079,7 +3079,8 @@
>   "  'qpdf' made some significant size reductions:\n",
>   paste("  ", res, collapse = "\n"),
>   "\n",
> - "  consider running tools::compactPDF() on these 
> files\n")
> + "  consider running tools::compactPDF() on these 
> files,\n",
> + "  or build the source package with 
> --compact-vignettes\n")
>  }
>  if (R_check_doc_sizes2) {
>  gs_cmd <- find_gs_cmd()
> @@ -3093,7 +3094,8 @@
>   "  'gs+qpdf' made some significant size 
> reductions:\n",
>   paste("  ", res, collapse = "\n"),
>   "\n",
> - '  consider running 
> tools::compactPDF(gs_quality = "ebook") on these files\n')
> + '  consider running 
> tools::compactPDF(gs_quality = "ebook") on these files,\n',
> + '  or build the source package with 
> --compact-vignettes=both\n')
>  }
>  } else {
>  if (!any) noteLog(Log)

> Or is there anything else you would prefer to be reworded? Should the
> message link to Writing R Extensions, section 1.4? Recently there was a
> project to improve the R CMD check messages [*], but I managed to miss
> almost all of it.

> -- 
> Best regards,
> Ivan

> [*] https://github.com/r-devel/r-project-sprint-2023/issues/55

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

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

Re: [Rd] bug in utils:::format.person

[Kurt Hornik]

> Achim Zeileis writes:

Thanks---Ivan's fix committed now with c84497.

Best
-k

> Apologies, I missed Ivan's fix to the problem (my day was too long...) 
> which is, of course, better than mine.

> On Sat, 3 Jun 2023, Achim Zeileis wrote:

>> Thierry,
>> 
>> thanks for this, this is a bug in utils:::.format_person_as_R_code(). This 
>> calls deparse() on the elements of the person object with the default 
>> width.cutoff = 60. As your comment exceeds this width, the erroneous 
>> formatting is produced. The simplest reproducible example I could come up 
>> with was:
>> 
>> p <- person(".", comment = c(foo = ".",
>> bar = "."))
>> writeLines(format(p, style = "R"))
>> 
>> This can be fixed in line 1017 of utils/R/citation.R either by increasing 
>> the 
>> width.cutoff, e.g.,
>> 
>> sprintf("%s = %s", names(e), sapply(e, deparse, width.cutoff = 500L))
>> 
>> but, of course, this still has an arbitrary cutoff. So maybe better
>> 
>> sprintf("%s = %s", names(e), sapply(e,
>> function(x) paste(deparse(x), collapse = "")))
>> 
>> which should work.
>> 
>> I'll ping Kurt about this and try to coordinate a fix.
>> 
>> Best wishes,
>> Achim
>> 
>> 
>> On Fri, 2 Jun 2023, Thierry Onkelinx via R-devel wrote:
>> 
>>> Dear all,
>>> 
>>> I think I found a bug in utils::format.person when using style = "R" with a
>>> vector of comments. The comment section is not parsed properly. Please find
>>> below the mwe and the session info.
>>> 
>>> Best regards,
>>> 
>>> Thierry
>>> 
>>> maintainer <- person(
>>> given = "Thierry", family = "Onkelinx", role = c("aut", "cre"),
>>> email = "thierry.onkel...@inbo.be",
>>> comment = c(
>>> ORCID = "-0001-8804-4216",
>>> affiliation = "Research Institute for Nature and Forest (INBO)"
>>> )
>>> )
>>> format(maintainer, style = "R") |>
>>> cat(sep = "\n")
>>> # output
>>> person(given = "Thierry",
>>> family = "Onkelinx",
>>> role = c("aut", "cre"),
>>> email = "thierry.onkel...@inbo.be",
>>> comment = c("c(ORCID = \"-0001-8804-4216\", affiliation =
>>> \"Research Institute for Nature and Forest (INBO)\"", ")"))
>>> 
>>> ─ Session info
>>> ──
>>> setting  value
>>> version  R version 4.3.0 (2023-04-21)
>>> os   Ubuntu 22.04.2 LTS
>>> system   x86_64, linux-gnu
>>> ui   X11
>>> language nl_BE:nl
>>> collate  nl_BE.UTF-8
>>> ctypenl_BE.UTF-8
>>> tz   Europe/Brussels
>>> date 2023-06-02
>>> pandoc   NA
>>> 
>>> ─ Packages
>>> ──
>>> package * version date (UTC) lib source
>>> cli   3.6.1   2023-03-23 [1] CRAN (R 4.3.0)
>>> fortunes  1.5-4   2016-12-29 [1] CRAN (R 4.3.0)
>>> sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.3.0)
>>> 
>>> 
>>> 
>>> ir. Thierry Onkelinx
>>> Statisticus / Statistician
>>> 
>>> Vlaamse Overheid / Government of Flanders
>>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
>>> FOREST
>>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
>>> thierry.onkel...@inbo.be
>>> Havenlaan 88 bus 73, 1000 Brussel
>>> www.inbo.be
>>> 
>>> ///
>>> To call in the statistician after the experiment is done may be no more
>>> than asking him to perform a post-mortem examination: he may be able to say
>>> what the experiment died of. ~ Sir Ronald Aylmer Fisher
>>> The plural of anecdote is not data. ~ Roger Brinner
>>> The combination of some data and an aching desire for an answer does not
>>> ensure that a reasonable answer can be extracted from a given body of data.
>>> ~ John Tukey
>>> ///
>>> 
>>> 
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Kurt Hornik]

>>>>> Karolis Koncevičius writes:

> But this might require a more detailed investigation. For example I
> just noticed that even with the patch `@` is still not listed in
> .S3_methods_table().

Afaict base does not register any methods for @ or @<- ?

-k

> KK.

>> On Apr 29, 2023, at 4:44 PM, Karolis Koncevičius 
>>  wrote:
>> 
>> Hello Kurt,
>> 
>> With r84341 it now works on my side.
>> 
>> Warm regards,
>> Karolis K.
>> 
>>> On Apr 29, 2023, at 1:24 PM, Kurt Hornik  wrote:
>>> 
>>>>>>>> Karolis Koncevičius writes:
>>> 
>>> Can you pls try again with r84341 or later?
>>> 
>>> Best
>>> -k
>>> 
>>>> A more concrete example in order to correct my vague messages below.
>>>> Writing an R package that uses `@` and `@<-` as S3 generics. Line from 
>>>> manual pages in .Rd files:
>>> 
>>>> \method{@}{newclass}(object, name) <- value
>>> 
>>>> Throws this error during R CMD check —as-cran
>>> 
>>>> Bad \usage lines found in documentation object ’code’:
>>>> method{@}{newclass}(object, name) <- value
>>> 
>>>> This error is due to tools::checkDocFiles eventually calling 
>>>> tools:::.S3_method_markup_regexp and not finding `@` as a valid for S3.
>>>> This error is gone if we adjust tools:::.S3_method_markup_regexp to pass 
>>>> for ‘@‘ by adding ‘\\@‘ to regexp.
>>> 
>>>> Please note that this now is not dependant on using or not using roxygen2
>>>> KK.
>>> 
>>>>> On Apr 29, 2023, at 12:53 AM, Karolis Koncevičius 
>>>>>  wrote:
>>>>> 
>>>>> Thank you for such a quick reply, Gabriel,
>>>>> 
>>>>> I am not too familiar with the package tools, so cannot speak too 
>>>>> confidently, but below is how I see the issue currently.
>>>>> 
>>>>> The issue is not for external packages to rely on unexported functions 
>>>>> from tools::, rather the issue is that 'R CMD check —as-cran' runs those 
>>>>> functions from tools:: in order to check the validity of Rd files (from 
>>>>> any package). R 4.3.0 added @ as internal S3 generic. However, package 
>>>>> tools does not recognise it as valid in Rd files and throws errors when 
>>>>> it sees S3 method declared for @ in the Rd usage lines.
>>>>> 
>>>>> So any package that will try to use @ generic will run into the issue, 
>>>>> without attempting to use internal S3 functions in their code, but during 
>>>>> the R CMD check step.
>>>>> 
>>>>> Hope I am being clearer now, and not missing something important (all 
>>>>> these things: both @ as generic and tools:: package are quite new to me),
>>>>> Karolis K.
>>>>> 
>>>>> On Apr 29, 2023, at 12:38 AM, Gabriel Becker  
>>>>> wrote:
>>>>> 
>>>>> Karolis,
>>>>> 
>>>>> It seems likely, without having looked myself, that you could be correct 
>>>>> about the issue, but it does seem worth noting that both of the functions 
>>>>> you have mentioned are not exported, and thus not part of the API that 
>>>>> extension packages are allowed to use and rely on.
>>>>> 
>>>>> If retrieving the list of "internal S3 generics" is something package and 
>>>>> user code is allowed to do, the real fix seems to go beyond what you're 
>>>>> suggesting, to actually providing an API entry point that gives the 
>>>>> relevant information (maybe in an identical form to how those internal 
>>>>> functions do so, maybe not). If it's not, for some principled reason, 
>>>>> something R-core wants to support package and user code doing, then the 
>>>>> fact that the new thing doesn't work automatically with roxygen2 would 
>>>>> become the roxygen maintainers' job to fix or document. 
>>>>> 
>>>>> I do not know whether R-core feels this is something packages/users 
>>>>> should be able to do; both decisions strike me as possible, to be honest, 
>>>>> depending on details I don't know and/or am not privy to.
>>>>> 
>>>>> Best,
>>>>> ~G 
>>>>> 
>>>>> On Fri, Apr 28, 2023 at 1:49 PM Karolis Koncevičius 
>>&g

Re: [Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Kurt Hornik]

> Karolis Koncevičius writes:

Can you pls try again with r84341 or later?

Best
-k

> A more concrete example in order to correct my vague messages below.
> Writing an R package that uses `@` and `@<-` as S3 generics. Line from manual 
> pages in .Rd files:

> \method{@}{newclass}(object, name) <- value

> Throws this error during R CMD check —as-cran

> Bad \usage lines found in documentation object ’code’:
>   method{@}{newclass}(object, name) <- value

> This error is due to tools::checkDocFiles eventually calling 
> tools:::.S3_method_markup_regexp and not finding `@` as a valid for S3.
> This error is gone if we adjust tools:::.S3_method_markup_regexp to pass for 
> ‘@‘ by adding ‘\\@‘ to regexp.

> Please note that this now is not dependant on using or not using roxygen2
> KK.

>> On Apr 29, 2023, at 12:53 AM, Karolis Koncevičius 
>>  wrote:
>> 
>> Thank you for such a quick reply, Gabriel,
>> 
>> I am not too familiar with the package tools, so cannot speak too 
>> confidently, but below is how I see the issue currently.
>> 
>> The issue is not for external packages to rely on unexported functions from 
>> tools::, rather the issue is that 'R CMD check —as-cran' runs those 
>> functions from tools:: in order to check the validity of Rd files (from any 
>> package). R 4.3.0 added @ as internal S3 generic. However, package tools 
>> does not recognise it as valid in Rd files and throws errors when it sees S3 
>> method declared for @ in the Rd usage lines.
>> 
>> So any package that will try to use @ generic will run into the issue, 
>> without attempting to use internal S3 functions in their code, but during 
>> the R CMD check step.
>> 
>> Hope I am being clearer now, and not missing something important (all these 
>> things: both @ as generic and tools:: package are quite new to me),
>> Karolis K.
>> 
>>> On Apr 29, 2023, at 12:38 AM, Gabriel Becker  wrote:
>>> 
>>> Karolis,
>>> 
>>> It seems likely, without having looked myself, that you could be correct 
>>> about the issue, but it does seem worth noting that both of the functions 
>>> you have mentioned are not exported, and thus not part of the API that 
>>> extension packages are allowed to use and rely on.
>>> 
>>> If retrieving the list of "internal S3 generics" is something package and 
>>> user code is allowed to do, the real fix seems to go beyond what you're 
>>> suggesting, to actually providing an API entry point that gives the 
>>> relevant information (maybe in an identical form to how those internal 
>>> functions do so, maybe not). If it's not, for some principled reason, 
>>> something R-core wants to support package and user code doing, then the 
>>> fact that the new thing doesn't work automatically with roxygen2 would 
>>> become the roxygen maintainers' job to fix or document. 
>>> 
>>> I do not know whether R-core feels this is something packages/users should 
>>> be able to do; both decisions strike me as possible, to be honest, 
>>> depending on details I don't know and/or am not privy to.
>>> 
>>> Best,
>>> ~G 
>>> 
>>> On Fri, Apr 28, 2023 at 1:49 PM Karolis Koncevičius 
>>> mailto:karolis.koncevic...@gmail.com>> 
>>> wrote:
 This issue might go deeper - I was not successful in passing R CMD checks 
 for the usage files. R CMD check kept showing errors for `@` declarations, 
 even thou they were identical to `$` declarations (which passed fine).
 
 Seems like the usage check functions are not prepared for `@` - also in 
 tools:::.S3_method_markup_regexp
 
 > On Apr 28, 2023, at 10:34 PM, Karolis Koncevičius 
 > mailto:karolis.koncevic...@gmail.com>> 
 > wrote:
 > 
 > I was building a package that uses the new generic @ and kept having 
 > errors with “roxygen2” documentation. “roxygen2” generated NAMESPACE 
 > added `@.newclass` as a newly exported function, not as a S3method.
 > 
 > At first I thought this must be a bug in roxygen2 and they lag behind 
 > the new developments in R. But after some investigation I found that 
 > “roxygen2” is using tools:::.get_internal_S3_generis() to decide if the 
 > method should be exported as S3method or not. For some reason “@<-“ is 
 > listed in there, but “@“ is not.
 > 
 > Am I missing some context, or is this an oversight?
 > 
 > Kind regards,
 > Karolis Koncevicius
 
 __
 R-devel@r-project.org  mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>> 


>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Incorrect behavior of ks.test and psmirnov functions with exact=TRUE

[Kurt Hornik]

> Alexey Sergushichev writes:

Thanks.  This is now fixed for the upcoming 4.3.0 release.

Best
-k

> HI,
> I've noticed what I think is an incorrect behavior of stats::psmirnov
> function and consequently of ks.test when run in an exact mode.

> For example:
> psmirnov(1, sizes=c(50, 50), z=1:100, two.sided = FALSE, lower.tail = F,
> exact=TRUE)

> produces 2.775558e-15

> However, the exact value should be 1/combination(100, 50), which is
> 9.9e-30. While the absolute error is small, the relative error is huge, and
> it is not fixed by setting option log.p=T

> To compare, SciPy has a correct implementation in scipy.stats.ks_2samp:
> scipy.stats.ks_2samp(list(range(1,51)), list(range(51, 101)),
> alternative="greater", method="exact")
> returns 9.911653021418333e-30.

> I've tried to dig in a bit and the problem comes down to how the final
> value is calculated in psmirnov function:

> if (log.p & !lower.tail)
> return(log1p(-ret/exp(logdenom)))
> if (!log.p & !lower.tail)
> return(1 - ret/exp(logdenom))

> There exp(logdenom) is a relatively good (but not perfect) approximation of
> combination(100, 50) = 1.008913e+29, ret is also a good approximation of
> combination(100, 50)-1 = 1.008913e+29 but there is not enough double
> precision for 1 - ret/exp(logdenom) to capture 1/combination(100, 50).

> I don't have time to provide a fix, at least not now, but I think this
> behavior (good absolute error, but poor relative error for small values)
> should at least be mentioned in the manual of the methods psmirnov and/or
> ks.test

> Best,
> Alexey Sergushichev

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Not documenting a function and not getting a check error?

[Kurt Hornik]

> Duncan Murdoch writes:

> On 06/01/2023 5:25 a.m., Kevin Coombes wrote:
>> I am fairly certain that the check for documentation is really just a 
>> check for the presence of the function name in an "alias" line. 

> Yes, that's what the test does, and that's fine.  The problem is with
> the usage test in tools::codoc().  If I had incorrect arguments
> specified for a documented function, I'd be warned.  If I skip the
> usage docs completely, I am not warned.

> I think the test belongs around here in the source:

> https://github.com/r-devel/r-svn/blob/b57918fd104962415a752ea7db12dcf4f3f5219f/src/library/tools/R/QC.R#L585

> If you look there, you see a variable named 
> "functions_in_usages_not_in_code" but nothing named 
> "functions_in_code_not_in_usages".

Actually, IIuc the infrastructure is there, but it is not used.
print.codoc() has

## In general, functions in the code which only have an \alias but
## no \usage entry are not necessarily a problem---they might be
## mentioned in other parts of the Rd object documenting them, or be
## 'internal'.  However, if a package has a namespace, then all
## *exported* functions should have \usage entries (apart from
## defunct functions and S4 generics, see the above comments for
## functions_missing_from_usages).  Currently, this information is
## returned in the codoc object but not shown.  Eventually, we might
## add something like
## functions_missing_from_usages <-
## attr(x, "functions_missing_from_usages")
## if(length(functions_missing_from_usages)) {
## writeLines("Exported functions without usage information:")
## .pretty_print(functions_in_code_not_in_usages)
## writeLines("")
## }
## similar to the above.

which goes back to sometimes 2009 ...

Best
-k

> Duncan Murdoch


> My
>> circumstantial evidence, from a package in the early stages of 
>> development, came from changing the name of a function. I updated 
>> everything else (usage, examples, etc.) but forgot to change the alias. 
>> Got a warning that the newly named function was not documented. It took 
>> me a while to figure out why R CMD check was still complaining.
>> 
>> I am also pretty sure that, when looking for help in at least one 
>> existing package (can't remember which one), I clicked on the link and 
>> got sent to a page that said absolutely nothing about the function I was 
>> interested in.
>> 
>> On Fri, Jan 6, 2023, 4:48 AM Duncan Murdoch > > wrote:
>> 
>> On 05/01/2023 10:10 p.m., Deepayan Sarkar wrote:
>> > On Fri, Jan 6, 2023 at 1:49 AM Duncan Murdoch
>> mailto:murdoch.dun...@gmail.com>> wrote:
>> >>
>> >> I'm in the process of a fairly large overhaul of the exports
>> from the
>> >> rgl package, with an aim of simplifying maintenance of the package.
>> >> During this work, I came across the reverse dependency geomorph that
>> >> calls the rgl.primitive function.
>> >>
>> >> I had forgotten that rgl.primitive was still exported:  I've been
>> >> thinking of it as an internal function for a few years now.  I was
>> >> surprised geomorph was able to call it.
>> >>
>> >> Particularly surprising to me was the fact that it is not properly
>> >> documented.  One of the help topics lists it as an alias, but it
>> >> contains no usage info, and is not mentioned in the .Rd file
>> other than
>> >> the alias.  And yet "R CMD check rgl" has never complained about it.
>> >>
>> >> Is this intentional?
>> >
>> > Does the Rd file that documents it have \keyword{internal}? These are
>> > not checked fully (as I realized recently while working on the help
>> > system), and I guess that's intentional.
>> 
>> No, not marked internal.  Here's a simple example:  a package that
>> exports f and g, and has only one help page:
>> 
>> -
>> NAMESPACE:
>> -
>> export(f, g)
>> -
>> 
>> -
>> R/source.R:
>> -
>> f <- function() "this is f"
>> 
>> g <- function() "this is g"
>> -
>> 
>> -
>> man/f.Rd:
>> -
>> \name{f}
>> \alias{f}
>> \alias{g}
>> \title{
>> This is f.
>> }
>> \description{
>> This does nothing
>> }
>> \usage{
>> f()
>> }
>> -
>> 
>> 
>> No complaints about the lack of documentation of g.
>> 
>> Duncan Murdoch
>> 
>> __
>> R-devel@r-project.org  mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 

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

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

Re: [Rd] Bug with `[<-.POSIXlt` on specific OSes

[Kurt Hornik]

> Davis Vaughan writes:

> I've got a bit more information about this one. It seems like it
> (only? not sure) appears when `TZ = "UTC"`, which is why I didn't see
> it before on my Mac, which defaults to `TZ = ""`. I think this is at
> least explainable by the fact that those "optional" fields aren't
> technically needed when the time zone is UTC.

Exactly.  Debugging `[<-.POSIlt` with

x <- as.POSIXlt(as.POSIXct("2013-01-31", tz = "America/Chicago"))
Sys.setenv(TZ = "UTC")
x[1] <- NA

shows we get into

value <- unclass(as.POSIXlt(value))
if (ici) {
for (n in names(x)) names(x[[n]]) <- nms
}
for (n in names(x)) x[[n]][i] <- value[[n]]

where

Browse[2]> names(value)
[1] "sec"   "min"   "hour"  "mday"  "mon"   "year"  "wday"  "yday"  "isdst"
Browse[2]> names(x)
 [1] "sec""min""hour"   "mday"   "mon""year"   "wday"   "yday"  
 [9] "isdst"  "zone"   "gmtoff"

Without having looked at the code, the docs say

 ‘zone’ (Optional.) The abbreviation for the time zone in force at
  that time: ‘""’ if unknown (but ‘""’ might also be used for
  UTC).

 ‘gmtoff’ (Optional.) The offset in seconds from GMT: positive
  values are East of the meridian.  Usually ‘NA’ if unknown,
  but ‘0’ could mean unknown.

so perhaps we should fill with the values for the unknown case?

-k

> I can reproduce this now on my personal Mac:

> ```

> x <- as.POSIXlt(as.POSIXct("2013-01-31", tz = "America/Chicago"))

> Sys.setenv(TZ = "")

> x[1] <- NA

> x

> #> [1] NA


> x <- as.POSIXlt(as.POSIXct("2013-01-31", tz = "America/Chicago"))

> Sys.setenv(TZ = "America/New_York")

> x[1] <- NA

> x

> #> [1] NA


> x <- as.POSIXlt(as.POSIXct("2013-01-31", tz = "America/Chicago"))

> Sys.setenv(TZ = "UTC")

> x[1] <- NA
> #> Error in x[[n]][i] <- value[[n]] : replacement has length zero

> x

> #> [1] "2013-01-31 CST"
> ```

> Here are `sessionInfo()` and `Sys.getenv("TZ")` outputs for 3 GitHub
> Actions platforms where the bug exists (note they all set `TZ = "UTC"`!):

> Linux:

> ```

>> sessionInfo()

> R version 4.2.1 (2022-06-23)

> Platform: x86_64-pc-linux-gnu (64-bit)

> Running under: Ubuntu 18.04.6 LTS


> Matrix products: default

> BLAS:   /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3

> LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so


> locale:

>  [1] LC_CTYPE=C.UTF-8   LC_NUMERIC=C   LC_TIME=C.UTF-8

>  [4] LC_COLLATE=C.UTF-8 LC_MONETARY=C.UTF-8LC_MESSAGES=C.UTF-8

>  [7] LC_PAPER=C.UTF-8   LC_NAME=C  LC_ADDRESS=C

> [10] LC_TELEPHONE=C LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C


> attached base packages:

> [1] stats graphics  grDevices utils datasets  methods   base


> loaded via a namespace (and not attached):

> [1] compiler_4.2.1


>> Sys.getenv("TZ")

> [1] "UTC"
> ```

> Mac:

> ```

>> sessionInfo()

> R version 4.2.1 (2022-06-23)

> Platform: x86_64-apple-darwin17.0 (64-bit)

> Running under: macOS Big Sur ... 10.16


> Matrix products: default

> BLAS:
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRblas.0.dylib

> LAPACK:
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib


> locale:

> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8


> attached base packages:

> [1] stats graphics  grDevices utils datasets  methods   base


> loaded via a namespace (and not attached):

> [1] compiler_4.2.1


>> Sys.getenv("TZ")

> [1] "UTC"
> ```

> Windows:
> This is the best I can get you, sorry (remote worker issues), but note that
> it does also say `tz UTC` like the others.

> ```
> version R version 4.2.1 (2022-06-23 ucrt)
> os Windows Server x64 (build 20348)
> system x86_64, mingw32
> ui RTerm
> language (EN)
> collate English_United States.utf8
> ctype English_United States.utf8
> tz UTC
> date 2022-10-11
> ```

> And here is my Mac where the bug doesn't show up by default because `TZ =
> ""`:

> ```

>> sessionInfo()

> R version 4.2.1 (2022-06-23)

> Platform: x86_64-apple-darwin17.0 (64-bit)

> Running under: macOS Big Sur ... 10.16


> Matrix products: default

> BLAS:
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRblas.0.dylib

> LAPACK:
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib


> locale:

> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8


> attached base packages:

> [1] stats graphics  grDevices utils datasets  methods   base


> loaded via a namespace (and not attached):

> [1] compiler_4.2.1


>> Sys.getenv("TZ")

> [1] ""


>> Sys.timezone()

> [1] "America/New_York"
> ```

> -Davis


> On Thu, Oct 6, 2022 at 9:33 AM Davis Vaughan  wrote:

>> Hi all,
>> 
>> I have found another POSIXlt bug while I've been fiddling around with it.
>> This one only appears on specific OSes, because it has to do with the fact
>> that the `gmtoff` field is optional, and isn't always used on all OSes. It
>> also doesn't seem to be specific 

Re: [Rd] Date method of as.POSIXct does not respect tz

[Kurt Hornik]

> Martin Maechler writes:

Currently in R-devel,

R> as.POSIXlt.Date
function (x, ...) 
{
if (any((y <- unclass(x)) > .Machine$integer.max, na.rm = TRUE)) 
as.POSIXlt(.POSIXct(y * 86400), tz = "UTC")
else .Internal(Date2POSIXlt(x))
}

R> as.POSIXct.Date
function (x, ...) 
.POSIXct(unclass(x) * 86400)

Adding tz to the latter is easy, and the former could do the if() part
also with a given tz without needing to change the .Internal?

Best
-k

> Roland Fuß 
> on Tue, 20 Sep 2022 09:25:52 +0200 writes:

>> Hello, May I follow up on this? Has it fallen through the
>> cracks or were there considerations against passing `tz`
>> to `.POSIXct`?

>> Regards,
>> Roland

> Hmm...  I don't remember  even though I had replied positively
> to your question in May 2018.

> PROS (for allowing 'tz') to be passed to
>    as.POSIXct.Date()  and hence ideally also to as.POSIXlt.Date() 

> 1) as.POSIXct() and as.POSIXlt()   all show with a 'tz' argument
>   on the help page, and hence for consistency users should
>   really expect  that 'tz = ".."'  also works in these two cases:

>   Usage:

>  as.POSIXct(x, tz = "", ...)
>  as.POSIXlt(x, tz = "", ...)
 
>  ## S3 method for class 'character'
>  as.POSIXlt(x, tz = "", format,
> tryFormats = c("%Y-%m-%d %H:%M:%OS",
>"%Y/%m/%d %H:%M:%OS",
>"%Y-%m-%d %H:%M",
>"%Y/%m/%d %H:%M",
>"%Y-%m-%d",
>"%Y/%m/%d"),
> optional = FALSE, ...)
>  ## Default S3 method:
>  as.POSIXlt(x, tz = "",
> optional = FALSE, ...)
>  ## S3 method for class 'numeric'
>  as.POSIXlt(x, tz = "", origin, ...)


> 2) It is easy to be implemented for  as.POSIXct()   as you found
>already in 2018.


> CONS:
> -

> 3) The 'Details:' section on the help page,
>end of 1st paragraph says

>  Dates without times are treated as being at midnight UTC.

>So the current hardwired behavior is documented.

> 4a) For  as.POSIXlt.Date()  to allow passing 'tz' needs changes
>in the C code,  i.e., is considerable more work than for the as.POSIXct(),
>(or actually just post-processing in the R code, much less work)

> 4b) Only changing the behavior for as.POSIXct()  but not for as.POSIXlt()
> is also an inconsistency.


> My personal inclination would still be to do the change,
> by giving most weight to  '1)' above.

> What do other experienced R developers think ?

> Martin


>> Am 17.05.2018 um 19:55 schrieb Martin Maechler:
 Roland Fuß on Wed, 16 May 2018 17:21:07 +0200
 writes:
>>> > R 3.5.0 Is it intended that the Date method of
>>> as.POSIXct > does not respect the tz parameter? I suggest
>>> changing > as.POSIXct.Date
>>> 
>>> which is
>>> 
>>> function (x, ...) .POSIXct(unclass(x) * 86400)
>>> 
>>> > to this:
>>> 
>>> function (x, tz = "", ...)  .POSIXct(unclass(x) * 86400,
>>> tz = tz)
>>> 
>>> or rather just forward the '...', i.e., use
>>> 
>>> function (x, ...) .POSIXct(unclass(x) * 86400, ...)
>>> 
>>> ??
>>> 
>>> > Currently, the best workaround seems to be using the >
>>> character method if one doesn't want the default timezone
>>> > (which is often an annoying DST timezone).
>>> 
>>> > This came up on Stack Overflow: >
>>> https://stackoverflow.com/q/50373340/1412059
>>> 
>>> > --
>>> > Roland
>>> 
>>> Thank you Roland for your notice (and the help on SO).
>>> 
>>> Best, Martin

>> -- 
>> Dr. Roland Fuß

>> Thünen-Institut für Agrarklimaschutz/ Thünen Institute of
>> Climate-Smart Agriculture

>> Bundesallee 65 D-38116 Braunschweig, Germany

>> Tel.: ++49 531 596 2627 Fax: ++49 531 596 2699 Email:
>> roland.f...@thuenen.de

>> Arbeitsgruppe "Emissionsberichterstattung"/ Working group
>> "Emission Inventories" Email:
>> emissionsinvent...@thuenen.de

>> Das Johann Heinrich von Thünen-Institut,
>> Bundesforschungsinstitut für Ländliche Räume, Wald und
>> Fischerei – kurz: Thünen-Institut – besteht aus 15
>> Fachinstituten, die in den Bereichen Ökonomie, Ökologie
>> und Technologie forschen und die Politik beraten.

>> The Johann Heinrich von Thünen Institute, Federal Research
>> Institute for Rural Areas, Forestry and Fisheries – Thünen
>> Institute in brief – consists of 15 specialized institutes
>> that carry out research and provide policy advice in the
>> fields of economy, ecology and technology.

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

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

Re: [Rd] [External] Time to drop globalenv() from searches in package code?

[Kurt Hornik]

> luke-tierney  writes:

> On Thu, 15 Sep 2022, Duncan Murdoch wrote:
>> The author of this Stackoverflow question 
>> https://stackoverflow.com/q/73722496/2554330 got confused because a typo in 
>> his code didn't trigger an error in normal circumstances, but it did when he 
>> ran his code in pkgdown.
>> 
>> The typo was to use "x" in a test, when the local variable was named ".x". 
>> There was no "x" defined locally or in the package or its imports, so the 
>> search got all the way to the global environment and found one.  (The very 
>> confusing part for this user was that it found the right variable.)
>> 
>> This author had suppressed the "R CMD check" check for use of global 
>> variables.  Obviously he shouldn't have done that, but he's working with 
>> tidyverse NSE, and that causes so many false positives that it is somewhat 
>> understandable he would suppress one too many.
>> 
>> The pkgdown simulation of code in examples doesn't do perfect mimicry of 
>> running it at top level; the fake global environment never makes it onto the 
>> search list.  Some might call this a bug, but I'd call it the right search 
>> strategy.
>> 
>> My suggestion is that the search for variables in package code should never 
>> get to globalenv().  The chain of environments should stop after handling 
>> the 
>> imports.  (Probably base package functions should also be implicitly 
>> imported, but nothing else.)
>> 

> This was considered and discussed when I added namespaces. Basically
> it would mean making the parent of the base namespace environment be
> the empty environment instead of the global environment. As a design
> this is cleaner, and it would be a one-line change in eval.c.  But
> there were technical reasons this was not a viable option at the time,
> also a few political reasons. The technical reasons mostly had to do
> with S3 dispatch.

> Changes over the years, mostly from work Kurt has done, to S3 dispatch
> for methods defined and registered in packages might make this more
> viable in principle, but there would still be a lot of existing code
> that would stop working. For example, 'make check' with the one-line
> change fails in a base example that defines an S3 method. It might be
> possible to fiddle with the dispatch to keep most of that code
> working, but I suspect that would be a lot of work. Seeing what it
> would take to get 'make check' to succeed would be a first step if
> anyone wants to take a crack at it.

Luke,

Can you please share the one-line change so that I can take a closer
look?

Best
-k

>> I suspect this change would reveal errors in lots of packages, but the 
>> number 
>> of legitimate uses of the current search strategy has got to be pretty small 
>> nowadays, since we've been getting warnings for years about implicit imports 
>> from other standard packages.

> Your definition of 'legitimate' is probably quite similar to mine, but
> there is likely to be a small but vocal minority with very different
> views :-).

> Best,

> luke

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

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

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

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

Re: [Rd] Respecting custom repositories files in interactive/batch R sessions

[Kurt Hornik]

> Gabriel Becker writes:

Friends,

I always keep forgetting how these things currently/precisely work, but
I guess the principle is that utils:::.onLoad() does

  options(repos = c(CRAN = "@CRAN@"))

unless the repos option was already set (in the user or site profiles).
As the latter are not used when checking, the check code in tools takes
advantage of the repositories file mechanism, see ? setRepositories:

 The default list of known repositories is stored in the file
 ‘R_HOME/etc/repositories’.  That file can be edited for a site, or
 a user can have a personal copy in the file pointed to by the
 environment variable ‘R_REPOSITORIES’, or if this is unset or does
 not exist, in ‘HOME/.R/repositories’, which will take precedence.

which also points to Startup etc).

I guess one could teach utils:::.onLoad() to use the user/site
repositories setting instead of the hard-wired CRAN = @CRAN@?  Afaict,
that would make no difference if the repositories file was not
configured, and provide the configured setting in case repos was not set
in the user/site profile ...

Best
-k


> Hi Dirk,
> So there's a couple of things going on. First off you're correct that that
> works generally. There are a couple of reasons that made it not. The first
> is a bug/design error in Rstudio which is causing the R_PROFILE to not be
> adhered to when you build there. I will be filing a bug regarding that with
> them, as I know that is irrelevant to this list.  There was some indication
> that even raw R CMD check running via an R studio server installation was
> missing the profile, but that ended up being spurious upon deeper testing.

> That said, I do think that there is a case to be made for the ability to
> modify what repositories R knows about at a more fundamental level than
> setting options in a site profile, and that is, ostensibly, what the
> repositories file machinery does. I understand it was intended initially
> and is currently only (?) used for the windows repository gui menu and
> related setRepositories function, but I still think there is some value in
> extending it in the ways I described.

> One major difference is that in this case, even when run with --vanilla,
> administrators would still be in control of which repositories users hit
> (by default only, of course, but there is still value in that).

> Best,
> ~G

> On Thu, Sep 15, 2022 at 11:31 AM Dirk Eddelbuettel  wrote:

>> 
>> I may be missing something here but aren't you overcomplicating things?
>> One
>> can avoid the repetitive dialog by setting   options(repos)   accordingly,
>> and I have long done so.  The Debian (and hence Ubuntu and other
>> derivatives)
>> package does so via the Rprofile.site I ship.  See e.g. here
>> 
>> https://sources.debian.org/src/r-base/4.2.1-2/debian/Rprofile.site/
>> 
>> I have used the same mechanism to point to intra-company repositories,
>> easily
>> a decade or so ago. I had no problems with R CMD check of in-house packages
>> using this.
>> 
>> Dirk
>> 
>> --
>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>> 

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] documentation of asplit

[Kurt Hornik]

> SOEIRO Thomas writes:

> Dear list,

> The documentation of `asplit` currently says (section Details): "apply
> *always* simplifies common length results, so attempting to split via
> apply(x, MARGIN, identity) does not work (as it simply gives x)."

> This may be updated (e.g., by simply removing "always") since `apply`
> recently gained a `simplify` argument.

Thanks.  Finally updated now.

Best
-k

> Best,

> Thomas

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

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

Re: [Rd] LOGNAME env var in the check code

[Kurt Hornik]

> Gábor Csárdi writes:

Thanks.  c81206 changes to use 

  user <- Sys.info()[["effective_user"]]

which afawct should always give the same  as the uname for files created
by the current user.  Pls check: if not, we can go for something like

foo <- function() {
writeLines("ABC", tf <- tempfile())
on.exit(unlink(tf))
file.info(tf)$uname
}

Best
-k


> While trying to reproduce a NOTE for
> * checking for new files in some other directories ... NOTE

> I noticed that the check code uses

> Sys.getenv("LOGNAME")

> to query the name of the current user. However on many systems this is
> not set, so this is the empty string, and then no NOTE is shown. (Only
> files owned by the current user generate a NOTE.)

> An alternative would be to call `id -un` to query the username, or
> create a file and then use `file.info()` to query its owner. Using one
> of these alternatives would make this check more reproducible.

> Thanks,
> Gabor

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

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

Re: [Rd] LOGNAME env var in the check code

[Kurt Hornik]

> Gábor Csárdi writes:

> While trying to reproduce a NOTE for
> * checking for new files in some other directories ... NOTE

> I noticed that the check code uses

> Sys.getenv("LOGNAME")

> to query the name of the current user. However on many systems this is
> not set, so this is the empty string, and then no NOTE is shown. (Only
> files owned by the current user generate a NOTE.)

> An alternative would be to call `id -un` to query the username, or
> create a file and then use `file.info()` to query its owner. Using one
> of these alternatives would make this check more reproducible.

Thanks, will try to get this improved (I like the "or" idea) ...

Best
-k

> Thanks,
> Gabor

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

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

Re: [Rd] Should Position() use match.fun()?

[Kurt Hornik]

>>>>> Kurt Hornik writes:

>>>>> Steve Martin writes:
>> Hello,
>> All of the funprog functions except Position() use match.fun() early
>> in the body of the function. (Filter() seems to rely on lapply() for
>> this, but the effect is the same.) 

> Right. 

>> In most cases this isn't a problem, but I can't see why Position()
>> shouldn't look something like

>> Position2 <- function(f, x, right = FALSE, nomatch = NA_integer_) {
>> f <- match.fun(f) # the only difference from Position()
>> ind <- if (right) rev(seq_along(x)) else seq_along(x)
>> for (i in ind) {
>> if (f(x[[i]])) return(i)
>> }
>> nomatch
>> }

>> This would make it consistent with the other funprog functions, and
>> would mean that Find() and Position() give the same result when
>> expected

> Indeed.  I'll look into adding the match.fun ...

Changed now with c80873.

Best
-k

> Best
> -k

>>> equals3 <- function(x) x == 3
>>> Position("equals3", 1:5)
>> Error in f(x[[i]]) : could not find function "f"
>>> Position2("equals3", 1:5)
>> [1] 3
>>> Find("equals3", 1:5)
>> [1] 3

>> Thanks,
>> Steve

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

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

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

Re: [Rd] Should Position() use match.fun()?

[Kurt Hornik]

> Steve Martin writes:

> Hello,
> All of the funprog functions except Position() use match.fun() early
> in the body of the function. (Filter() seems to rely on lapply() for
> this, but the effect is the same.) 

Right. 

> In most cases this isn't a problem, but I can't see why Position()
> shouldn't look something like

> Position2 <- function(f, x, right = FALSE, nomatch = NA_integer_) {
> f <- match.fun(f) # the only difference from Position()
> ind <- if (right) rev(seq_along(x)) else seq_along(x)
> for (i in ind) {
> if (f(x[[i]])) return(i)
> }
> nomatch
> }

> This would make it consistent with the other funprog functions, and
> would mean that Find() and Position() give the same result when
> expected

Indeed.  I'll look into adding the match.fun ...

Best
-k

>> equals3 <- function(x) x == 3
>> Position("equals3", 1:5)
> Error in f(x[[i]]) : could not find function "f"
>> Position2("equals3", 1:5)
> [1] 3
>> Find("equals3", 1:5)
> [1] 3

> Thanks,
> Steve

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

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

Re: [Rd] Should seq.Date() return double storage?

[Kurt Hornik]

> Michael Chirico via R-devel writes:

> today <- Sys.Date()
> typeof(today)
> # [1] "double"
> typeof(seq(today, by=1, length.out=2))
> # [1] "integer"

> Clearly minor as it doesn't seem to have come up before (e.g. coercion
> to numeric will happen automatically whenever fractional dates are
> needed); I only noticed because of a test using identical failing:

> identical(
>   seq(today, by=1, length.out=10),
>   today + 0:9
> )
> # [1] FALSE

> It's easy in this case to fix the test using coercion, but this could
> (and did in practice) come up at deeper levels of nesting that become
> more onerous to handle. And using all.equal() comes with its own
> tradeoffs.

> The fix would be easy enough -- at a glance there are two usages of
> .Date(seq.int(...)) in seq.Date() that could be replaced by
> .Date(as.numeric(seq.int(...))).

Thanks.  Can you pls provide a patch for these?

Best
-k

> Mike C

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

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

Re: [Rd] Possible bug in help file name generation

[Kurt Hornik]

> Deepayan Sarkar writes:

> On Thu, Jun 24, 2021 at 5:31 PM Iñaki Ucar  wrote:
>> 
>> Hi,
>> 
>> I noticed that R 4.1 places html files into the packages' help
>> directory, compared to previous versions, which used an RDS. I found a
>> possible bug in the code that processes the aliases from the Rd files
>> and generates the names for these html files (I haven't identified
>> where this happens though).
>> 
>> To reproduce this, install e.g. the 'caper' package from CRAN and
>> inspect the help directory. I find the following file:
>> 
>> 'pgls.confint'$'\n''.html'
>> 
>> which contains a special character. This comes from the fact that the
>> file caper/man/pgls.profile.Rd in caper's source code contains a
>> newline in the corresponding alias:
>> 
>> \name{pgls.profile}
>> \alias{pgls.profile}
>> \alias{plot.pgls.profile}
>> \alias{pgls.confint
>> }
>> 
>> and this ends up in the file name.

> Yes, the code should probably do a trimws() somewhere, but this also
> looks like something that maybe R CMD check should identify and
> complain about.

I'll take a look ...

-k

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

Re: [Rd] help(".libPaths"): Paragraph lacks mentioning of R_LIBS_SITE

[Kurt Hornik]

> Henrik Bengtsson writes:

Thanks: Tomas and I have now improved this.

Best
-k

> In ?base::.libPaths, there's a paragraph saying:
> The library search path is initialized at startup from the environment
> variable R_LIBS (which should be a colon-separated list of directories
> at which R library trees are rooted) followed by those in environment
> variable R_LIBS_USER. Only directories which exist at the time will be
> included.

> Shouldn't R_LIBS_SITE also be mentioned in that passage?  Something like:

> ...followed by those in environment variables R_LIBS_USER and R_LIBS_SITE. ...

> /Henrik

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

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

Re: [Rd] Silent failure with NA results in fligner.test()

[Kurt Hornik]

> Karolis K writes:

> To me it seems like returning chi-sq = 0 and p-value = 1 would make sense.
> It would also be consistent with other scenarios of equal variance in all
> groups. One example:

> fligner.test(1:8, gl(2,4))
> #Fligner-Killeen test of homogeneity of variances
> #
> # data:  1:8 and gl(2, 4)
> # Fligner-Killeen:med chi-squared = 0, df = 1, p-value = 1

> But I am aware that other tests implemented in stats:: sometimes throw
> errors in similar situations.

> Maybe someone more familiar with the behaviour and philosophy behind
> stats:: preferences can add more weight here?

Thanks for spotting this.  After some internal discussions, we've come
to the conclusion that there is no "obvious" way to handle situations
where the Fligner-Killeen:med chi-squared test statistic is undefined
(i.e., when the denominator is zero).  [Owing to the discreteness of the
ranks, trying to take limits will not work.]  For now, these
sitatuations consistently give NaN/NA instead of errors (and the numeric
computations were improved so that it should no longer possible to get a
zero denominator and a non-zero numerator).

Best
-k

> Warm regards,
> Karolis K.

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] WRE still hints at the "styles" field in R_FortranMethodDef

[Kurt Hornik]

> Ivan Krylov writes:

Thanks: fixed now in the trunk with c79735.

Best
-k

> The field has been removed in R 3.4.0 after being deprecated in R
> 3.3.3. Indeed, the paragraph describing it has been commented out
> (lines 10144-10151 in R-exts.texi), but another paragraph above (lines
> 10101-10110) still mentions the field as if it exists. I would like to
> suggest some rewording along the lines of the attached patch in order
> to avoid confusing readers like me.

> -- 
> Best regards,
> Ivan
> x[DELETED ATTACHMENT WREstyles.patch, text/x-patch]
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Silent failure with NA results in fligner.test()

[Kurt Hornik]

> Karolis K writes:

Any preferences?

Best
-k

> Hello,
> In certain cases fligner.test() returns NaN statistic and NA p-value.
> The issue happens when, after centering with the median, all absolute values 
> become constant, which ten leads to identical ranks.

> Below are a few examples:

> # 2 groups, 2 values each
> # issue is caused by residual values after centering (-0.5, 0.5, -0.5, 0.5)
> # then, after taking the absolute value, all the ranks become identical.
>> fligner.test(c(2,3,4,5), gl(2,2))

> Fligner-Killeen test of homogeneity of variances

> data:  c(2, 3, 4, 5) and gl(2, 2)
> Fligner-Killeen:med chi-squared = NaN, df = 1, p-value = NA


> # similar situation with more observations and 3 groups
>> fligner.test(c(2,3,2,3,4,4,5,5,8,9,9,8), gl(3,4))

> Fligner-Killeen test of homogeneity of variances

> data:  c(2, 3, 2, 3, 4, 4, 5, 5, 8, 9, 9, 8) and gl(3, 4)
> Fligner-Killeen:med chi-squared = NaN, df = 2, p-value = NA


> Two simple patches are proposed below. One returns an error, and another 
> returns a p-value of 1.
> Not sure which one is more appropriate, so submitting both.

> Warm regards,
> Karolis Koncevičius

> ---

> Index: fligner.test.R
> ===
> --- fligner.test.R(revision 79650)
> +++ fligner.test.R(working copy)
> @@ -59,8 +59,13 @@
>  stop("data are essentially constant")
 
>  a <- qnorm((1 + rank(abs(x)) / (n + 1)) / 2)
> -STATISTIC <- sum(tapply(a, g, "sum")^2 / tapply(a, g, "length"))
> -STATISTIC <- (STATISTIC - n * mean(a)^2) / var(a)
> +if (var(a) > 0) {
> +STATISTIC <- sum(tapply(a, g, "sum")^2 / tapply(a, g, "length"))
> +STATISTIC <- (STATISTIC - n * mean(a)^2) / var(a)
> +}
> +else {
> +STATISTIC <- 0
> +}
>  PARAMETER <- k - 1
>  PVAL <- pchisq(STATISTIC, PARAMETER, lower.tail = FALSE)
>  names(STATISTIC) <- "Fligner-Killeen:med chi-squared”

> ---

> Index: fligner.test.R
> ===
> --- fligner.test.R(revision 79650)
> +++ fligner.test.R(working copy)
> @@ -57,6 +57,8 @@
>  x <- x - tapply(x,g,median)[g]
>  if (all(x == 0))
>  stop("data are essentially constant")
> +if (var(abs(x)) == 0)
> +stop("absolute residuals from the median are essentially constant")
 
>  a <- qnorm((1 + rank(abs(x)) / (n + 1)) / 2)
>  STATISTIC <- sum(tapply(a, g, "sum")^2 / tapply(a, g, "length"))

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

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

Re: [Rd] order() and sort() on single row data.frames

[Kurt Hornik]

> Benjamin Becker writes:

> Hi,
> not sure whether this belongs here or has been reported/asked before.

> In the current R devel the behavior of order() and sort() on data.frames 
> with a single row has changed.

> Before (release):

>> sort(data.frame("b", "a"))
>    X.a. X.b.
> 1    a    b

> Now (devel):

>> sort(data.frame("b", "a"))
>    X.b.
> 1    b

> I did not find any specific documentation in the daily news log on
> this.

Work in progress.  Likely this will become an error: ? sort clearly says
it does not work on data frames.

Best
-k

> Thanks,
> Benjamin

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

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

Re: [Rd] Named class vector

[Kurt Hornik]

> Duncan Murdoch writes:

> The source to the noquote() function looks like this:
> noquote <- function(obj, right = FALSE) {
>  ## constructor for a useful "minor" class
>  if(!inherits(obj,"noquote"))
>  class(obj) <- c(attr(obj, "class"),
>  if(right) c(right = "noquote") else "noquote")
>  obj
> }

> Notice what happens with right = TRUE:

>> x <- noquote("a", right = TRUE)
>> x
> [1] a
>> class(x)
>  right
> "noquote"

> The class vector for x is named.  The print method pays attention to the 
> name, so we get different behaviour for a class of "noquote" and a class 
> of c(right = "noquote").

> I had never noticed a named class vector before, and it raised some 
> questions for me:

> - Is this used anywhere else?

Not that I'd be aware of: I think MMae is the expert here.

> - Are names preserved in all the operations normally done on a class 
> vector?  (As far as I can see they are, but maybe I've missed something.)
> - Is it a good idea to encode a string value worth of information in the 
> name, rather than setting the class to something like c("noquote", 
> "right") instead?

My preference would be to have unnamed class vectors, so that the names
could perhaps eventually be used to store the name of the package which
owns the class.  For noquote, I guess you'd want something like

  c("noquote_right", "noquote")

Best
-k

> Comments would be welcome.

> Duncan Murdoch

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

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

Re: [Rd] Error in ?lowess

[Kurt Hornik]

> Duncan Murdoch writes:

Thanks, fixed now.

Best
-k

> The lowess() help page refers to documentation in "src/appl/lowess.doc". 
>   This was moved to "src/library/stats/src/lowess.doc" in 2007.  This 
> patch fixes it:

> Index: src/library/stats/man/lowess.Rd
> ===
> --- src/library/stats/man/lowess.Rd   (revision 79137)
> +++ src/library/stats/man/lowess.Rd   (working copy)
> @@ -30,7 +30,7 @@
>   \details{
> \code{lowess} is defined by a complex algorithm, the Ratfor original
> of which (by W. S. Cleveland) can be found in the \R sources as file
> -  \file{src/appl/lowess.doc}.  Normally a local linear polynomial fit is
> +  \file{src/library/stats/src/lowess.doc}.  Normally a local linear 
> polynomial fit is
> used, but under some circumstances (see the file) a local constant fit
> can be used.  \sQuote{Local} is defined by the distance to the
> \code{floor(f*n)}th nearest neighbour, and tricubic weighting is used

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

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

Re: [Rd] utils::isS3stdGeneric chokes on primitives and identity

[Kurt Hornik]

> Gabriel Becker writes:

> I added that so I can look at the proposed fix and put it or something
> similar in bugzilla for review final review.

> Apologies for the oversight.

Fixed now with

-while(as.character(bdexpr[[1L]]) == "{")
+while(is.call(bdexpr) && (as.character(bdexpr[[1L]]) == "{"))

(the suggested fix does not work on things like
foo <- function(x) {{ x }} 
...)

Best
-k

> ~G

> On Wed, Aug 19, 2020 at 3:40 PM Antoine Fabri 
> wrote:

>> Dear R-devel,
>> 
>> utils::isS3stdGeneric tries to subset the body of the function it's fed,
>> primitives don't like that because they don't have a body, identity doesn't
>> like it either because it's body is a symbol.
>> 
>> According to the doc, any function is a legal input.
>> 
>> See below:
>> 
>> identity
>> #> function (x)
>> #> x
>> #> 
>> #> 
>> 
>> max
>> #> function (..., na.rm = FALSE)  .Primitive("max")
>> 
>> isS3stdGeneric(identity)
>> #> Error in bdexpr[[1L]]: objet de type 'symbol' non indiçable
>> 
>> isS3stdGeneric(max)
>> #> Error in while (as.character(bdexpr[[1L]]) == "{") bdexpr <-
>> bdexpr[[2L]]: l'argument est de longueur nulle
>> 
>> Here is a simple fix :
>> 
>> isS3stdGeneric <- function(f) {
>> {
>> bdexpr <- body(f)
>> if(is.null(bdexpr) || !is.call(bdexpr)) return(FALSE)
>> while (as.character(bdexpr[[1L]]) == "{") bdexpr <- bdexpr[[2L]]
>> ret <- is.call(bdexpr) && identical(bdexpr[[1L]], as.name
>> ("UseMethod"))
>> if (ret)
>> names(ret) <- bdexpr[[2L]]
>> ret
>> }
>> }
>> 
>> isS3stdGeneric(identity)
>> #> [1] FALSE
>> isS3stdGeneric(max)
>> #> [1] FALSE
>> 
>> Best,
>> 
>> Antoine
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Stale link from ?check to R Internals

[Kurt Hornik]

> Duncan Murdoch writes:

> On 19/08/2020 12:26 p.m., Toby Hocking wrote:
>> Hi the reference to R Internals
>> https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools
>> in ?check (PkgUtils.Rd in utils package) is stale. Here is my proposed
>> patch (use named reference rather than numeric reference to avoid any
>> similar broken links in the future).

> Just to be clear:  you're giving the current URL, the problem is it's 
> called "Chapter 6".

Fixed now.

Best
-k

> Duncan Murdoch

>> 
>> Index: src/library/utils/man/PkgUtils.Rd
>> ===
>> --- src/library/utils/man/PkgUtils.Rd (revision 79049)
>> +++ src/library/utils/man/PkgUtils.Rd (working copy)
>> @@ -40,7 +40,7 @@
>> set by environment variables \env{_R_BUILD_RESAVE_DATA_} and
>> \env{_R_BUILD_COMPACT_VIGNETTES_}: see \sQuote{Writing \R Extensions}.
>> Many of the checks in \command{R CMD check} can be turned off or on by
>> -  environment variables: see Chapter 6 of the \sQuote{R Internals} manual.
>> +  environment variables: see Chapter "Tools" of the \sQuote{R Internals}
>> manual.
>> 
>> By default \command{R CMD build} uses the \code{"internal"} option to
>> \code{\link{tar}} to prepare the tarball.  An external \command{tar}
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 

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

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

Re: [Rd] Typos in file.path documentation.

[Kurt Hornik]

> Rui Barradas writes:

Thanks: both fixed now in the trunk with c79004.

Best
-k

> Hello,
> R 4.0.2 on Ubuntu 20.04, sessionInfo() below.

> I believe there are two typos in ?file.path, section Value, 2nd paragraph.

> 1. There is a close parenthesis missing  after Encoding, as it is 
> reading is a bit confusing, I had to backtrack and repeat.
> 2. I'm not a native language speaker but before a consonant it's 'a', 
> not 'an', right?

> an component

> should be

> a component


> Current:

> An element of the result will be marked (see Encoding as UTF-8 if run in 
> a UTF-8 locale (when marked inputs are converted to UTF-8) or if an 
> component of the result is marked as UTF-8, or as Latin-1 in a 
> non-Latin-1 locale.

> Should be:

> An element of the result will be marked (see Encoding) as UTF-8 if run 
> in a UTF-8 locale (when marked inputs are converted to UTF-8) or if a 
> component of the result is marked as UTF-8, or as Latin-1 in a 
> non-Latin-1 locale.


> sessionInfo()
> R version 4.0.2 (2020-06-22)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 20.04.1 LTS

> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

> locale:
>   [1] LC_CTYPE=pt_PT.UTF-8   LC_NUMERIC=C
>   [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
>   [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
>   [7] LC_PAPER=pt_PT.UTF-8   LC_NAME=C
>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base

> loaded via a namespace (and not attached):
> [1] compiler_4.0.2


> Hope this helps,

> Rui Barradas

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

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

Re: [Rd] Typo in ?base::Bessel

[Kurt Hornik]

> EDUARDO GARCIA PORTUGUES writes:

Thanks, will fix and add a DOI ...

Best
-k

> "So*c*kne, David J. (1973)." -> "Sookne, David J. (1973)."
> "Sookne" is referred previously in the documentation and is the correct
> surname in the publication
> 
> and Netlib's source .

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Compilation error for R 4.0.2

[Kurt Hornik]

> Wim R Cardoen writes:

> Hello,
> I experienced a compiler error when I tried to compile the latest version
> of R i.e. R4.0.2
> making iosupport.d from iosupport.c
> making lapack.d from lapack.c
> making list.d from list.c
> making localecharset.d from localecharset.c
> grep.c(74): catastrophic error: cannot open source file "pcre2.h"
>   # include
> (The pcre2.h header file is actually present!)


> I used the following compiler flags:
> # PCRE2:
> # -
> setenv CC gcc
> setenv CFLAGS " -O2 -fPIC "
> ./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/pcre2/10.35 \
> --enable-pcre2-16 --enable-pcre2-32 --with-pic

> module purge
> module load intel/2019.5.281

> # USe a modern version of curl & pcre2 (The current one on Centos 7 is TOO
> old)
> setenv CURLDIR "/uufs/chpc.utah.edu/sys/installdir/curl/7.65.3"
> setenv PCRE2DIR "/uufs/chpc.utah.edu/sys/installdir/pcre2/10.35"

> setenv PATH ${PCRE2DIR}/bin:$PATH

>  Setting Compiler & linker flags:
> setenv CC icc
> setenv CXX icpc
> setenv F77 ifort
> setenv FC ifort
> setenv CFLAGS   " -axCORE-AVX512,CORE-AVX2,AVX,SSE4.2 -O3 -qopenmp
> -fp-model precise -fPIC -I${MKLROOT}/include -I${CURLDIR}/include
>   -I${PCRE2DIR}/include "

What I guess you should do is

 /path/to/configure CPPFLAGS="-I${PCRE2DIR}/include .."
 make

Hth
-k


> setenv CXXFLAGS " ${CFLAGS} "
> setenv FFLAGS   " ${CFLAGS} "
> setenv FCFLAGS  " ${CFLAGS} "
> setenv LDFLAGS  " -Wl,-rpath=${MKLROOT}/lib/intel64_lin
> -L${MKLROOT}/lib/intel64_lin -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
>   -Wl,-rpath=/uufs/
> chpc.utah.edu/sys/installdir/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin
>-L/uufs/
> chpc.utah.edu/sys/installdir/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin
>-liomp5 -lpthread -ldl -Wl,-rpath=${CURLDIR}/lib
> -L${CURLDIR}/lib -lcurl
>-Wl,-rpath=${PCRE2DIR}/lib -L${PCRE2DIR}/lib
>  -lpcre2-8 -lpcre2-posix "

> ./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/R/4.0.2i
> --enable-R-profiling --enable-R-shlib --enable-memory-profiling
> --enable-java --enable-shared=yes --with-blas="$LDFLAGS" --with-readline
> --with-cairo --with-tcltk --with-libpng --with-jpeglib --with-libtiff
> --with-ICU --with-pic --with-x --with-lapack --with-pcre2

> I also appended the corresponding config.log:

> Thank you,

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

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

Re: [Rd] R-devel internal errors during check produce?

[Kurt Hornik]

>>>>> Jan Gorecki writes:

> Thank you both,
> You are absolutely correct that example should be minimal, so here it is.

> l = list(a=new.env(), b=new.env())
> unique(l)

> Just for completeness, env_list during check that raises error

> env_list <- list(baseenv(),
>   as.environment("package:graphics"),
>   as.environment("package:stats"),
>   as.environment("package:utils"),
>   as.environment("package:methods")
> )
> unique(env_list)

Thanks ... but the above work fine for me.  E.g., 

R> l = list(a=new.env(), b=new.env())
R> unique(l)
[[1]]


[[2]]


Best
-k


> Best regards,
> Jan

> On Mon, Jun 29, 2020 at 5:42 PM Martin Maechler
>  wrote:
>> 
>> >>>>> Kurt Hornik
>> >>>>> on Mon, 29 Jun 2020 16:13:03 +0200 writes:
>> 
>> >>>>> Jan Gorecki writes:
>> >> So the unique.default is from the R tools package during
>> >> checks.  I don't see those issues on CRAN checks.
>> 
>> > I cannot reproduce this locally (and have no clues about
>> > docker).  Perhaps you can try to debug this on your end?
>> > And see what env_list is when the error occurs?
>> 
>> > Best -k
>> 
>> Indeed, if it is a bug in R (as opposed to being an assumption
>> that 'data.table' makes about undocumented R internals), it
>> should be reproducible with a very small dummy package instead
>> of data.table. ... or actually reproducible with relatively
>> simple R code calling unique() not envolving any non base package.
>> 
>> Martin
>> 
>> 
>> >> Exact environment where I am reproducing this issue is a
>> >> fresh ubuntu, no R packages pre-installed docker pull
>> >> registry.gitlab.com/jangorecki/dockerfiles/r-devel
>> >> https://gitlab.com/jangorecki/dockerfiles/-/raw/master/r-devel/Dockerfile
>> 
>> >> On Sat, Jun 27, 2020 at 12:37 AM Jan Gorecki
>> >>  wrote:
>> >>>
>> >>> Hi R developers,
>> >>>
>> >>> On R-devel (2020-06-24 r78746) I am getting those two
>> >>> new exceptions during R check. I found a change which
>> >>> eventually may be related
>> >>> https://github.com/wch/r-source/commit/69de92b9fb1b7f2a7c8d1394b8d56050881a5465
>> >>> I think this may be a regression. I grep'ed package
>> >>> manuals and R code for unique.default but don't see
>> >>> any. Usage section of the unique method looks fine as
>> >>> well. Errors look a little bit like internal errors.
>> >>>
>> >>> * checking Rd \usage sections ... NOTE Error in
>> >>> unique.default(env_list) : LENGTH or similar applied to
>> >>> environment object Calls: 
>> >>> ... .get_S3_generics_as_seen_from_package -> unique ->
>> >>> unique.default Execution halted The \usage entries for
>> >>> S3 methods should use the \method markup and not their
>> >>> full name.  * checking S3 generic/method consistency
>> >>> ... WARNING Error in unique.default(env_list) : LENGTH
>> >>> or similar applied to environment object Calls:
>> >>>  ... .get_S3_generics_as_seen_from_package ->
>> >>> unique -> unique.default
>> >>>
>> >>> I don't think if it is related but I build R-devel with
>> >>> extra args: --with-recommended-packages
>> >>> --enable-strict-barrier --disable-long-double I check
>> >>> with: --as-cran --no-manual To reproduce download
>> >>> current data.table from CRAN (1.12.8) and run R check
>> >>>
>> >>> Best regards, Jan Gorecki
>> 
>> >> __
>> >> R-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] "R CMD Sweave --driver=..." woes

[Kurt Hornik]

> Vincent Goulet via R-devel writes:

Thanks: fixed now in the trunk with c78751.

Best
-k

> In trying to change the driver used by Sweave on the command line using 
>R CMD Sweave --driver=foo

> I consistently get the "directory 'foo' does not exist' error. (For any value 
> of 'foo', even the default 'RweaveLatex'.)

> Looking up the source code for function .Sweave that is called by 'R CMD 
> Sweave', I notice that the argument 'driver', if used, is added to the vector 
> of arguments of ''buildVignette' without being named. It ends up being passed 
> to argument 'dir', hence rhe error.

> I believe the simple patch below should fix the issue, but I wasn't able to 
> test it.

> Hope this helps.

> v.

> Vincent Goulet
> Professeur titulaire
> École d'actuariat, Université Laval


> Index: src/library/utils/R/Sweave.R
> ===
> --- src/library/utils/R/Sweave.R  (revision 78746)
> +++ src/library/utils/R/Sweave.R  (working copy)
> @@ -516,7 +516,7 @@
> do_exit(1L)
> }
> args <- list(file=file, tangle=FALSE, latex=toPDF, engine=engine, 
> clean=clean)
> -if(nzchar(driver)) args <- c(args, driver)
> +if(nzchar(driver)) args <- c(args, driver=driver)
> args <- c(args, encoding = encoding)
> if(nzchar(options)) {
> opts <- eval(str2expression(paste0("list(", options, ")")))

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

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

Re: [Rd] R-devel internal errors during check produce?

[Kurt Hornik]

> Jan Gorecki writes:

> So the unique.default is from the R tools package during checks.
> I don't see those issues on CRAN checks.

I cannot reproduce this locally (and have no clues about docker).
Perhaps you can try to debug this on your end?  And see what env_list is
when the error occurs?

Best
-k


> Exact environment where I am reproducing this issue is a fresh ubuntu,
> no R packages pre-installed
> docker pull registry.gitlab.com/jangorecki/dockerfiles/r-devel
> https://gitlab.com/jangorecki/dockerfiles/-/raw/master/r-devel/Dockerfile

> On Sat, Jun 27, 2020 at 12:37 AM Jan Gorecki  wrote:
>> 
>> Hi R developers,
>> 
>> On R-devel (2020-06-24 r78746) I am getting those two new exceptions
>> during R check. I found a change which eventually may be related
>> https://github.com/wch/r-source/commit/69de92b9fb1b7f2a7c8d1394b8d56050881a5465
>> I think this may be a regression. I grep'ed package manuals and R code
>> for unique.default but don't see any. Usage section of the unique
>> method looks fine as well. Errors look a little bit like internal
>> errors.
>> 
>> * checking Rd \usage sections ... NOTE
>> Error in unique.default(env_list) :
>> LENGTH or similar applied to environment object
>> Calls:  ... .get_S3_generics_as_seen_from_package ->
>> unique -> unique.default
>> Execution halted
>> The \usage entries for S3 methods should use the \method markup and not
>> their full name.
>> * checking S3 generic/method consistency ... WARNING
>> Error in unique.default(env_list) :
>> LENGTH or similar applied to environment object
>> Calls:  ... .get_S3_generics_as_seen_from_package ->
>> unique -> unique.default
>> 
>> I don't think if it is related but I build R-devel with extra args:
>> --with-recommended-packages --enable-strict-barrier --disable-long-double
>> I check with:
>> --as-cran --no-manual
>> To reproduce download current data.table from CRAN (1.12.8) and run R check
>> 
>> Best regards,
>> Jan Gorecki

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

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

Re: [Rd] Possible bug in heatmap()?

[Kurt Hornik]

> Viechtbauer, Wolfgang (SP) writes:

Should be fixed now.

Best
-k

> Dear All,
> There might be a bug in heatmap():

> x <- matrix(rnorm(10*5), 10, 5)
> heatmap(x, labCol=1:5)

> Error in axis(1, 1L:nc, labels = labCol, las = 2, line = -0.5, tick = 0,  : 
>   'at' and 'labels' lengths differ, 5 != 10

> Works fine under 4.0.1. Looking at the code from 4.0.1 vs. Rdevel, esp. this 
> part sticks out:

> labRow <- labRow[rowInd] %||% rownames(x) %||% (1L:nr)[rowInd]
> labCol <- labCol[rowInd] %||% colnames(x) %||% (1L:nc)[colInd]

> Maybe this should be:

> labCol <- labCol[colInd] %||% colnames(x) %||% (1L:nc)[colInd]

>> sessionInfo()
> R Under development (unstable) (2020-06-21 r78727)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 16.04.6 LTS

> Matrix products: default
> BLAS:   /home/wviechtb/rdev/lib/libRblas.so
> LAPACK: /home/wviechtb/rdev/lib/libRlapack.so

> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C   
> LC_TIME=en_US.UTF-8   
>  [4] LC_COLLATE=C   LC_MONETARY=en_US.UTF-8
> LC_MESSAGES=en_US.UTF-8   
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C  LC_ADDRESS=C   
>
> [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 
> LC_IDENTIFICATION=C   

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 

> loaded via a namespace (and not attached):
> [1] compiler_4.1.0

> Best,
> Wolfgang

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

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

Re: [Rd] quantile() type 1 for some ordered factors in R-devel

[Kurt Hornik]

>>>>> Trang Le writes:

> Hi Kurt,
> Thank you for fixing quantile(). However, do you think c.factor() can
> potentially break more functions? For example, with this new change,
> classification from the partykit package using predict() comes back NA because
> of this:

> https://github.com/cran/partykit/blob/597245ef3dfc98411ce919b74c68ba565f077c47/R/party.R#L500

All issues in the CRAN checks were identified and reported, and should
be fixed shortly.

Best
-k

> I understand that most of the fixes will probably be simple with as.numeric()
> or as.integer(), but tracing down these breaks can be time-consuming. What
> about a warning whenever code that would trigger c.factor() is called? This
> way users are given a chance to update packages and code.

> Thanks,
> Trang

> On Wed, May 20, 2020 at 1:53 AM Kurt Hornik  wrote:

>>>>>> Tobias Rockel writes:
   
> Thanks for spotting this, and also to Hadley for reporting to me
> directly.
   
> Fixed now with c78501.
   
> Best
> -k
   
>> Hi,
>> In R-devel (2020-05-17 r78478) quantile() type 1 seems to behave a
> little
>> bit strange for some ordered factors:
>> quantile(factor(1:3, ordered = TRUE), 0.5, type = 1)
>> returns “2” as expected. But
>> quantile(factor(2:4, ordered = TRUE), 0.5, type = 1)
>> returns “4” and
>> quantile(factor(3:5, ordered = TRUE), 0.5, type = 1)
>> returns “NA”. Furthermore, the function returns “NA” for calls like
>> quantile(factor(c("a", "b", "c"), ordered = TRUE), 0.5, type = 1)
   
>> In R 4.0.0 everything seems fine (return values “2”, “3”, “4”, “b”). If
> the
>> vectors are treated as numeric, everything seems to work fine in
> R-devel,
>> too. For example
>> quantile(3:5, 0.5, type = 1)
>> returns “4” in R-devel and R 4.0.0.
   
>> Best regards,
>> Tobias Rockel
   
>>        [[alternative HTML version deleted]]
   
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
   
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] quantile() type 1 for some ordered factors in R-devel

[Kurt Hornik]

> Tobias Rockel writes:

Thanks for spotting this, and also to Hadley for reporting to me
directly.

Fixed now with c78501.

Best
-k

> Hi,
> In R-devel (2020-05-17 r78478) quantile() type 1 seems to behave a little
> bit strange for some ordered factors:
> quantile(factor(1:3, ordered = TRUE), 0.5, type = 1)
> returns “2” as expected. But
> quantile(factor(2:4, ordered = TRUE), 0.5, type = 1)
> returns “4” and
> quantile(factor(3:5, ordered = TRUE), 0.5, type = 1)
> returns “NA”. Furthermore, the function returns “NA” for calls like
> quantile(factor(c("a", "b", "c"), ordered = TRUE), 0.5, type = 1)

> In R 4.0.0 everything seems fine (return values “2”, “3”, “4”, “b”). If the
> vectors are treated as numeric, everything seems to work fine in R-devel,
> too. For example
> quantile(3:5, 0.5, type = 1)
> returns “4” in R-devel and R 4.0.0.

> Best regards,
> Tobias Rockel

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Minor typo in recent commit

[Kurt Hornik]

> Hugh Parsonage writes:

Thanks: fixed now.

Best
-k

> I believe should be February 2020 not 2010
> --- a/doc/manual/R-exts.texi
> +++ b/doc/manual/R-exts.texi
> @@ -2631,9 +2631,9 @@ not necessarily installed) on all known @R{}
> platforms.  As from @R{}
>  4.0.0 a C++ compiler will be selected only if it conforms to the 2011
>  standard (`C++11').  A minor update@footnote{The changes are linked from
>  
> @uref{https://isocpp.org/@/std/@/standing-documents/@/sd-6-sg10-feature-test-recommendations}.}

> -(`C++14') was published in December 2014.  The latest standard (`C++17')
> -was published in December 2017, and a further revision (`C++20') is in
> -preparation.
> +(`C++14') was published in December 2014.  A revision (`C++17') was
> +published in December 2017, and a further revision (`C++20', with many
> +new features) is scheduled for February 2010.

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

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

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

[Kurt Hornik]

> Laurent Gautier writes:

> 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)
> ```

I cannot reproduce this using current R-devel or R-patched.  After
starting with R_DEFAULT_PACKAGES=NULL,

R> search()
[1] ".GlobalEnv"   "Autoloads""package:base"
R> loadedNamespaces()
[1] "compiler" "tools""base"
R> package <- "utils"
R> lib.loc <- file.path(R.home(), "library")
R> ns <- loadNamespace(package, lib.loc)
R> loadedNamespaces()
[1] "compiler" "tools""utils""base"

-k

> 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

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

Re: [Rd] R-intro: Appendix A: attach position

[Kurt Hornik]

> Suharto Anggono Suharto Anggono via R-devel writes:

Thanks: fixed now in the trunk.

Best
-k

> In "An Introduction to R", in "Appendix A  A sample session", in the part on 
> Michelson data, information for
> attach(mm)
> is
> Make the data frame visible at position 3 (the default).

> In fact, the 'attach' is at position 2.

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

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

Re: [Rd] Addition of a meta viewport tag to HTML manuals

[Kurt Hornik]

>>>>> Kurt Hornik writes:

>>>>> Bob Rudis writes:
>> Thanks for both the support & sage advice, Martin!
>> And, aye, tis straightforward to convert the perl one-liner to a
>> shell/sed idiom.

>> A kind soul from the list has also offered to walk me through the
>> "provide a patch" process and I'll do my best to get it right on Par 1
>> :-)

> When building HTML from the Texinfo sources, we already have a sed
> script in place: we can easily teach it to also add the HTML5 viewport
> meta tag as suggested.

> I'll do so after more checking ...

Done now:

r76856 | hornik | 2019-07-22 08:56:41 +0200 (Mon, 22 Jul 2019) | 2 lines
Add HTML5 viewport meta tags to the HTML manuals.
Suggested by Bob Rudis .

Thanks again!

Best
-k


> -k

>> -Bob

>> On Mon, Jul 15, 2019 at 5:54 AM Martin Maechler
>>  wrote:
>>> 
>>> >>>>> Bob Rudis
>>> >>>>> on Tue, 9 Jul 2019 14:24:24 -0400 writes:
>>> 
>>> > The addition of a single line:
>>> > 
>>> 
>>> > at in the  of the R HTML generated manuals would make them much 
>>> > easier to read on mobile devices.
>>> 
>>> > texi2any (which generates the HTML files) is based on long-working Perl 
>>> > code that includes many modern HTML elements but does not include this 
>>> > one.
>>> 
>>> > A Perl one-liner in the install-html: Makefile directive in Makefile.in:
>>> 
>>> > install-html: installdirs
>>> > @for f in $(OBJECTS_HTML); do \
>>> > if test -f $${f} ; then \
>>> > $(INSTALL_DATA) $${f} "$(DESTDIR)$(rdocdir)/manual"; \
>>> > perl -pi -e 's/\>> > content="width=device-width, initial-scale=1.0">\n>> > fi \
>>> > done
>>> 
>>> > would insert this (I still need to read Makefile.win to see where it 
>>> > should go there) and I'd be glad to create a PR unless folks do not think 
>>> > better accessibility on mobile is a good idea.
>>> 
>>> To the contrary.
>>> Thank you very much, Bob, for bringing this up, here!
>>> 
>>> > $(PERL) does not seem to be defined but Perl itself is a requirement for 
>>> > texi2any so it is definitely something that would work in the current 
>>> > installation process.
>>> 
>>> > -Bob
>>> 
>>> Hmm,.. a very long time ago,  perl was an absolute requirement
>>> for building R from the sources, but in the mean time, it's not
>>> been required anymore strictly *).  AFAIK, there are alternative versions
>>> of versions/alternatives to texi2any  (say on Windoze .. or
>>> bizarre Linux distros or non-linux unices), and I'm almost sure
>>> we do not want to require perl explicitly.
>>> 
>>> We are using R itself in many places for installation things,
>>> but here, it should be possible to use smaller unix tools (such
>>> as 'sed' and 'grep' say) instead.
>>> 
>>> If you (or someone else) provided a small patch for using those
>>> instead of perl, I don't see a reason not to be grateful and
>>> apply it to the sources.
>>> 
>>> Thank you once more
>>> Martin
>>> 
>>> 
>>> --
>>> *)  perl is mentioned twice in the "R Administration and
>>> Installation" manual:
>>> 1. maybe needed for 'install-info'  *if* there's no
>>> 'install-info' command on the system [but on my Fedora and
>>> probably most "math-y" Linux dist there is a binary]
>>> 
>>> 2. On Windoze, the texinfo 5.x package needs perl

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

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

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

Re: [Rd] Addition of a meta viewport tag to HTML manuals

[Kurt Hornik]

> Bob Rudis writes:

> Thanks for both the support & sage advice, Martin!
> And, aye, tis straightforward to convert the perl one-liner to a
> shell/sed idiom.

> A kind soul from the list has also offered to walk me through the
> "provide a patch" process and I'll do my best to get it right on Par 1
> :-)

When building HTML from the Texinfo sources, we already have a sed
script in place: we can easily teach it to also add the HTML5 viewport
meta tag as suggested.

I'll do so after more checking ...

-k

> -Bob

> On Mon, Jul 15, 2019 at 5:54 AM Martin Maechler
>  wrote:
>> 
>> > Bob Rudis
>> > on Tue, 9 Jul 2019 14:24:24 -0400 writes:
>> 
>> > The addition of a single line:
>> > 
>> 
>> > at in the  of the R HTML generated manuals would make them much 
>> > easier to read on mobile devices.
>> 
>> > texi2any (which generates the HTML files) is based on long-working Perl 
>> > code that includes many modern HTML elements but does not include this one.
>> 
>> > A Perl one-liner in the install-html: Makefile directive in Makefile.in:
>> 
>> > install-html: installdirs
>> > @for f in $(OBJECTS_HTML); do \
>> > if test -f $${f} ; then \
>> > $(INSTALL_DATA) $${f} "$(DESTDIR)$(rdocdir)/manual"; \
>> > perl -pi -e 's/\> > content="width=device-width, initial-scale=1.0">\n> > fi \
>> > done
>> 
>> > would insert this (I still need to read Makefile.win to see where it 
>> > should go there) and I'd be glad to create a PR unless folks do not think 
>> > better accessibility on mobile is a good idea.
>> 
>> To the contrary.
>> Thank you very much, Bob, for bringing this up, here!
>> 
>> > $(PERL) does not seem to be defined but Perl itself is a requirement for 
>> > texi2any so it is definitely something that would work in the current 
>> > installation process.
>> 
>> > -Bob
>> 
>> Hmm,.. a very long time ago,  perl was an absolute requirement
>> for building R from the sources, but in the mean time, it's not
>> been required anymore strictly *).  AFAIK, there are alternative versions
>> of versions/alternatives to texi2any  (say on Windoze .. or
>> bizarre Linux distros or non-linux unices), and I'm almost sure
>> we do not want to require perl explicitly.
>> 
>> We are using R itself in many places for installation things,
>> but here, it should be possible to use smaller unix tools (such
>> as 'sed' and 'grep' say) instead.
>> 
>> If you (or someone else) provided a small patch for using those
>> instead of perl, I don't see a reason not to be grateful and
>> apply it to the sources.
>> 
>> Thank you once more
>> Martin
>> 
>> 
>> --
>> *)  perl is mentioned twice in the "R Administration and
>> Installation" manual:
>> 1. maybe needed for 'install-info'  *if* there's no
>> 'install-info' command on the system [but on my Fedora and
>> probably most "math-y" Linux dist there is a binary]
>> 
>> 2. On Windoze, the texinfo 5.x package needs perl

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

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

Re: [Rd] trivial typos in man/switch.Rd

[Kurt Hornik]

> Ben Bolker writes:

Thanks: fixed now in the trunk.

Best
-k

>   My colleague points out that these typos are probably still present
> because almost no-one has the stamina to read that far down in ?switch ...

>   cheers
> Ben Bolker
> x[DELETED ATTACHMENT switch_patch.txt, plain text]
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] eliminate a partial argument match warning in R CMD check

[Kurt Hornik]

> Jennifer Bryan writes:

Thanks: fixed with c76763 in the trunk.

Best
-k

> Hello,
> I'm seeing a nuisance warning when I run `R CMD check --as-cran
> whatever_x.y.z.tar.gz`.

> I generally work with these options set:

> options(
>   warnPartialMatchArgs = TRUE,
>   warnPartialMatchAttr = TRUE,
>   warnPartialMatchDollar = TRUE
> )

> And I see this:

> * checking use of SHLIB_OPENMP_*FLAGS in Makefiles ...Warning in dir("src",
> patt = "[.]c$") :
>   partial argument match of 'patt' to 'pattern'
> Warning in dir("src", patt = "[.](cc|cpp)$") :
>   partial argument match of 'patt' to 'pattern'
> Warning in dir("src", patt = "[.]f$") :
>   partial argument match of 'patt' to 'pattern'
> Warning in dir("src", patt = "[.]f9[05]$") :
>   partial argument match of 'patt' to 'pattern'

> It's not a big deal but it would be nice to silence it. Patch below.

> Thanks,
> Jenny

> diff --git a/src/library/tools/R/check.R b/src/library/tools/R/check.R

> index 21d192af485..199029bda73 100644
> --- a/src/library/tools/R/check.R
> +++ b/src/library/tools/R/check.R
> @@ -2933,10 +2933,10 @@ add_dummies <- function(dir, Log)
>  any <- msg <- character()
>  for (m in makefiles) {
>  lines <- readLines(m, warn = FALSE)
> -have_c <- length(dir('src', patt = "[.]c$", recursive
> = TRUE)) > 0L
> -have_cxx <- length(dir('src', patt = "[.](cc|cpp)$",
> recursive = TRUE)) > 0L
> -have_f <- length(dir('src', patt = "[.]f$", recursive
> = TRUE)) > 0L
> -have_f9x <- length(dir('src', patt = "[.]f9[05]$",
> recursive = TRUE)) > 0L
> +have_c <- length(dir('src', pattern = "[.]c$",
> recursive = TRUE)) > 0L
> +have_cxx <- length(dir('src', pattern =
> "[.](cc|cpp)$", recursive = TRUE)) > 0L
> +have_f <- length(dir('src', pattern = "[.]f$",
> recursive = TRUE)) > 0L
> +have_f9x <- length(dir('src', pattern = "[.]f9[05]$",
> recursive = TRUE)) > 0L
>  for (f in c("C", "CXX", "F", "FC", "CPP"))  {
>  this <- paste0(f, "FLAGS")
>  this2 <- paste0("PKG_", this)

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] [R] Open a file which name contains a tilde

[Kurt Hornik]

> Duncan Murdoch writes:

With c76695 in the trunk, we now only tilde expand file names starting
with a tilde also when using readline.

Best
-k

> On 11/06/2019 4:34 p.m., William Dunlap via R-devel wrote:
>> Note that R treats tildes in file names differently on Windows and Linux.
>> On Windows, it is only replaced if it it at the beginning of the line and
>> is followed by a forward or backward slash or end-of-line.  On Linux it is
>> replaced no matter where it is in the text and ~someUser will be replaced
>> by someUser's home directory (if 'someUser' is a user with a home
>> directory).

> That's not quite true:  On Linux the bug is in the code that uses 
> libreadline, which you don't have to use.  If you just specify
> "--no-readline" when you start R, it will be fine on Linux, as far as I 
> can see.

> I wouldn't choose that as the default way to run R (it's pretty 
> irritating not to have readline support), but it is a workaround for 
> this bug.

> Duncan Murdoch

>> 
>> Hence, if you have a Windows machine that can look at the file system on
>> your Linux machine you can use file.rename on Windows to change the names.
>> My inclination would be to use a bash script on Linux to change the names,
>> but if you are not comfortable with bash try the Windows approach.
>> 
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>> 
>> 
>> On Tue, Jun 11, 2019 at 1:13 PM Frank Schwidom  wrote:
>> 
>>> Hi Gabriel,
>>> 
>>> I actually want to make renames over thousands of files. But if I am not
>>> able to express the source filename of the rename operation I will not be
>>> able to get the work done. Besides the fact that there are issues I think
>>> that R is qualified for solving my problem by the method how it can handle
>>> long vectors of strings, booleans and also lists.
>>> 
>>> Kind regards,
>>> Frank
>>> 
>>> On 2019-06-11 09:49:17, Gabriel Becker wrote:
 Hi Frank,
 I'm hesitant to be "that guy", but in case no one else has brought
>>> this up
 to you, having files with a tilde in their names (generally but
>>> especially
 on a linux system, where ~ in file names has a very important special
 meaning in some cases, as we know) strikes me as an exceptionally bad
 practice anyway. In light of that, the solution with the smallest
>>> amount
 of pain for you is almost surely to just... not do that. Your
>>> filenames
 will be better for it anyway.
 There is a reason no one has complained about this before, and while I
 haven't run a study or anything, I strongly suspect its that
>>> "everyone"
 else is already on the "no tildes in filenames" bandwagon, so this
 behavior, even if technically a bug, has no ability to cause them
 problems.
 Best,
 ~G
 On Tue, Jun 11, 2019 at 8:25 AM Frank Schwidom <[1]schwi...@gmx.net>
 wrote:
 
 Hi,
 
 yes, I have seen this package and it has the same tilde expanding
 problem.
 
 Please excuse me I will cc this answer to r-help and r-devel to
>>> keep the
 discussion running.
 
 Kind regards,
 Frank Schwidom
 
 On 2019-06-11 09:12:36, Gábor Csárdi wrote:
 > Just in case, have you seen the fs package?
 > [2]https://fs.r-lib.org/
 >
 > Gabor
 >
 > On Tue, Jun 11, 2019 at 7:51 AM Frank Schwidom <[3]
>>> schwi...@gmx.net>
 wrote:
 > >
 > > Hi,
 > >
 > > to get rid of any possible filename modification I started a
>>> little
 project to cover my usecase:
 > >
 > > [4]https://github.com/schwidom/simplefs
 > >
 > > This is my first R package, suggestions and a review are
>>> welcome.
 > >
 > > Thanks in advance
 > > Frank Schwidom
 > >
 > > On 2019-06-07 09:04:06, Richard O'Keefe wrote:
 > > >How can expanding tildes anywhere but the beginning of a
>>> file
 name NOT be
 > > >considered a bug?
 > > >On Thu, 6 Jun 2019 at 23:04, Ivan Krylov
 <[1][5]krylov.r...@gmail.com> wrote:
 > > >
 > > >  On Wed, 5 Jun 2019 18:07:15 +0200
 > > >  Frank Schwidom <[2][6]schwi...@gmx.net> wrote:
 > > >
 > > >  > +> path.expand("a ~ b")
 > > >  > [1] "a /home/user b"
 > > >
 > > >  > How can I switch off any file crippling activity?
 > > >
 > > >  It doesn't seem to be possible if readline is enabled and
 works
 > > >  correctly.
 > > >
 > > >  Calls to path.expand [1] end up [2] in R_ExpandFileName
>>> [3],
 which
 > > >  calls R_ExpandFileName_readline [4], which uses
>>> libreadline
 function
 > > >  tilde_expand [5]. tilde_expand seems to be designed to
>>> expand
 '~'
 > > >  anywhere in the string it is handed, i.e. operate on
>>> whole
 command
 > > >  lines, not file paths.
 > > >
 > > >  I am taking the liberty of Cc-ing R-devel in case this
>>> can be
 > > >  considered a bug.
 > > >

Re: [Rd] Wrong IEEE reference in documentation for the Round function

[Kurt Hornik]

> Kyle Hamilton writes:

Thanks: I'll fix that.

Best
-k

> Hello,
> Since I can't open an account on Bugzilla and the website told me to
> submit my bug report to the mailing list here's a patch addressing a
> minor typo in the documentation for the Round function. The reference
> section states that the correct IEEE standard is 745:2008 but
> everywhere else in the documentation it's IEEE 754:2008. I've attached
> the patch correcting this typo. If someone creates an account for me
> on Bugzilla I'll submit the patch and other though that system.

> Kyle Hamilton
> kylehamilton.com
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Spurious warning from checkReplaceFuns about a non-replacement function

[Kurt Hornik]

> Hugh Parsonage writes:

> If a function contains the pattern `<-` it is (with a few exceptions)
> deemed to be a replacement function and in particular must have second
> argument `value` to pass R CMD check.

> Consider the function %<->% or any other function containing <- within
> grapes. I claim that such functions should not be considered
> replacement functions and thus the R CMD check should not require its
> second argument to be `value`.

I just committed c76224 which drops %xxx% binops from the list of
(probable) replacement functions.

Thanks for spotting this!

Best
-k

> Recommend in the function tools::checkReplaceFuns

> grep("<-", objects_in_code,
> value = TRUE)

> be changed to

> grep("<-$", objects_in_code,
> value = TRUE)


> Hugh.

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

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

Re: [Rd] Patch idea: an environment variable for setting the user ID

[Kurt Hornik]

> Will L writes:

> To R-devel,
> In `R CMD build`, the ID of the user is automatically inserted into the
> DESCRIPTION file, e.g.

> Packaged: 2018-11-06 14:01:50 UTC; 


> This is problematic for those of us who work in corporate settings. We must
> not divulge our user IDs in the packages we develop and release.

> Jim Hester pointed out that these two lines in
> `add_build_stamp_to_description_file()`
> 
> are responsible. Could we consider his suggestion of using an optional
> environment variable to overwrite the default behavior?

> user <- Sys.getenv("R_BUILD_USERNAME")
> if (!nzchar(user)) user <- Sys.info()["user"]
> if(user == "unknown") user <- Sys.getenv("LOGNAME")

Yep, something along these lines should be possible.
R_BUILD_USER or R_BUILD_LOGNAME may seem more natural though ...

Best
-k



> Will Landau
> -- 
> wlandau.github.io
> linkedin.com/in/wlandau
> github.com/wlandau

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] trivial typo in src/library/stats/man/ts.Rd

[Kurt Hornik]

> Ben Bolker writes:

Thanks, fixed in the trunk now.

Best
-k

>  "vector[s]" should be plural in line 54 ...
>   cheers
>Ben Bolker

> 

> Index: ts.Rd
> ===
> --- ts.Rd (revision 75540)
> +++ ts.Rd (working copy)
> @@ -54,7 +54,7 @@
>  }
>  \details{
>The function \code{ts} is used to create time-series objects.  These
> -  are vector or matrices with class of \code{"ts"} (and additional
> +  are vectors or matrices with class of \code{"ts"} (and additional
>attributes) which represent data which has been sampled at equispaced
>points in time.  In the matrix case, each column of the matrix
>\code{data} is assumed to contain a single (univariate) time series.

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

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

Re: [Rd] Suggestion: Make CRAN source URLs immutable

[Kurt Hornik]

> Kurt Wheeler writes:

Try e.g.

https://cran.r-project.org/package=httr=1.3.1
https://cran.r-project.org/package=httr=1.3.0

-k

> Hello, I hope the is the right list to send this suggestion to.
> I was wondering if it might be possible to have CRAN store the most current
> version of a package's source tarball at a location that does not change.
> As an example, the source tarball for `httr` is stored at
> https://cran.r-project.org/src/contrib/httr_1.3.1.tar.gz. However, once the
> next version of `httr` is released, the URL for version 1.3.1 of `httr`
> will change to
> https://cran.r-project.org/src/contrib/Archive/httr_1.3.1.tar.gz.

> The implications of this are that if I want to write a script which
> installs version 1.3.1 of `httr`, I need to do so like this:

> ```
> httr_url <- "https://cran.r-project.org/src/contrib/httr_1.3.1.tar.gz;

> curl_result <- system(paste0("curl --head ", httr_url), intern=TRUE)
> if (grepl("404", curl_result[1])) {
>   httr_url <- "
> https://cran.r-project.org/src/contrib/Archive/httr_1.3.1.tar.gz;
> }

> install.packages(httr_url)
> ```

> I think there are two obvious ways of remedying this issue. The first would
> be to simply archive the most recent version along with all the old
> versions. Then to install a specific version of a package, it would just be:

> ```
> install.packages("
> https://cran.r-project.org/src/contrib/Archive/httr_1.3.1.tar.gz;)
> ```

> even if 1.3.1 is the most recent version of `httr`.


> The other way to remedy this issue would be to simply not use the
> `/Archive/` sub-directory. So if I wanted to install an old version of
> `httr` it would be:

> ```
> install.packages("https://cran.r-project.org/src/contrib/httr_1.3.0.tar.gz;)
> ```

> despite the fact that version 1.3.0 is not the most recent version.


> I believe the first way would be a better choice because then any existing
> scripts which reference URLs which include `/Archive/` would still work.
> However I do not have strong opinions on how this should be implemented, I
> would just like a URL which points to a certain version of a package that
> will never change.

> Thank you,

> - Kurt

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] 2 minor typos

[Kurt Hornik]

> Marie-Helene Burle writes:

Thanks, will fix!

Best
-k

> Hello,
> I would like to report 2 very minor typos:


> 1. help file for package:base function:function

> The last sentence of the "Technical details" section reads:

> "This is not normally user-visible, but it indicated when functions are 
> printed."

> Either "is" is missing ("but it is indicated") or "it" should be replaced by 
> "is" ("but is indicated") if the subject is omitted.


> 2. R FAQ, mailing list section 
> (https://cran.r-project.org/doc/FAQ/R-FAQ.html#What-mailing-lists-exist-for-R_003f)

> For the R-package-devel list, the section reads:

> "A list which which provides a forum for learning about the R package 
> development process."

> (Double "which").


> If this was not the proper list or the proper way to report such minor typos, 
> please do let me know so that I will know better in the future.

> Thank you!

> Best,

> -
> Marie-Helene Burle (Marie)

> PhD candidate (Centre for Wildlife Ecology)
> R Data Peer (Research Commons)
> Writing Facilitator (Student Learning Commons)
> Data and Software Carpentry instructor
> RStudio Community sustainer
> Scientific Programming Study Group admin
> -
> Simon Fraser University
> (+1) 778 782-5618
> http://www.sfu.ca/content/sfu/biology/people/profiles/msb2.html
> https://github.com/prosoitos
> https://twitter.com/MHBurle

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

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

Re: [Rd] Segfault when performing match on POSIXlt object

[Kurt Hornik]

> Marco Giuliano writes:

Thanks.  Should be fixed in the trunk with c75224: will close the PR
after more testing.

Best
-k

> Bug report submitted :
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17459
> Thanks!

> On Fri, Aug 31, 2018 at 6:48 PM Martin Maechler 
> wrote:

>> > Marco Giuliano
>> > on Fri, 31 Aug 2018 16:50:56 +0200 writes:
>> 
>> > Hi Martin, should I file a formal bug report somewhere or
>> > you've already done it ?
>> 
>> No, I haven't,
>> and as I may not address this bug further myself (in the near
>> future), it may be best if you file a formal report.
>> 
>> I will create an account for you on R's bugzilla - you will be
>> notified and can update your initial pseudo-random password.
>> 
>> Best,
>> Martin
>> 
>> 

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] Argument 'dim' misspelled in error message

[Kurt Hornik]

> Hervé Pagès writes:

Thanks: fixed in the trunk with c75223.

Best
-k

> Hi,
> The following error message misspells the name of
> the 'dim' argument:

>> array(integer(0), dim=integer(0))
>Error in array(integer(0), dim = integer(0)) :
>  'dims' cannot be of length 0

> The name of the argument is 'dim' not 'dims':

>> args(array)
>function (data = NA, dim = length(data), dimnames = NULL)
>NULL

> Cheers,
> H.

> -- 
> Hervé Pagès

> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024

> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319

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

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

Re: [Rd] premature use of startsWith in r75110

[Kurt Hornik]

> Hugh Parsonage writes:

Thanks, will fix.

Best
-k

> In r75110 at line 1846 in src/library/tools/R/check.R the following
> line was changed

> - if(length(grep("^Found the defunct/removed function", out8)))
> + if(any(startsWith(out8, "Found the defunct/removed function")))

> However, if `out8` is NULL at this point (which is plausible), the
> original returns FALSE, but the second returns an error. Recommend

> + if(!is.null(out8) && any(startsWith(out8, "Found the defunct/removed
> function")))




> Best,

> HP

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

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

Re: [Rd] MARGIN in base::unique.matrix() and base::unique.array()

[Kurt Hornik]

> Hervé Pagès writes:

Thanks for spotting this.

With c74978 I just committed, we now get

R> unique(matrix(1:10, ncol=2), MARGIN=1:3)
Error in unique.matrix(matrix(1:10, ncol = 2), MARGIN = 1:3) : 
  MARGIN = 1,2,3 is invalid for dim = 5,2
Calls: unique -> unique.matrix
R> unique(matrix(1:10, ncol=2), MARGIN=3)
Error in unique.matrix(matrix(1:10, ncol = 2), MARGIN = 3) : 
  MARGIN = 3 is invalid for dim = 5,2
Calls: unique -> unique.matrix

Best
-k

> Hi,
> The man page for base::unique.matrix() and base::unique.array() says
> that MARGIN is expected to be a single integer. OTOH the code in charge
> of checking the user supplied MARGIN is:

>  if (length(MARGIN) > ndim || any(MARGIN > ndim))
>  stop(gettextf("MARGIN = %d is invalid for dim = %d",
>  MARGIN, dx), domain = NA)

> which doesn't really make sense.

> As a consequence the user gets an obscure error message when specifying
> a MARGIN that satisfies the above check but is in fact invalid:

>> unique(matrix(1:10, ncol=2), MARGIN=1:2)
>Error in args[[MARGIN]] <- !duplicated.default(temp, fromLast = 
> fromLast,  :
>  object of type 'symbol' is not subsettable

> Also the code used by the above check to generate the error message
> is broken:

>> unique(matrix(1:10, ncol=2), MARGIN=1:3)
>Error in sprintf(gettext(fmt, domain = domain), ...) :
>  arguments cannot be recycled to the same length

>> unique(matrix(1:10, ncol=2), MARGIN=3)
>Error in unique.matrix(matrix(1:10, ncol = 2), MARGIN = 3) :
>  c("MARGIN = 3 is invalid for dim = 5", "MARGIN = 3 is invalid for 
> dim = 2")

> Thanks,
> H.

> -- 
> Hervé Pagès

> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024

> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319

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

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

Re: [Rd] Bug 16719: kruskal.test documentation for formula

[Kurt Hornik]

> Thomas Levine writes:

Thanks: this is now fixed in the trunk with c74945.

Best
-k

> I submit a couple options for addressing bug 16719: kruskal.test
> documentation for formula.
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16719

> disallow-character.diff changes the documentation and error message
> to indicate that factors are accepted.

> allow-character.diff changes the kruskal.test functions to convert
> character vectors to factors; documentation is updated accordingly.

> I tested the updated functions with the examples in example.R. It is
> based on the examples in the bug report.

> If there is interest in applying either patch, especially the latter,
> I want first to test the change on lots of existing programs that call
> kruskal.test, to see if it causes any regressions. Is there a good place
> to look for programs that use particular R functions?

> I am having trouble building R, so I have so far tested these changes
> only by patching revision 74631 (SVN head) and sourcing the resulting
> kruskal.test.R in R 3.4.1 on OpenBSD 6.2. I thus have not tested the
> R documentation files.
> x[DELETED ATTACHMENT disallow-character.diff, plain text]
> x[DELETED ATTACHMENT allow-character.diff, plain text]
> x[DELETED ATTACHMENT example.R, plain text]
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] agrep bug

[Kurt Hornik]

> Kolter, Andreas writes:

> Sorry, I don't understand how to file a bug properly. Nontheless I
> want to report this one because it is still in the code after so many
> years.

Thanks.  This is now fixed in the trunk with c74916.

Best
-k

> This bug still exists:

> https://stackoverflow.com/questions/15871702/difficulties-with-agrep-fixed-f

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] access an element with empty name

[Kurt Hornik]

> Serguei Sokol writes:

> Hi,
> I came across a case where I cannot access a list element by its empty name.
> Minimal example can be constructed as

>      x=list("A", 1)
>      names(x)=c("a", "")
>      x[["a"]]
>      #[1]  "A"
>      x[[""]]
>      #NULL
>      x$`a`
>      #[1]  "A"
>      x$``
>      # Error: attempt to use zero-length variable name
>      # but we can still access the second element by its index
>      x[[2]]
>      #[1] 1

> To my mind, it should be perfectly legal to access an element by an 
> empty name as we can have for example
>      match("", names(x))
>      #[1] 2
> Hence a traditional question: is it a bug or feature?

A feature according to the docs: ? Extract says

Neither empty (‘""’) nor ‘NA’ indices match any names, not even
empty nor missing names. 

-k



> Best,
> Serguei.


>> sessionInfo()
> R version 3.5.0 (2018-04-23)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Mageia 6

> Matrix products: default
> BLAS/LAPACK: /home/opt/OpenBLAS/lib/libopenblas_sandybridge-r0.3.0.dev.so

> locale:
> [1] C

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods base

> loaded via a namespace (and not attached):
> [1] compiler_3.5.0

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

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

Re: [Rd] Numerical stability in chisq.test

[Kurt Hornik]

> Jan Motl writes:

> The chisq.test on line 57 contains following code:
>   STATISTIC <- sum(sort((x - E)^2/E, decreasing = TRUE))

The preceding 2 lines seem relevant:

## Sorting before summing may look strange, but seems to be
## a sensible way to deal with rounding issues (PR#3486):
STATISTIC <- sum(sort((x - E) ^ 2 / E, decreasing = TRUE))

-k

> However, based on book "Accuracy and stability of numerical algorithms" 
> available from:
>   
> http://ftp.demec.ufpr.br/CFD/bibliografia/Higham_2002_Accuracy%20and%20Stability%20of%20Numerical%20Algorithms.pdf
> Table 4.1 on page 89, it is better to sort the data in increasing order than 
> in decreasing order, when the data are non-negative.

> An example:
>   x = matrix(c(rep(1.1, 1)), 10^16, nrow = 10001, ncol = 1)# We 
> have a vector with 1*1.1 and 1*10^16
>   c(sum(sort(x, decreasing = TRUE)), sum(sort(x, decreasing = FALSE)))
> The result:
>   100010996 100011000
> When we sort the data in the increasing order, we get the correct result. If 
> we sort the data in the decreasing order, we get a result that is off by 4.

> Shouldn't the sort be in the increasing order rather than in the decreasing 
> order?

> Best regards,
> Jan Motl


> PS: This post is based on discussion on 
> https://stackoverflow.com/questions/47847295/why-does-chisq-test-sort-data-in-descending-order-before-summation
>  and the response from the post to r-h...@r-project.org.
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Region subtag in package 'Language' field

[Kurt Hornik]

> Jeroen Ooms writes:

All standard (not private use or grandfathered) IETF language tags
should be fine.  What WRE says about ISO-639 codes is meant to explain
the language subtags.

Hth
-k

> I am looking for the appropriate field to let package authors to
> declare the pkg documentation language for spell checkers. The most
> important case is to specify a preference between "en-US" or "en-GB"
> which can be used by the hunspell or spelling pkg to select the
> appropriate dictionary.

> WRE defines the "Language" field for documentation language, but from
> the current description it seems restricted to 2 or 3 letter ISO-639
> codes such as "en" or "eng". WRE also mentions rfc-5646, which refers
> to ISO 3166-1 for region/country subtags but it is unclear if these
> are allowed in the field?

> Spell checking libraries (e.g. myspell/hunspell) typically use
> locale-like language names to identify the appropriate dictionary such
> as "en_GB" or "de_AT", see for example [1,2]. Merely specifying "en"
> or "de" is ambiguous to the spell checker. I was wondering if the WRE
> definition of the "Language" field could allow for this?



> [1] https://apps.fedoraproject.org/packages/hunspell-en/contents/
> [2] https://packages.debian.org/stretch/hunspell-en-gb

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

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

Re: [Rd] Dialect for shell scripts

[Kurt Hornik]

> Iñaki Úcar writes:

Same from here: in addition to what the standards say, it always pays to
be defensive and check "Portable Shell Programming" in the Autoconf
manual.  Among other things, this says

'$((EXPRESSION))'
 Arithmetic expansion is not portable as some shells (most notably
 Solaris 10 '/bin/sh') don't support it.

motivating the code shown below.  Perhaps simplest to always use expr.

-k


> For what it's worth, Autoconf does not assume that arithmetic
> expansion will be available. Instead, it emits the following shell
> code:

> if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then
>   eval 'func_arith ()
>   {
> func_arith_result=$(( $* ))
>   }'
> else
>   func_arith ()
>   {
> func_arith_result=`expr "$@"`
>   }
> fi

> 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar :
>> Dear all,
>> 
>> During a recent package submission, we were highlighted that some lines in
>> our configure script didn't follow the correct syntax. The lines looked like
>> this:
>> 
>> x=$(($y/10))
>> 
>> We were indicated at the time that this is because the statement does not
>> use Bourne shell syntax, which is absolutely true, and also that the manual
>> warns about this, which is true again. So far everything is clear.
>> 
>> However, what confuses me is that even when the manual says that "you can
>> include an executable (Bourne) shell script configure in your package" [1],
>> the associated footnote says something slightly different: "The script
>> should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes even
>> further, and links to the POSIX specification of the Shell Command Language
>> [3] (as published by The Open Group), which explicitly includes arithmetic
>> expressions like the one above in its syntax [4].
>> 
>> My question then is: what exact dialect should be considered? Given that the
>> statement above does not work in the Bourne shell, I conclude that the
>> Bourne shell is not POSIX-compliant. That in turn would make the manual
>> ambiguous as to the precise dialect that should be used by our configure
>> scripts, and either the shells used by R should be changed to be
>> POSIX-compliants, or the manual edited to be more precise regarding .
>> 
>> Many thanks.
>> 
>> Rodrigo
>> 
>> [1]
>> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
>> [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25
>> [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
>> [4]
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



> -- 
> Iñaki Úcar
> http://www.enchufa2.es
> @Enchufa2

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

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

Re: [Rd] R CMD Rd2pdf and macros

[Kurt Hornik]

> Kasper Daniel Hansen writes:

Interesting.  When I take e.g. zTree as the last CRAN package using the
\packageTitle macro,

   R CMD Rd2pdf zTree

seems to work fine, but

   R CMD Rd2pdf zTree/man

gives

Converting Rd files to LaTeX Warning in parse_Rd("zTree/man/zTree-package.Rd", 
encoding = "unknown",  :
  zTree/man/zTree-package.Rd:6: unknown macro '\packageTitle'
Warning in parse_Rd("zTree/man/zTree-package.Rd", encoding = "unknown",  :
  zTree/man/zTree-package.Rd:9: unknown macro '\packageDescription'
Warning in parse_Rd("zTree/man/zTree-package.Rd", encoding = "unknown",  :
  zTree/man/zTree-package.Rd:13: unknown macro '\packageDESCRIPTION'
Warning in parse_Rd("zTree/man/zTree-package.Rd", encoding = "unknown",  :
  zTree/man/zTree-package.Rd:14: unknown macro '\packageIndices'
Warning in parse_Rd("zTree/man/zTree-package.Rd", encoding = "unknown",  :
  zTree/man/zTree-package.Rd:17: unknown macro '\packageAuthor'
Warning in parse_Rd("zTree/man/zTree-package.Rd", encoding = "unknown",  :
  zTree/man/zTree-package.Rd:18: unknown macro '\packageMaintainer'

Same in your case?

Best
-k


> When I run R CMD Rd2pdf on the man pages of a package, ie
>   R CMD Rd2pdf man

> I get

> Converting Rd files to LaTeX Warning in parse_Rd("man/mpra-package.Rd",
> encoding = "unknown", fragment = FALSE,  :
>   man/mpra-package.Rd:6: unknown macro '\packageTitle'
> Warning in parse_Rd("man/mpra-package.Rd", encoding = "unknown", fragment =
> FALSE,  :
>   man/mpra-package.Rd:9: unknown macro '\packageDescription'
> Warning in parse_Rd("man/mpra-package.Rd", encoding = "unknown", fragment =
> FALSE,  :
>   man/mpra-package.Rd:15: unknown macro '\packageAuthor'
> Warning in parse_Rd("man/mpra-package.Rd", encoding = "unknown", fragment =
> FALSE,  :
>   man/mpra-package.Rd:17: unknown macro '\packageMaintainer'
> Warning in parse_Rd("man/mpra-package.Rd", encoding = "unknown", fragment =
> FALSE,  :
>   man/mpra-package.Rd:24: unknown macro '\doi'

> It would appear that installed, system level macros are not read and used?

> Best,
> Kasper

>   [[alternative HTML version deleted]]

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

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

Re: [Rd] unlicense

[Kurt Hornik]

> Charles Geyer writes:

> In that case, perhaps the question could be changed to could CC0 be
> added to the list of R licences.  Right now the only CC licence that
> is in the R licenses is CC-BY-SA-4.0.

Hmm, I see

Name: CC0
FSF: free_and_GPLv3_compatible 
(https://www.gnu.org/licenses/license-list.html#CC0)
OSI: NA (https://opensource.org/faq#cc-zero)
URL: https://creativecommons.org/publicdomain/zero/1.0/legalcode
FOSS: yes

in the R license db ...

-k

> On Wed, Jan 18, 2017 at 7:23 AM, Brian G. Peterson  
> wrote:
>> 
>> On Tue, 2017-01-17 at 22:46 -0500, Kevin Ushey wrote:
>>> It appears that Unlicense is considered a free and GPL-compatible
>>> license; however, the page does suggest using CC0 instead (which is
>>> indeed a license approved / recognized by CRAN). CC0 appears to be
>>> the primary license recommended by the FSF for software intended for
>>> the public domain.
>> 
>> I'd second the recommendation for CC0.  Lawyers at IP-restrictive firms
>> I've worked for in the past have been OK with this license.
>> 
>> - Brian
>> 



> -- 
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu

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

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

Re: [Rd] RFC: Declaring foo.bar as nonS3method() ?!

[Kurt Hornik]

 Duncan Murdoch writes:

 On 12/06/2015 4:12 AM, Martin Maechler wrote:
 This is a topic ' apparent S3 methods note in R CMD check '
 from R-package-devel  
 https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html
 
 which is relevant to here because some of us have been thinking
 about extending R  because of the issue.
 
 John Fox, maintainer of the 'effects' package has enquired about
 the following  output from  'R CMD check effects' 
 
  * checking S3 generic/method consistency ... NOTE
  Found the following apparent S3 methods exported but not registered:
  all.effects
 
 and added
 
  The offending function, all.effects(), is deprecated in favour of
  allEffects(), but I'd rather not get rid of it for backwards 
  compatibility.
  Is there any way to suppress the note without removing all.effects()? 
 
 and I had agreed that this was a False Positive in this case.
 
 [...]
 
 and then
 
  Now I agree .. and have e-talked about this with another R core
  member .. that it would be desirable for the package author to
  effectively declare the fact that such a function is not an S3
  method even though it looks like it at least if looked from far.
 
  So, ideally, you could have something like
 
  nonS3method(all.effects)
 
  somewhere in your package source ( in NAMESPACE or R/*.R )
  which would tell the package-checking code -- but *ALSO* all the other S3
  method code that  all.effects should be treated as a regular R
  function.
 
  I would very much like such a feature in R, and for that reason,
  I'm cross posting this (as one of the famous exceptions that
  accompany real-life rules!!) to R-devel.
 
 and actually I did *not* cross post, but have now moved the
 relevant part of the thread to  R-devel.
 

 It sounds like a good idea.  It's a nontrivial amount of work, because
 of the all the other S3 method code part.  There's the question of
 functions defined outside of packages:  presumably they are still S3
 methods, with no way to suppress that.

I am not sure this is the right solution: S3 dispatch will still occur
because we first look at foo.bar exports and then in the S3 registry,
afaicr (the all the other S3 method code part).

If we could move to only looking at the registry for dispatch, there
would be no need to declare situations where we should not dispatch on
foo.bar exports.

-k

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

Re: [Rd] RFC: Declaring foo.bar as nonS3method() ?!

[Kurt Hornik]

 Duncan Murdoch writes:

 On 12/06/2015 7:16 AM, Kurt Hornik wrote:
 Duncan Murdoch writes:
 
 On 12/06/2015 4:12 AM, Martin Maechler wrote:
 This is a topic ' apparent S3 methods note in R CMD check '
 from R-package-devel  
 https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html
 
 which is relevant to here because some of us have been thinking
 about extending R  because of the issue.
 
 John Fox, maintainer of the 'effects' package has enquired about
 the following  output from  'R CMD check effects' 
 
 * checking S3 generic/method consistency ... NOTE
 Found the following apparent S3 methods exported but not registered:
 all.effects
 
 and added
 
 The offending function, all.effects(), is deprecated in favour of
 allEffects(), but I'd rather not get rid of it for backwards 
 compatibility.
 Is there any way to suppress the note without removing all.effects()? 
 
 and I had agreed that this was a False Positive in this case.
 
 [...]
 
 and then
 
 Now I agree .. and have e-talked about this with another R core
 member .. that it would be desirable for the package author to
 effectively declare the fact that such a function is not an S3
 method even though it looks like it at least if looked from far.
 
 So, ideally, you could have something like
 
 nonS3method(all.effects)
 
 somewhere in your package source ( in NAMESPACE or R/*.R )
 which would tell the package-checking code -- but *ALSO* all the other S3
 method code that  all.effects should be treated as a regular R
 function.
 
 I would very much like such a feature in R, and for that reason,
 I'm cross posting this (as one of the famous exceptions that
 accompany real-life rules!!) to R-devel.
 
 and actually I did *not* cross post, but have now moved the
 relevant part of the thread to  R-devel.
 
 
 It sounds like a good idea.  It's a nontrivial amount of work, because
 of the all the other S3 method code part.  There's the question of
 functions defined outside of packages:  presumably they are still S3
 methods, with no way to suppress that.
 
 I am not sure this is the right solution: S3 dispatch will still occur
 because we first look at foo.bar exports and then in the S3 registry,
 afaicr (the all the other S3 method code part).
 
 If we could move to only looking at the registry for dispatch, there
 would be no need to declare situations where we should not dispatch on
 foo.bar exports.
 

 I think that would break a lot of existing scripts.  I think the logic
 should be something like this.

 For each class in the class list:

 Search backwards through the environment chain.  If the current location
 is a package environment or namespace, look only in the registry.  If
 not, look at all functions.

 If that search failed, try the next class.

Yep---that's what I meant.  I forgot to write the if namespace
semantics applies part :-)

Best
-k

 A variation on the test is:  If there's a registry in the current
 location, look there.  But I think the registry is not on the search
 list, so I'm not sure that would work.

 This assumes that we keep separate registries in each package; if we
 merge them into one big registry, it gets harder.  I'm not familiar
 enough with the code to know which way we do it.

 Duncan Murdoch

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

Re: [Rd] NEWS.md support on CRAN

[Kurt Hornik]

 Duncan Murdoch writes:

 On 02/06/2015 11:05 AM, Dirk Eddelbuettel wrote:
 Hi Kurt,
 
 On 1 June 2015 at 14:02, Kurt Hornik wrote:
 |  peter dalgaard writes:
 |
 |  On 30 May 2015, at 01:20 , Imanuel Costigan i.costi...@me.com wrote:
 | 
 |  So I assume this commit means NEWS.md is now no longer on blacklist?
 | 
 |
 |  in the development version. Not true of released versions.
 |
 | Now also in r-patched.
 
 Nice.
 
 Now, is there a way for package authors to preview how a .md would be
 rendered?  I wrote mine with GitHub in mind, and they render fine. I looked a
 recently-uploaded README.md of mine on CRAN, and it got some of the pandoc-y
 parts wrong --- and looks unprofessional.
 
 I would like to avoid that.  How can I?

 In the short term, you should probably try to run pandoc with the same 
 version and options as CRAN.  Kurt, can you say what these are?  If you 
 (Dirk) know pandoc options that emulate Github, it would probably make 
 sense for CRAN to use those.

Sure.  We currently have

pandoc 1.12.4.2
Compiled with texmath 0.6.6.1, highlighting-kate 0.5.8.5.

which we use with --email-obfuscation=references.

Best
-k

 In the longer term, the plan is to include our own parser and renderer.  
 At that point this would be easy.

 Duncan Murdoch
 
 Dirk
 
 
 | -k
 |
 |  -pd
 |
 |
 |  
 https://github.com/wch/r-source/commit/9ffe87264a1cd59a31a829f72d57af0f1bfa327a
 | 
 |  Sent from my iPad
 | 
 |  On 23 May 2015, at 6:05 pm, Kurt Hornik kurt.hor...@wu.ac.at wrote:
 | 
 |  Duncan Murdoch writes:
 | 
 |  On 22/05/2015 8:49 PM, Imanuel Costigan wrote:
 |  Are there any plans for CRAN to support NEWS files in markdown? Bit 
 of a hassle to go the the package’s Github (or other like) site to read NEWS.
 | 
 |  Not as far as I know.  There have been discussions about increasing 
 the
 |  support of Markdown, but so far the conclusion has been that it's too
 |  hard to do -- the support is not stable enough on all the platforms
 |  where R runs.
 | 
 |  There are actually two issues here.
 | 
 |  For CRAN, we could in principle take inst/NEWS.md files, convert these
 |  to HTML using pandoc, and use the HTML for the package web page.  
 (Would
 |  need the CRAN incoming checks to be taught about inst/NEWS.md.)
 | 
 |  However, we cannot use such files for utils::news() because we do not
 |  (yet?) know how to reliably parse such files and extract the news items
 |  (and hence cannot really compute on the news information).
 | 
 |  Btw, currently only one package on CRAN has inst/NEWS.md (another one
 |  has NEWS.md at top level).
 | 
 |  Best
 |  -k
 | 
 |  Markdown is allowed for vignettes (because the package author 
 processes
 |  those), so I'd suggest putting your news into a vignette instead of a
 |  news file.  Put in a token news file that points to the vignette so
 |  users can find it.
 | 
 |  Duncan Murdoch
 | 
 |  __
 |  R-devel@r-project.org mailing list
 |  https://stat.ethz.ch/mailman/listinfo/r-devel
 | 
 |  [[alternative HTML version deleted]]
 | 
 |  __
 |  R-devel@r-project.org mailing list
 |  https://stat.ethz.ch/mailman/listinfo/r-devel
 |
 |  --
 |  Peter Dalgaard, Professor,
 |  Center for Statistics, Copenhagen Business School
 |  Solbjerg Plads 3, 2000 Frederiksberg, Denmark
 |  Phone: (+45)38153501
 |  Email: pd@cbs.dk  Priv: pda...@gmail.com
 |
 |  __
 |  R-devel@r-project.org mailing list
 |  https://stat.ethz.ch/mailman/listinfo/r-devel
 |
 | __
 | R-devel@r-project.org mailing list
 | https://stat.ethz.ch/mailman/listinfo/r-devel
 

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

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

Re: [Rd] NEWS.md support on CRAN

[Kurt Hornik]

 peter dalgaard writes:

 On 30 May 2015, at 01:20 , Imanuel Costigan i.costi...@me.com wrote:
 
 So I assume this commit means NEWS.md is now no longer on blacklist? 
 

 in the development version. Not true of released versions.

Now also in r-patched.

-k

 -pd


 https://github.com/wch/r-source/commit/9ffe87264a1cd59a31a829f72d57af0f1bfa327a
 
 Sent from my iPad
 
 On 23 May 2015, at 6:05 pm, Kurt Hornik kurt.hor...@wu.ac.at wrote:
 
 Duncan Murdoch writes:
 
 On 22/05/2015 8:49 PM, Imanuel Costigan wrote:
 Are there any plans for CRAN to support NEWS files in markdown? Bit of a 
 hassle to go the the package’s Github (or other like) site to read NEWS.
 
 Not as far as I know.  There have been discussions about increasing the
 support of Markdown, but so far the conclusion has been that it's too
 hard to do -- the support is not stable enough on all the platforms
 where R runs.
 
 There are actually two issues here.
 
 For CRAN, we could in principle take inst/NEWS.md files, convert these
 to HTML using pandoc, and use the HTML for the package web page.  (Would
 need the CRAN incoming checks to be taught about inst/NEWS.md.)
 
 However, we cannot use such files for utils::news() because we do not
 (yet?) know how to reliably parse such files and extract the news items
 (and hence cannot really compute on the news information).
 
 Btw, currently only one package on CRAN has inst/NEWS.md (another one
 has NEWS.md at top level).
 
 Best
 -k
 
 Markdown is allowed for vignettes (because the package author processes
 those), so I'd suggest putting your news into a vignette instead of a
 news file.  Put in a token news file that points to the vignette so
 users can find it.
 
 Duncan Murdoch
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 
 [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

 -- 
 Peter Dalgaard, Professor,
 Center for Statistics, Copenhagen Business School
 Solbjerg Plads 3, 2000 Frederiksberg, Denmark
 Phone: (+45)38153501
 Email: pd@cbs.dk  Priv: pda...@gmail.com

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

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

Re: [Rd] NEWS.md support on CRAN

[Kurt Hornik]

 Duncan Murdoch writes:

 On 22/05/2015 8:49 PM, Imanuel Costigan wrote:
 Are there any plans for CRAN to support NEWS files in markdown? Bit of a 
 hassle to go the the package’s Github (or other like) site to read NEWS.

 Not as far as I know.  There have been discussions about increasing the
 support of Markdown, but so far the conclusion has been that it's too
 hard to do -- the support is not stable enough on all the platforms
 where R runs.

There are actually two issues here.

For CRAN, we could in principle take inst/NEWS.md files, convert these
to HTML using pandoc, and use the HTML for the package web page.  (Would
need the CRAN incoming checks to be taught about inst/NEWS.md.)

However, we cannot use such files for utils::news() because we do not
(yet?) know how to reliably parse such files and extract the news items
(and hence cannot really compute on the news information).

Btw, currently only one package on CRAN has inst/NEWS.md (another one
has NEWS.md at top level).

Best
-k

 Markdown is allowed for vignettes (because the package author processes
 those), so I'd suggest putting your news into a vignette instead of a
 news file.  Put in a token news file that points to the vignette so
 users can find it.

 Duncan Murdoch

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

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

Re: [Rd] Help finding source of warnings

[Kurt Hornik]

 Prof J C Nash (U30A) writes:

 I've been implementing a wrapper to the 2011 Fortran version of 
 L-BFGS-B. In optim(), R uses a C translation of a Fortran version (the 
 version number does not appear to be documented by the original 
 authors). The authors of the original Fortran code have updated it and 
 published the reasons in ACM TOMS due to inefficiencies and a bug.

 In running the checks on the resulting package (which is on R-forge 
 under the optimizer project), I'm getting a number of warning messages 
 of the type

 Warning in file.copy(file.path(.Library, pkg, DESCRIPTION), pd) :
problem copying /usr/lib/R/library/mgcv/DESCRIPTION to 
 /tmp/Rtmp0kkeHo/RLIBS_1214765d1c5f/mgcv/DESCRIPTION: No such file or 
 directory

 which reference DESCRIPTIONs for a number of packages other than the one 
 being checked -- here mgcv -- and which are not referenced in my package 
 as far as I can determine.

 Possibly unrelated, when I run the code on a problem, it works for one 
 run, then gives a NAMESPACE error and failure on the second try. Apart 
 from this, checks and unit tests appear to work correctly.

 Does anyone have pointers where I might find some ideas on the origin of 
 the issue(s)? I suspect the warning messages are not particularly 
 indicative of the source of the warnings, but that I have some subtle 
 glitch in the setup and call to the Fortran.

 I suspect this is not platform dependent, but I'm running Linux Mint 
 17.1 (ubuntu derivative), and  R 3.1.2.

John: maybe you did not install the recommended packages?
(On Debian, the corresponding package would be r-recommended.)

Best
-k

 Cheers, JN

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

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

Re: [Rd] Making iconv portable?

[Kurt Hornik]

 Spencer Graves writes:

 Hello, All:  
 What would it take to make “iconv” portable?  


 I ask, because I want to convert accented characters to
 vanilla ASCII, thereby converting, e.g., ‘Raúl’ to “Raul”, and
 Milan Bouchet-Valet suggested on R-help that I use 'iconv(x,
 “, ASCII//TRANSLIT”)’.  This worked under Windows but failed
 on Linux and Mac.  It’s part of the “subNonStandardCharacters”
 function in the Ecfun package. The development version on
 R-Forge uses this and returns “Raul” under Windows and NA
 under Mac OS X (and presumably also Linux).

Hmm.

R iconv(Raúl, , ASCII//TRANSLIT)
[1] Raul

seems to work for me on Linux ...

-k


The “iconv” R code merely calls compiled code, which I’ve used very 
 little in 30 years.   


 Thanks, 
 Spencer 



 On Nov 30, 2014, at 2:32 AM, Spencer Graves 
 spencer.gra...@structuremonitoring.com 
 mailto:spencer.gra...@structuremonitoring.com wrote:
 
 Wonderful.  Thanks very much.  Spencer
 
 
 On 11/30/2014 2:25 AM, Milan Bouchet-Valat wrote:

   [[alternative HTML version deleted]]

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

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

Re: [Rd] links to package vignettes on CRAN after R 2.14.0

[Kurt Hornik]

 Yihui Xie writes:

 Hi,
 I noticed the links to my package vignettes on CRAN were gone after I
 started using ./vignettes instead of ./inst/doc, as suggested by the
 R-exts manual in R 2.14.0. For example,

 http://cran.r-project.org/web/packages/formatR/index.html
 http://cran.r-project.org/web/packages/Rd2roxygen/index.html

 I have put %\VignetteIndexEntry in the Rnw file, but I do not
 understand why CRAN does not create the link in the package webpage
 any more. In the past, my vignettes were under ./inst/doc, and the
 links appeared as expected.

Should be fixed now.

-k

 Thanks!

 Regards,
 Yihui
 --
 Yihui Xie xieyi...@gmail.com
 Phone: 515-294-2465 Web: http://yihui.name
 Department of Statistics, Iowa State University
 2215 Snedecor Hall, Ames, IA

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

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

Re: [Rd] libtool FIXME

[Kurt Hornik]

 Marco atzeri writes:

 Hi,
 looking on the build scripts, I noticed on configure.ac

 ## FIXME
 ## Completely disable using libtool for building shlibs until libtool
 ## fully supports Fortran and C++.
 ## AC_ARG_WITH([libtool],
 ## [AS_HELP_STRING([--with-libtool],[use libtool for building shared 
 libraries @
 :@yes@:@])],
 ## [use_libtool=${withval}],
 ## [use_libtool=yes])
 ## AM_CONDITIONAL(USE_LIBTOOL, [test x${use_libtool} = xyes])
 ## /FIXME

 Is this comment outdated or still valid ?

Marco,

svn blame has

 17895 hornik ## Completely disable using libtool for building shlibs until 
libtool
 17895 hornik ## Completely disable using libtool for building shlibs until 
libtool

and change set 17895 is from 2002-01-21, so almost 10 years old.

Then it was certainly true.  Whether it still is, I don't know: we
needed to put considerable effort into creating our own non-libtool
solution.  Now we have something working and considerable effort would
be needed to rewrite the build toolchain [and I'd additionally be
concerned about possible future lack of libtool support for things R
needs to support].

Best
-k

 In my experience, Octave, that is mainly Fortran and C++ plus a small
 amount of C, is fully employing libtool and automake with a very clean
 and lean build system.

 My question is not just academic; I was thinking to package
 R for cygwin but the current configuration produce shared libs
 with the wrong name

/usr/bin/libR.dll
/usr/bin/libRmath.dll

 instead of expected

/usr/bin/cygR.dll
/usr/bin/cygRmath.dll

 (http://cygwin.com/cygwin-ug-net/dll.html#dll-build)
 so the as it is package will be rejected and a substantial
 patching of the various Makefile.in will be needed to make
 it conformant.


 Thanks in advance
 Marco

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

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

Re: [Rd] Referencing non-CRAN extension from CRAN package

[Kurt Hornik]

 Tim Jurka writes:

 Hi r-devel,

 I would like to submit a package to CRAN that makes use of an Omegahat
 extension, RStem ( http://www.omegahat.org/Rstem/ ). What is the best
 way to reference it in my package, and ensure compliance with CRAN
 submission guidelines?

CRAN can deal with package dependencies from BioC and Omegahat.

So e.g., Depends: Rstem in DESCRIPTION if you have Rstem as a depends.

Best
-k

 Thank you for your help!

 Tim



 --
 Timothy P. Jurka
 Department of Political Science
 University of California, Davis
 www.timjurka.com

   [[alternative HTML version deleted]]

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

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

Re: [Rd] all.equal doesn't work for POSIXlt objects

[Kurt Hornik]

 Joris Meys writes:

This is already fixed in r-devel.

-k

 Hi all,
 following sample code illustrates the problem :

   Date1 - Date2 -
 as.POSIXlt(seq.Date(as.Date(2010-04-01),as.Date(2011-04-01),by='day'))
   identical(Date1,Date2)
   all.equal(Date1,Date2)

 identical() gives the correct answer. As there is no all.equal method
 for POSIXlt objects, all.equal.list is used instead. Subsetting using
 [[]] doesn't work on POSIXlt objects. I solved the problem by adding a
 function all.equal.POSIXlt() :

 all.equal.POSIXlt - function(target, current, ..., scale=1) {
   check_tzones(target, current)
   target - unclass(target)
   current - unclass(current)
   NextMethod(all.equal.list)
 }

 This seems to work bugfree, but I'm not sure about it. So am I doing
 it correct, and if so, can this be added to the next R release? I'm
 not sure where else I should drop this proposal...

 Cheers
 Joris

 -- 
 Joris Meys
 Statistical consultant

 Ghent University
 Faculty of Bioscience Engineering
 Department of Applied mathematics, biometrics and process control

 tel : +32 9 264 59 87
 joris.m...@ugent.be
 ---
 Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

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

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

Re: [Rd] Accessing Package NEWS (NEWS.Rd)

[Kurt Hornik]

 Paul Roebuck writes:

 Okay. So, after having spent quite some time never really tracking down
 why my package NEWS files were unacceptable to readNEWS(), I
 noticed that there was recent (to me anyway) development that allowed
 the NEWS to be done as an Rd file. Sweet! A more standard format...

 I converted a NEWS file in one of my unreleased packages to Rd format.
 checkNEWS() gave it a thumbs up.

 But then it went south. Tried the following after installation:

All of this works much better for r-devel: in particular, this makes
clear that checkNEWS is for old-style (pre 2.12.0) R NEWS files ...

Best
-k

 checkNEWS(myapp/trunk/MyApp/inst/NEWS.Rd)
 [1] TRUE
 news(package=MyApp)

 Nothing.

 Debugging news() itself left me wondering. The first thing checked
 for was 'inst/NEWS.Rd' - once I install the package, that would never
 exist though, right? Should tools:::.build_news_db() instead use:

 nfile - file.path(dir, c(NEWS.Rd, file.path(inst, NEWS.Rd)))

 On the slim chance it should, I modified the path to my
 source folder's copy and continued debugging into 
 tools:::.build_news_db_from_package_NEWS_Rd().


 debug: ind - grepl(re_v, nms, ignore.case = TRUE)
 Browse[2] 
 debug: if (!all(ind)) warning(Cannot extract version info from the following 
 section titles:\n, 
 Browse[2] ind
 [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
 Browse[2] 
 debug: NULL
 Browse[2] 
 debug: .make_news_db(cbind(ifelse(ind, sub(re_v, \\1, nms), NA_character_), 
 ifelse(grepl(re_d, nms), sub(re_d, \\1, nms), NA_character_), 
 db[, 2L], sub(\n*$, , db[, 3L])), logical(nrow(db)), 
 news_db_from_Rd)
 Browse[2] 
 debugging in: .make_news_db(cbind(ifelse(ind, sub(re_v, \\1, nms), 
 NA_character_), 
 ifelse(grepl(re_d, nms), sub(re_d, \\1, nms), NA_character_), 
 db[, 2L], sub(\n*$, , db[, 3L])), logical(nrow(db)), 
 news_db_from_Rd)
 debug: {
 out - data.frame(x, row.names = NULL, stringsAsFactors = FALSE)
 colnames(out) - c(Version, Date, Category, Text)
 if (!is.null(bad)) 
 attr(out, bad) - bad
 class(out) - unique(c(classes, news_db, data.frame))
 out
 }
 Browse[3] 
 debug: out - data.frame(x, row.names = NULL, stringsAsFactors = FALSE)
 Browse[3] 
 debug: colnames(out) - c(Version, Date, Category, Text)
 Browse[3] 
 debug: if (!is.null(bad)) attr(out, bad) - bad
 Browse[3] 
 debug: attr(out, bad) - bad
 Browse[3] 
 debug: class(out) - unique(c(classes, news_db, data.frame))
 Browse[3] 
 debug: out
 Browse[3] 
 exiting from: .make_news_db(cbind(ifelse(ind, sub(re_v, \\1, nms), 
 NA_character_), 
 ifelse(grepl(re_d, nms), sub(re_d, \\1, nms), NA_character_), 
 db[, 2L], sub(\n*$, , db[, 3L])), logical(nrow(db)), 
 news_db_from_Rd)
 exiting from: tools:::.build_news_db_from_package_NEWS_Rd(newsfile)
 Error: invalid version specification CHANGES IN VERSION 1.0.0CHANGES IN 
 VERSION 1.0.1CHANGES IN VERSION 2.0.0


 Well, so it didn't like my version numbers. But is the regexp check correct?

 Browse[2] .standard_regexps()$valid_package_version
 [1] ([[:digit:]]+[.-]){1,}[[:digit:]]+

 Would appear as though packages with only major.minor comparisons would
 pass. Or did I miss something...


 
 P.S. Another thing I didn't see specified was whether this was an acceptable 
 format
 in current Rd format:

 \section{CHANGES IN VERSION 2.0.0}{

 Trying to get original TEXT files to be read by readNEWS(), the sections had 
 to
 read CHANGES IN R VERSION nnn. Using Rd format, checkNEWS() seemed
 to allow optionally using a package name instead (of 'R'). As it also allowed 
 using
 nothing, i went with that. What's the intended canonical format?

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

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

Re: [Rd] print.citation, small bug?

[Kurt Hornik]

 Nicholas Lewin-Koh writes:

Thanks.  Changed in r-devel now.

Best
-k

 Hi,
 I use Sweave extensively in my consulting work. When submitting reports to
 the scientists I work
 with I like to use the citation function to reference any packages I use, to
 give proper acknowledgement.
 I noted in the documentation that a  citation inherits from bibentry, and
 indeed,
 citr- citation()
 class(citr)
 [1] citation bibentry

 However, following this line I would assume citation should fully inherit
 the methods of bibentry. But that is not the case,
 print(citr, style=latex)
 still gives style='citation'

 utils:::print.citation
 function (x, ...)
 {
 NextMethod(print, x, style = citation)
 invisible(x)
 }
 environment: namespace:utils

 The citation print style is hard coded. Of course a workaround is,
 class(citr) - 'bibentry'
 but I think it would be better if print inherited all bibentry methods,
 something like

 print.citation - function (x, style=citation ...)
 {
 NextMethod(print, x, style = style, ...)
 invisible(x)
 }

 Then the default is still printing a citation, but other print methods are
 available.

 Thanks
 Nicholas

 -- 
 The bear and the goat were married and lived together until the end of
 their days. Either the goat went mad or the bear became sane.

 Nicholas Lewin-Koh
 Genentech

   [[alternative HTML version deleted]]

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

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

Re: [Rd] Minimum of an ordered factor

[Kurt Hornik]

 Martin Maechler writes:

 TTLAM == Thaler, Thorn, LAUSANNE, Applied Mathematics 
 thorn.tha...@rdls.nestle.com
 on Thu, 6 Jan 2011 15:37:01 +0100 writes:

TTLAM Kurt Hornik writes
  if (!all(sapply(args, is.ordered)) ||
  !all(sapply(level.list, identical, y = level.set))) {
 
 I think it would be better to use something like
 
 ll - lapply(args, levels)
 
 !all(sapply(ll, identical, ll[[1L]]))
 
 [using union() is not quite right]

TTLAM Yes definitely. This line is in fact just a relic from a previous idea I
TTLAM had.
 
 I have now committed the amended proposal (rev 53925);
 thank you for the feedbacks..


 The general comment is that if we support this I don't see why we
 should
 not also support c.ordered (and in fact also c.factor) with the same
 restrictions (identical level sequences for ordered and level sets for
 factors).  We already have Ops.factor and Ops.ordered using the same
 principle afaic.

 Yes, I think, too.

 If we add c.ordered, we should be able to encapsulate the identity of
 levels testing into this, and simply use
 
 x - c(...)
 
 and then call .Generic on the codes of x etc.

TTLAM Sounds reasonable. Ack.

 Yes, adding c.factor() and c.ordered() seems reasonable in
 principle.
 However, S and R now have a more than 20 year old history of
 silently coercing factors to there integer codes with c(),
 that I'm not yet sure we can do this without breaking too much
 code [[and I am pretty sure this topic has been discusses before]].

Yes, of course.  But then we just made another backwards incompatible
change, and

R c(ordered(1 : 3), ordered(4 : 6))
[1] 1 2 3 1 2 3

seems more like a bug to me :-)

 I think we should start discussing the issue in a new thread
 with proper Subject explicitly mention c() or
 c.factor/c.ordered.

Yes!

Best
-k

 Martin



TTLAM BR Thorn

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

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

Re: [Rd] Minimum of an ordered factor

[Kurt Hornik]

 Martin Maechler writes:

I have 3 comments:

 Thaler, Thorn, LAUSANNE, Applied Mathematics 
 thorn.tha...@rdls.nestle.com
 on Wed, 5 Jan 2011 11:20:47 +0100 writes:

 Hi everybody, Is there a particular reason, why this code
 does not work as intended:

 z - factor(LETTERS[1:3], ordered = TRUE)
 u - 4:6
 min(z[u  4])

 Error in Summary.factor(2:3, na.rm = FALSE) :
 min not meaningful for factors



 I agree that min is indeed not meaningful for not ordered
 factors, but it makes sense for ordered
 factors. Especially since

 z[3]  z[2]
 sort(z)

 _ARE_ defined and work as expected. 

 I agree that it is natural then, to expect  min(), max() and
 range() to work as well.

Same for me.

 Of course I can do something like

 sort(z[u4])[1]

 but this does not enhance readability of my code. Thus, I
 overloaded Summary.ordered as follows:


 

 Summary.ordered - function(..., na.rm) {

 ok - switch(.Generic, max = , min = , range = TRUE,
 FALSE)

 if (!ok) {

 warning(sprintf('%s' is not meaningful for ordered
 factors, .Generic))

 return(NA)

 }

 args - list(...)

 level.list - lapply(args, levels)

 level.set - Reduce(union, level.list)

 if (!all(sapply(args, is.ordered)) ||
 !all(sapply(level.list, identical, y = level.set))) {

I think it would be better to use something like

  ll - lapply(args, levels)

  !all(sapply(ll, identical, ll[[1L]]))

[using union() is not quite right]  

 stop(sprintf('%s' is only meaningful for ordered
 factors if all arguments are ordered factors with the same
 level sets,

 .Generic))

 }

 codes - lapply(args, as.integer)

 ind - do.call(.Generic, c(codes, na.rm = na.rm))

 factor(level.set[ind], levels = level.set, ordered =
 TRUE)

 }

 (the above is now even more garbled than it was already by your
  use of HTML-ified e-mail ..)

 But your code is fine, even nice, in most parts,
 and I will add (most of) it (and some documentation) to R-devel
 
 unless we get contradicting comments :

 Any comments appreciated.
 (still)

The general comment is that if we support this I don't see why we should
not also support c.ordered (and in fact also c.factor) with the same
restrictions (identical level sequences for ordered and level sets for
factors).  We already have Ops.factor and Ops.ordered using the same
principle afaic.

If we add c.ordered, we should be able to encapsulate the identity of
levels testing into this, and simply use

x - c(...)

and then call .Generic on the codes of x etc.

Best
-k


 Thank you, Thorn!

 With regards,
 Martin Maechler, ETH Zurich

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

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

Re: [Rd] R package BibTex entries: looking for a more general solution

[Kurt Hornik]

 Michael Friendly writes:

Thanks for the suggestions. In fact, we are currently working on this
issue. A lot of improvements have already been done, see ?person and
?bibentry for R 2.12.0 or later, especially the details and examples
sections. Some more work still needs to be done, though. We will write a
primer that introduces the new features when all of them are available.

Best
-k

 == Summary ==
 * Problem: BibTeX entries extracted from R packages via citation() 
 require too much manual editing to be
 of general use.
 * Proposal: Date: fields should be made mandatory in package DESCRIPTION 
 files, perhaps
 beginning with warnings from R CMD check
 * Proposal: Package authors should be encouraged to use a (new) 
 Contributors: field in the DESCRIPTION file
 rather than packing all information into the Author: field, which at 
 present cannot often be parsed by BibTeX.
 * Files: All test files referred to here can be found at

 http://euclid.psych.yorku.ca/SCS/Private/Rbibs/

 == Details ==
 Around 16 Dec. 2009, I queried R-help about automating the extraction of 
 citation()s from R packages. The stimulus
 was that some journals, notably JSS, now require a reference and 
 citation of every R package mentioned,
 and it is a pain to create these manually, no less maintain them for 
 current versions.

 The result of that query was a function, Rpackage.bibs() by Achim 
 Zeileis that I have been using ever since.
 Code in: http://euclid.psych.yorku.ca/SCS/Private/Rbibs/Rpackages.bib.R
 On one current system I get the following:

 Rpackage.bibs(file=Rpackages-R.2.11.1.bib)
 Converted 230 of 230 package citations to BibTex
 Results written to file Rpackages-R.2.11.1.bib
 Warning messages:
 1: In citation(x) :
 no date field in DESCRIPTION file of package 'codetools'
 2: In citation(x) :
 no date field in DESCRIPTION file of package 'gridBase'
 3: In citation(x) : no date field in DESCRIPTION file of package 'iplots'
 
 See:
 http://euclid.psych.yorku.ca/SCS/Private/Rbibs/Rpkg-test.pdf
 for the result of processing this .bib file with latex/bibtex using the 
 jss.bst bibliography style

 I'm writing to R-Devel because the DESCRIPTION and inst/CITATION files 
 in R packages provide the
 basic data used in citation() and any methods based on this, and yet the 
 information in these files is
 often insufficient to generate well-formed BibTeX entries for use in 
 vignettes and publications.

 One easy case is illustrated above, where 3 packages have no Date: field 
 so the BibTeX gets no
 year = {},
 and references get printed as Murrell, P () for gridBase. (In my 
 original test under R 2.9.1, there where
 ~ 20 such warnings.) Thus, I propose that Date: be a required field in 
 DESCRIPTION files, and
 R CMD check complain if this is not found.

 The more difficult case has to do with the Author: field in the 
 DESCRIPTION file (when no CITATION file is present)
 People can write whatever they want here, and the result looks sort of 
 OK when printed by citation(), but confuses
 BibTeX mightly. One example:

 citation(akima)
 To cite package ‘akima’ in publications use:

 Fortran code by H. Akima R port by Albrecht Gebhardt aspline function
 by Thomas Petzoldt petzo...@rcs.urz.tu-dresden.de enhancements and
 corrections by Martin Maechler (2009). akima: Interpolation of
 irregularly spaced data. R package version 0.5-4.
 http://CRAN.R-project.org/package=akima

 A BibTeX entry for LaTeX users is

 @Manual{,
 title = {akima: Interpolation of irregularly spaced data},
 author = {Fortran code by H. Akima R port by Albrecht Gebhardt aspline 
 function by Thomas Petzoldt petzo...@rcs.urz.tu-dresden.de 
 enhancements and corrections by Martin Maechler},
 year = {2009},
 note = {R package version 0.5-4},
 url = {http://CRAN.R-project.org/package=akima},
 }

 ATTENTION: This citation information has been auto-generated from the
 package DESCRIPTION file and may need manual editing, see
 ‘help(citation)’ .
 

 Yes, the ATTENTION note does say that manual editing may be necessary, 
 but I think a worthy goal would be
 to try to reduce the need for this.

 One simple way to do that would be to support an extra Contributions: 
 field in the DESCRIPTION file,
 so that Authors: can be more cleanly separated for the purpose of 
 creating well-structured BibTeX.
 Perhaps others have better ideas.

 -Michael

 -- 
 Michael Friendly Email: friendly AT yorku DOT ca
 Professor, Psychology Dept.
 York University  Voice: 416 736-5115 x66249 Fax: 416 736-5814
 4700 Keele StreetWeb:http://www.datavis.ca
 Toronto, ONT  M3J 1P3 CANADA

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

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

Re: [Rd] Suggestion: Add DESCRIPTION 'Date' to R CMD check log header

[Kurt Hornik]

 Martin Maechler writes:

 Hi Henrik
 HB == Henrik Bengtsson h...@stat.berkeley.edu
 on Tue, 14 Sep 2010 18:26:31 -0700 writes:

HB Hi,
HB in R CMD check, the version of the package being checked is reported, e.g.

HB Thu Sep  9 05:02:30 2010: Checking package R.utils (SVN revision 399) ...
HB * using log directory ‘/srv/R/R.check/R-devel/PKGS/R.utils.Rcheck’
HB * using R version 2.12.0 Under development (unstable) (2010-09-07 r52876)
HB * using platform: x86_64-unknown-linux-gnu (64-bit)
HB * using session charset: UTF-8
HB * checking for file ‘R.utils/DESCRIPTION’ ... OK
HB * this is package ‘R.utils’ version ‘1.5.2’
HB ...

HB I'd like to request/suggest that the 'Date' in the DESCRIPTION file is
HB also added, e.g.

HB * this is package ‘R.utils’ version ‘1.5.2’ ('2010-09-14')


HB WHY?
HB This would be particular useful when you work toward sites like
HB R-forge and Bioconductor when you may commit your day's work on
HB package when you update the 'Date' but you do not really want to
HB update the 'Version' because you're going to put in more work
HB tomorrow.  With the 'Date' information you'll be able to see what
HB version of your updates have been checked by the servers.  I
HB understand that this may be an odd process to follow even for devel
HB branches and you may argue that you should always bump the version
HB number whenever you do an SVN commit (e.g. '1.5.2.1' for temporary
HB commits).  Either way, I find it useful to see the date as well.

 I agree that this is useful.
 Of course, for all those cases, where there's no  Date:,
 nothing (i.e. no ()) should be written.

 If you (or someone) provide patches against  R-devel
 ( https://svn.r-project.org/R/trunk/ )
 and they pass 'make check-all', I'd add this feature.

But pls not against the Date field by default:

R-Forge packages record their revision in their package metadata.

CRAN packages record Date/Publication in their metadata.

Not sure about BioC ...

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

Re: [Rd] NEWS and readNEWS

[Kurt Hornik]

 Hadley Wickham writes:

 readNEWS() states:
  Read R's ‘NEWS’ file or a similarly formatted one.  This is an
  experimental feature, new in R 2.4.0 and may change in several
  ways

 and news() also indicates that this tool is supposed to work with
 non-R news files.  However, I've not been able to get readNEWS to read
 a package news file, even when following the format indicated in
 news().  Looking at the code for readNEWS() it seems there are couple
 of places where it assumes it's working with the main R NEWS file:

   * s.post -  SERIES NEWS
   * s.pre - ^[\t ]*CHANGES IN R VERSION 

 Is this a bug or is the documentation incorrect?

readNEWS() is really for such 3-level files, but then R itself will move
to an 2-level Rd format in R 2.12.0.

Use news() to read package news files.

-k

 Hadley

 -- 
 Assistant Professor / Dobelman Family Junior Chair
 Department of Statistics / Rice University
 http://had.co.nz/

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

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

Re: [Rd] codoc mismatches warning

[Kurt Hornik]

 Sebastian P Luque writes:

 Hi,
 Doing 'R CMD check diveMove' is now throwing this message:

Which version of diveMove is this?

-k

 Data codoc mismatches from documentation object 'sealLocs':
 Variables in data frame 'sealLocs'
   Code: id.time.class.lon.lat
   Docs: class id lat lon time

 with:

R sessionInfo()
 R version 2.10.1 (2009-12-14) 
 x86_64-pc-linux-gnu 

 locale:
  [1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C   
 LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
  [5] LC_MONETARY=C  LC_MESSAGES=en_CA.UTF-8
 LC_PAPER=en_CA.UTF-8   LC_NAME=C 
  [9] LC_ADDRESS=C   LC_TELEPHONE=C 
 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C   

 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base 

 other attached packages:
 [1] slmisc_0.7.3   lattice_0.18-3

 loaded via a namespace (and not attached):
 [1] grid_2.10.1

 I've never had this problem in previous versions.  'sealLocs' is a *.csv
 file with this head:

 ,-[ head -n5 data/sealLocs.csv ]
 | id,time,class,lon,lat
 | ringy,2006-06-14 20:31:46,2,-72.655,40.915
 | ringy,2006-06-15 05:58:14,3,-72.656,40.918
 | ringy,2006-06-15 07:56:32,3,-72.657,40.919
 | ringy,2006-06-15 19:07:49,2,-72.474,40.834
 `-

 and this is the relevant section of man/sealLocs.Rd:

 \format{A data frame with the following information:

   \describe{
 \item{id}{String naming the seal the data come from.}

 \item{time}{The date and time of the location.}

 \item{class}{The ARGOS location quality classification.}

 \item{lon, lat}{x and y geographic coordinates of each location.}
   }
 }

 Any pointers to avoid the warning?  Thanks.


 Cheers,

 -- 
 Seb

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

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

Re: [Rd] optional package dependency

[Kurt Hornik]

 Jeff Ryan writes:

 Hi Ross,
 The quantmod package makes available routines from a variety of
 contributed packages, but gets around your issues with a bit of, um,
 trickery.

 Take a look here (unless your name is Kurt ;-) ):

But Kurt will we happy to tell you that you can turn off forcing
suggested packages for checking by setting

  _R_CHECK_FORCE_SUGGESTS_=false

in your environment.  The idea is that maintainers typically want to
fully check their functionality, suggesting to force suggests by
default.

-k
  

 http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367root=quantmodview=markup

 It would be nice to have Suggests really mean suggests to check, but I
 am sure there is a good reason it doesn't.

 HTH
 Jeff

 On Fri, Jan 15, 2010 at 12:00 AM, Ross Boylan r...@biostat.ucsf.edu wrote:
 I have a package that can use rmpi, but works fine without it.  None of
 the automatic test code invokes rmpi functionality.  (One test file
 illustrates how to use it, but has quit() as its first command.)
 
 What's the best way to handle this?  In particular, what is the
 appropriate form for upload to CRAN?
 
 When I omitted rmpi from the DESCRITPION file R CMD check gave
 quote
 * checking R code for possible problems ... NOTE
 alldone: no visible global function definition for ‘mpi.bcast.Robj’
 alldone: no visible global function definition for ‘mpi.exit’
 quote
 followed by many more warnings.
 
 When I add
 Suggests: Rmpi
 in DESCRIPTION the check stops if the package is not installed:
 quote
 * checking package dependencies ... ERROR
 Packages required but not available:
  Rmpi
 /quote
 Rmpi is not required, but I gather from previous discussion on this list
 that suggests basically means required for R CMD check.
 
 NAMESPACE seems to raise similar issues; I don't see any mechanism for
 optional imports.  Also, I have not used namespaces, and am not eager to
 destabilize things so close to release.  At least, I hope I'm close to
 release :)
 
 Thanks for any advice.
 
 Ross Boylan
 
 P.S. Thanks, Duncan, for your recent advice on my help format problem
 with R 2.7.  I removed the nested \description, and now things look OK.
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 



 -- 
 Jeffrey Ryan
 jeffrey.r...@insightalgo.com

 ia: insight algorithmics
 www.insightalgo.com

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

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

Re: [Rd] missing R-devel/po

[Kurt Hornik]

 Petr Savicky writes:

 When i unpack R-devel_2010-01-05.tar.bz2 and run ./configure on
 two Linux machines, i get the error message

   configure: creating ./config.status
   config.status: creating Makeconf
   config.status: creating Makefile
   config.status: creating doc/Makefile
   config.status: creating doc/html/Makefile
   config.status: creating doc/manual/Makefile
   config.status: creating etc/Makefile
   config.status: creating etc/Makeconf
   config.status: creating etc/Renviron
   config.status: creating etc/ldpaths
   config.status: creating m4/Makefile
   config.status: error: cannot find input file: po/Makefile.in.in

 For R-devel_2010-01-04.tar.bz2, ./configure runs fine.

 The reason could be that R-devel_2010-01-05.tar.bz2 does not
 contain the directory R-devel/po. This directory is present in
 R-devel_2010-01-04.tar.bz2 and contains the file R-devel/po/Makefile.in.in.

 I see the directory R-devel/po at https://svn.r-project.org/R/trunk/,
 so the problem could be just temporary.

A problem from a recent change causing make dist to fail in subdir tests
(so subdir tests is empty and po is missing).  We're working on a fix.

Best
-k

 Petr Savicky.

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

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

Re: [Rd] R CMD check may not detect a code/documentation mismatch

[Kurt Hornik]

 Peter Dalgaard writes:

 Petr Savicky wrote:
 For the package at
 http://www.cs.cas.cz/~savicky/R-devel/something_0.0.0.tar.gz
 which is a minor part of some other package only to demonstrate the
 problem, i get (under R version 2.11.0 Under development 2009-12-12 r50714
 and also under R-2.9.2, openSUSE 11.1 (x86_64) and CentOS release 5.2)
 
 R CMD check something_0.0.0.tar.gz
 
 ...
 * checking Rd files ... OK
 * checking Rd metadata ... OK
 * checking Rd cross-references ... OK
 * checking for missing documentation entries ... OK
 * checking for code/documentation mismatches ... OK
 * checking Rd \usage sections ... OK
 * checking examples ... NONE
 * checking PDF version of manual ... OK
 
 although the package code contains
 
 testCoreNA - function()
 
 and the documentation contains
 
 \usage{
 testCoreClass(verbose=0)
 testCoreAttrEval(verbose=0)
 testCoreReg(verbose=0)
 testCoreNA(verbose=0)
 }
 
 There is a mismatch between code and documentation of testCoreNA(). Is the 
 problem caused by having four entries in \usage{} section?

 Hmm, looks more like a thinko in this code inside codoc():

  functions_in_code - Filter(function(f) {
  f - get(f, envir = code_env)
  is.function(f)  (length(formals(f))  0L)
  }, objects_in_code)

 which, further down the line, causes functions with no formal arguments 
 to be skipped when compared to the usage section.

 Browse[2]
 debug: ind - (!functions %in% functions_to_be_ignored  functions %in%
  functions_in_code)
 Browse[2] functions
 [1] testCoreClasstestCoreAttrEval testCoreReg 
 testCoreNA
 Browse[2]
 debug: bad_functions - mapply(functions[ind], exprs[ind], FUN = 
 function(x,
  y) check_codoc(x, as.pairlist(as.alist.call(y[-1L]))), SIMPLIFY = 
 FALSE)
 Browse[2] ind
 [1]  TRUE  TRUE  TRUE FALSE

 I.e. testCoreNA is never tested by check_codoc. There may of course be
 a rationale for this, but it escapes me...

Well, I am sure I had good reasons when I wrote the code many years ago,
but of course I no longer recall what they were.

Did you try the effect of removing the length(formals(f)) test?

-k


 -- 
 O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
   (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
 ~~ - (p.dalga...@biostat.ku.dk)  FAX: (+45) 35327907

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

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

Re: [Rd] error message when running news()

[Kurt Hornik]

 Duncan Murdoch writes:

 On 22/11/2009 7:34 AM, Gabor Grothendieck wrote:
 When running news() in I get this error message from print.news_db:
 
 news()
 Error: invalid version specification 2.0.12.0.1 patched2.1.02.1.12.1.1
 patched2.10.02.10.0 patched2.2.02.2.12.2.1 patched2.3.02.3.12.3.1
 patched2.4.02.4.12.4.1 patched2.5.02.5.12.5.1
 patched2.6.02.6.12.6.22.6.2 patched2.7.02.7.12.7.22.7.2
 patched2.8.02.8.12.8.1 patched2.9.02.9.12.9.22.9.2 patched
 R.version.string
 [1] R version 2.10.0 Patched (2009-11-21 r50532)


 This is also present in R-devel.  It's an error in utils:::print.news_db.

 The problem is that versions like 2.0.1 patched can't be converted to 
 numeric versions, but print.news_db tries to do it to sort the entries. 
   The repetitive message is just a bad error message from 
 .make_numeric_version.

 Presumably the intention is that 2.0.1 patched should compare bigger 
 than 2.0.1 and less than 2.0.2, but I don't know the best fix for this.

 Duncan Murdoch

I'll have a look.

-k

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