Re: [R-pkg-devel] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update

[Martin Maechler]

>>>>> Tim Taylor 
>>>>> on Wed, 10 Apr 2024 10:37:00 +0100 writes:

> Hi Mikael Revisiting this. Have the plans changed for
> 1.7-0 release?

> Tim

Yes.  Matrix 1.7-0 *has* been on CRAN now for while
(i.e. 'March' has remained as announced), *but*
-- because of the ABI change and the problem it can cause for
   *some* users --

we have made it  'Depends: R (>= 4.4.0)'
i.e., you *see* the new Matrix only once you use R 4.4.0
which has been available as "alpha" already and is now in
"beta" already, e.g.,

  R version 4.4.0 beta (2024-04-10 r86393) -- "Puppy Cup"


Best regards,
Martin

--
Martin Maechler
ETH Zurich  and  R Core Team


> On Mon, 12 Feb 2024, at 6:36 PM, Mikael Jagan wrote:
>> Dear users and binary repository maintainers,
>> 
>> We are preparing Matrix version 1.7-0 for CRAN submission
>> on March 11, ahead of the spring release of R version
>> 4.4.0.  The only significant change from Matrix 1.6-5 is
>> an update of the internal SuiteSparse libraries (5.10.1
>> -> 7.6.0).  Unfortunately, the old and new SuiteSparse
>> versions are binary incompatible, hence so too will be
>> the old and new Matrix versions.
>> 
>> A corollary is that users and binary repository
>> maintainers switching between Matrix < 1.7-0 and Matrix
>> >= 1.7-0 must rebuild _from sources_ packages that link
>> Matrix:
>> 
>> > tools::package_dependencies("Matrix", which =
>> "LinkingTo", reverse = TRUE)[[1L]] [1] "ahMLE"
>> "bayesWatch" "cplm" [4] "GeneralizedWendland" "geostatsp"
>> "irlba" [7] "lme4" "mcmcsae" "OpenMx" [10] "PRIMME"
>> "PUlasso" "robustlmm" [13] "spGARCH" "TMB" "bcSeq"
>> 
>> For users, that means doing, e.g.,
>> 
>> install.packages("lme4", type = "source")
>> 
>> but an alternative for Windows and macOS users without
>> the required tools is
>> 
>> oo <- options(repos = "https://cran.r-project.org/;)
>> install.packages("Matrix") install.packages("lme4")
>> options(oo)
>> 
>> where we trust CRAN to provide binaries compatible with
>> the latest Matrix version (because we notify CRAN upon
>> submission about required rebuilds).  Once other
>> repositories react with rebuilds, they can be used
>> instead of CRAN.
>> 
>> Our reverse dependency checks (and history, intuition,
>> ...) show that most problems (caught segfaults in this
>> case) can be traced to a binary incompatible lme4 and not
>> to one of the other packages linking Matrix.  Still, we
>> recommend rebuilds for all 15 packages.
>> 
>> Maintainers of packages that link Matrix can implement an
>> .onLoad test for possible binary incompatibility by
>> comparing the value of
>> 
>> if (utils::packageVersion("Matrix") >= "1.6.2")
>> Matrix::Matrix.Version()[["abi"]] else
>> numeric_version("0")
>> 
>> at install time and at load time, warning the user if the
>> values differ.  But please do look at the above and not
>> at packageVersion("Matrix") directly, as the ABI version
>> is incremented less often than the package version.
>> 
>> Mikael {on behalf of citation("Matrix")$author}
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 

>   [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Martin Maechler]

> Duncan Murdoch 
> on Thu, 7 Mar 2024 05:08:40 -0500 writes:

> On 07/03/2024 4:16 a.m., Ivan Krylov wrote:
>> On Wed, 6 Mar 2024 13:46:55 -0500 Duncan Murdoch
>>  wrote:
>> 
>>> is this just a more or less harmless error, thinking
>>> that the dot needs escaping
>> 
>> I think it's this one. You are absolutely right that the
>> dot doesn't need escaping in either TRE (which is what's
>> used inside exportPattern) or PCRE. In PRCE, this regular
>> expression would have worked as intended:
>> 
>> # We do match backslashes by mistake.  grepl('[\\.]',
>> '\\') # [1] TRUE
>> 
>> # In PCRE, this wouldn't have been a mistake.
>> grepl('[\\.]', c('\\', '.'), perl = TRUE) # [1] FALSE
>> TRUE
>> 

> Thanks, I didn't realize that escaping in PCRE was
> optional.

> So the default exportPattern line could be

>exportPattern("^[^.]")

> and it would work even if things were changed so that PCRE
> was used instead of TRE.

> Duncan Murdoch

Yes, thank you, Duncan!
.. I had started changing to this much easier pattern already
before reading on ...  -->  in R-devel; now also with "doc"s (NEWS.Rd, 
R-exts.texi)

Martin

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

Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Martin Maechler]

> Richard M Heiberger 
> on Wed, 6 Mar 2024 17:10:50 + writes:

> Thank you, I will do that reversion in a few days.

(good; I'm sorry I did not see this, before I replied to Joshua's)

> Before I do, I want to ask if the default export generated by R CMD build 
should be changed.
> the default is  exportPattern("."), which seems to be the cause of the 
problem.
> Might the default be changed to exportPattern("^[^\\.]") ?

That's a good suggestion in my view.
That default *was* sensible when namespaces were
introduced (~ 2004?): It did indeed ensure that the package worked
entirely as before there were namespaces -- always everything
was "exported", i.e. publicly visible and part of the implicit
package API.

And such 100%-backcompatibility was of course sensible to ease
transition. But we are ca. 20 years later now, and I guess that
most active R users (incl package developers) either don't know
or then hardly remember that R had no namespaces originally.

I see it only in the tools pkg hidden  writeDefaultNamespace()
which is used only once in tools:::.build_packages()

## add NAMESPACE if the author didn't write one
if(!file.exists(namespace <- file.path(pkgname, "NAMESPACE")) ) {
messageLog(Log, "creating default NAMESPACE file")
writeDefaultNamespace(namespace)
}

Note that the "Bible" on R packages has always been
'Writing R Extensions' - in the R sources,  doc/manual/R-exts.texi

It has -- *since* svn rev 23392,  003-02-27 19:02:45 +0100 
  by Luke Tierney and commit message
  "Added name space support for packages that do not use methods."

the text, e.g., at
  
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports

>For packages with many variables to export it may be more convenient
> to specify the names to export with a regular expression using
> ‘exportPattern’.  The directive

>  exportPattern("^[^\\.]")

> exports all variables that do not start with a period.  However, such
> broad patterns are not recommended for production code: it is better to
> list all exports or use narrowly-defined groups.  .

so I agree we should change the default.
The R code above shows that the user does get a message about
automatic NAMESPACE creation.

If there are cases, where people need to export even .,
they should have to consciously choose so.

Martin




>> On Mar 6, 2024, at 11:57, Joshua Ulrich  wrote:
>> 
>> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger  
wrote:
>>> 
>>> Thank you Duncan, Jeff, Ivan.
>>> 
>>> I did all that Duncan and Jeff suggested, plus a bit more that appeared 
to be necessary.
>>> All of what I did is documented in the RcmdrPlugin.HH/NEWS file.
>>> 
>>> Ivan's comments were received after I sent 1.1-50 to CRAN and it was 
accepted.
>>> 
>> I recommend you revert all the changes you made that are documented in
>> the package NEWS, and at minimum follow Ivan's advice to use
>> exportPattern("^[^\\.]") instead of exportPattern("."). It would be
>> even better to follow the advice in Writing R Extensions and list each
>> exported object individually.
>> 
>>> I suggest that my notes in the NEWS file, perhaps augmented with Ivan's 
comments,
>>> might be added to utils/man/globalVariables.Rd and to the
>>> "
>>> section ‘Package
>>> structure’ in the ‘Writing R Extensions’ manual.
>>> "
>>> 
>> That section of Writing R Extensions specifically says not to do what 
you did.
>> 
>> Beware of patterns which include names starting with a period: some
>> of these are internal-only variables and should never be exported,
>> e.g. ‘.__S3MethodsTable__.’ (and loading excludes known cases).
>> 
>> Duncan pointed out that '.__global__' is an internal-only variable
>> created by globalVariables(), which means it should never be exported
>> by a package. Imagine the number of conflicts there would be if every
>> package that used globalVariables() exported the '.__global__'
>> object... there would probably be thousands, yikes!
>> 
>> It's possible that future versions of 'R CMD check' will error if
>> there are any incorrectly exported internal variables (like
>> '.__global__'), which would cause your package to fail.
>> 
>> Best,
>> Josh
>> 
>> 
>>> 
 On Mar 6, 2024, at 01:38, Ivan Krylov  wrote:
 
 В Tue, 5 Mar 2024 22:41:32 +
 "Richard M. Heiberger"  пишет:
 
> Undocumented code objects:
> '.__global__'
> All user-level objects in a package should have documentation
> entries. See chapter 'Writing R documentation files' in the 'Writing R
> Extensions' manual.
 
 This object is not here for the user of the package. If you don't
 export it, there will be no WARNING about it 

Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Martin Maechler]

> Joshua Ulrich 
> on Wed, 6 Mar 2024 10:57:28 -0600 writes:

> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger
>  wrote:
>> 
>> Thank you Duncan, Jeff, Ivan.
>> 
>> I did all that Duncan and Jeff suggested, plus a bit more
>> that appeared to be necessary.  All of what I did is
>> documented in the RcmdrPlugin.HH/NEWS file.
>> 
>> Ivan's comments were received after I sent 1.1-50 to CRAN
>> and it was accepted.
>> 
> I recommend you revert all the changes you made that are
> documented in the package NEWS, and at minimum follow
> Ivan's advice to use exportPattern("^[^\\.]") instead of
> exportPattern("."). It would be even better to follow the
> advice in Writing R Extensions and list each exported
> object individually.

I agree: at least use   exportPattern("^[^\\.]")
instead of the 'very un-recommended' (.)  which -- as Ivan
mentioned -- does export *everything* --
entirely destroying one important advantage of namespaces,
namely to have "private" auxiliary functions/objects/data .

Martin

>> I suggest that my notes in the NEWS file, perhaps
>> augmented with Ivan's comments, might be added to
>> utils/man/globalVariables.Rd and to the " section
>> ‘Package structure’ in the ‘Writing R Extensions’ manual.
>> "
>> 
> That section of Writing R Extensions specifically says not
> to do what you did.

> Beware of patterns which include names starting with a
> period: some of these are internal-only variables and
> should never be exported, e.g. ‘.__S3MethodsTable__.’ (and
> loading excludes known cases).

> Duncan pointed out that '.__global__' is an internal-only
> variable created by globalVariables(), which means it
> should never be exported by a package. Imagine the number
> of conflicts there would be if every package that used
> globalVariables() exported the '.__global__'
> object... there would probably be thousands, yikes!

> It's possible that future versions of 'R CMD check' will
> error if there are any incorrectly exported internal
> variables (like '.__global__'), which would cause your
> package to fail.

> Best, Josh


>> 
>> > On Mar 6, 2024, at 01:38, Ivan Krylov
>>  wrote:
>> >
>> > В Tue, 5 Mar 2024 22:41:32 + > "Richard
>> M. Heiberger"  пишет:
>> >
>> >> Undocumented code objects: >> '.__global__' >> All
>> user-level objects in a package should have documentation
>> >> entries. See chapter 'Writing R documentation files'
>> in the 'Writing R >> Extensions' manual.
>> >
>> > This object is not here for the user of the package. If
>> you don't > export it, there will be no WARNING about it
>> being undocumented. This > variable is exported because
>> of exportPattern(".") in the file > NAMESPACE. The lone
>> dot is a regular expression that matches any name > of an
>> R object.
>> >
>> > If you don't want to manually list your exports in the
>> NAMESPACE file > (which can get tedious) or generate it
>> (which takes additional > dependencies and build steps),
>> you can use exportPattern('^[^\\.]') to > export
>> everything except objects with a name starting with a
>> period: >
>> 
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
>> >
>> > --
>> > Best regards, > Ivan
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel



> --
> Joshua Ulrich | about.me/joshuaulrich FOSS Trading |
> www.fosstrading.com

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

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

[R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Martin Maechler]

>>>>> McGrath, Justin M 
>>>>> on Tue, 12 Dec 2023 15:03:28 + writes:

> We include other software in our source code. It has some long paths so a 
few of the files end up with paths longer than 100 bytes, and we need to 
manually rename them whenever we pull in updates.
> The 100 byte path limit is from tar v7, and since
> POSIX1.1988, there has not been a path length limit. That
> standard is 35 years old now, so given that there is
> probably no one using an old version of tar that also
> wants to use the latest version of R, could the 100 byte
> limit be lifted? Incidentally, I am a big proponent of
> wide, long-term support, but it's hard to see that this
> change would negatively impact anyone.

> Best wishes,
> Justin

Wrong mailing list:

This is a topic for R-devel,  not at all R-package-devel,
but be more accurate in what you are talking about, only between
the line I could read that it is about some variants of using
'tar'.

Best regards,
Martin
---

Martin Maechler
ETH Zurich  and  R Core team

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

Re: [R-pkg-devel] Check warning around sprintf: Compiled code should not call entry points which might terminate R nor write to stdout/stderr instead of to the console, nor use Fortran I/O nor system

[Martin Maechler]

> Serguei Sokol 
> on Mon, 20 Nov 2023 10:04:10 +0100 writes:

> Le 19/11/2023 à 02:07, Iris Simmons a écrit :
>> Yes, the reason for the error is the use of sprintf. You can instead use
>> snprintf where n is the maximum number of bytes to write, including the
>> terminating nul character. For example:
>> 
>> char msg[8191];
>> snprintf(msg, 8191, "criteria: error (%d) -> %s\n", inErr, errStr);
> This line should be

> snprintf(msg, 8190, "criteria: error (%d) -> %s\n", inErr, errStr);

> i.e. 1-less than 'msg' size, leaving a room for the terminal 0-byte.
> Otherwise, a recent version of gcc emits a warning caught by CRAN.

> Best,
> Serguei.

Yes, indeed  ' - 1 ',

but really  Iago(and everyone else!) should in such cases
use the much nicer and easier code that  Ivan Krylov proposed
yesterday :

   Rf_error("criteria: error (%d) -> %s", inErr, errStr);

with *no* need of declaring a `msg` buffer and thinking about
its size.

Martin

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

Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[Martin Maechler]

Dear R-package-devel readers *and* notably writers,

In Europe there are (diverse) laws about privacy etc, and those,
(and/or some politeness) do not allow
free citing of private e-mail communications in public
nor ad hominem remarks in such public communication.

For this reason, I (as mailing list co-maintainer, and notably
responsible for the lawfulness of the public mailing list archives on
our web server) now spent about 2 hours  to carefully obey such
privacy requirements (carefully editing + recreating all the html archives).
{In another similar case, my employer, ETH Zurich, did urge me
"from above" to spend my time with such a tedious and ungratifying job ...}
This is *NOT* something I'd be happy to redo.

So *please* do not misuse such a public mailing list and do keep
your private opinions private in such a case in the future!

>>>>> Spencer Graves  on Thu, 2 Nov 2023 15:29:29 -0500 writes:

> On 11/2/23 2:52 PM, Rolf Turner wrote:
>> 
>> On Wed, 1 Nov 2023 16:10:34 + David Hugh-Jones wrote:
>> 
>>> Aside from the package question, surely the other issue
>>> here is that ’s email is extraordinarily
>>> rude. Any paid employee would be sacked for that. I
>>> appreciate R and CRAN are volunteer-run organisations,
>>> but I don’t think that should be an excuse for this
>>> level of, frankly, toxicity. Why is he allowed to get
>>> away with it?
>>> 
>>> David

>> 
>> I've just had a look at the initial posting in this
>> thread
>>
>> and can see nothing rude or offensive in the email
>> that was copied and pasted into that  posting.
>> 
>> I find *your* email far more offensive than anything that
>>  has ever written.  Get a life.
>> 
>> cheers,
>> 
>> Rolf Turner
>> 
>> P.S.  See fortunes::fortune(88).
>> 
>> R. T.


> Hi, David:


[]


> I've been in the military, and I've learned to ignore
> the tone and look for the value in comments I
> receive. I've learned a lot from , and
> others. When the tone seemed less supportive or even
> insulting, I'm very glad the person took the time to
> comment and didn't decide not to reply for fear of
> offending me. I'm more productive and a better human for
> all the help I've gotten from this and other R-related
> lists.


> fortunes::fortune('Spencer Graves')

which can you get 4 different answers; using `showMatches` argument
(which I think I had added), e.g. now gives

> fortune("Spencer Graves", showMatches = TRUE)
Matching row numbers: 90, 124, 177, 271 

Rolf Turner: In the middle of a Saturday morning (in my Time Zone!) I send out 
a plea for help, and in
just over 20 minutes my problem is solved!
I don't think you get service like that anywhere else. This R-help list is 
BLOODY AMAZING!
Spencer Graves: 'The sun never sets on the (former) British Empire.' Today, it 
never sets on R-Help.
   -- Rolf Turner and Spencer Graves
  R-help (May 2005)

and then

> fortune(90)

Our great-great grandchildren as yet unborn may read some of the stupid 
questions and/or answers that I
and perhaps others give from time to time. I'd rather get flamed for saying 
something stupid in public on
this list than to continue to provide substandard service to the people with 
whom I work because I
perpetrated the same mistake in an environment in which no one questioned so 
effectively my errors.
   -- Spencer Graves (in a discussion on whether answers on R-help should be 
more polite)
  R-help (December 2004)

> sg

Martin


--
Martin Maechler
ETH Zurich  and  R Core team

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

Re: [R-pkg-devel] Matrix and Mac OS

[Martin Maechler]

> Uwe Ligges 
> on Wed, 1 Nov 2023 06:26:23 +0100 writes:

> On 01.11.2023 03:51, Mikael Jagan wrote:
>> Thanks.  It seems that we were mistaken in our feeling (IIRC) that it 
would
>> be "OK" to implicitly require '--no-manual' on versions of R from 3.5.0 
to
>> 4.2.1, not changing our Depends.
>> 
>> We will fix this in Matrix 1.6-2, probably by conditionalizing or 
otherwise
>> replacing the amsmath commands and probably _not_ by changing to depend 
on
>> R >= 4.2.2.  Martin may have more to say in "the morning".

I agree (*not* to raise Matrix pkg's R version dependency).

> Note that dependin on R >= 4.2.2 does not work. We need dependencies of 
> the form R >= x.y.0. This is also part of the checks.

Yes, indeed.
And as we learned, R >= 4.2.0 would not help for r-oldrel-macos

I (am unhappy but) agree to take the responsibility for our
decision to go ahead and use much nicer LaTeX formula for
matrices etc, in our help pages {thinking that indeed people who'd
install Matrix on an old R version would always be able to read
Matrix manual pages via web search (as it seems to me 95% of
people do nowadays) ... or then have someone in their
organization to figure out how to use a newer amsmath (latex) package if
 they really really want the Matrix pdf manual offline}.

Martin

> Reason is that we have only one binary repository for one R-x.y.? 
> series. On WIndows, where we check with R-4.2.3, a binary would be 
> created and hence R-4.2.[0-1] would not see any valid Matrix binaries.

> So please either make this work on R >= 4.2.0 or require R >= 4.3.0. If 
> the latter, ideally with an interim version that works for R >= 4.2.0, 
> so that we valid binaries with correct dependency declarations again.

> Best,
> Uwe

>> In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may 
>> help
>> to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey revert 
its
>> strict version requirement, unless there are clear examples justifying 
one.
>> 
>> Mikael
>> 
>> 
>> On 2023-10-31 8:17 pm, Simon Urbanek wrote:
>>> Mikael,
>>> 
>>> in that case I think your requirements are wrong - Matrix says R >= 
>>> 3.5.0 which is apparently incorrect - from what you say it should be 
>>> 4.2.2?. I can certainly update to 4.2.3 if necessary.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
>>> 
 On 1/11/2023, at 9:19 AM, Mikael Jagan  wrote:
 
 Thanks.  We did see those ERRORs, stemming from use (since Matrix 
1.6-0)
 of amsmath commands in Rd files.  These have been supported since R 
 4.2.2,
 but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R 
 4.2.0.
 My expectation was that those machines would begin running R >= 4.2.2 
 well
 before the R 4.4.0 release, but apparently that was wrong.
 
 I am hesitant to complicate our Rd files with conditions on R versions
 only to support PDF output for R < 4.2.2, but maybe we can consider it
 for the Matrix 1.6-2 release if it is really a barrier for others ...
 
 Mikael
 
 On 2023-10-31 3:33 pm, Simon Urbanek wrote:
> Mikael,
> current Matrix fails checks on R-oldrel so that's why only the last 
> working version is installed:
> https://cran.r-project.org/web/checks/check_results_Matrix.html
> Cheers,
> Simon
> On 1/11/2023, at 4:05 AM, Mikael Jagan  wrote:
>> 
> I am guessing that they mean EdSurvey:
>> 
>     https://cran.r-project.org/web/checks/check_results_EdSurvey.html
>> 
> Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64,
> even though it can be, because it was not released until R 4.3-z.
>> 
> AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and
> even those changes should have been backwards compatible, modulo 
> handling
> of dimnames (class sparseQR gained a Dimnames slot in 1.6-0).
>> 
> So I don't see a clear reason for requiring 1.6-1.1.  Requiring 1.6-0
> might make sense, if somehow EdSurvey depends on how class sparseQR
> preserves dimnames.  But IIRC our rev. dep. checks at that time did 
> not
> reveal problems with EdSurvey.
>> 
> Mikael
>> 
> On 2023-10-31 7:00 am, r-package-devel-requ...@r-project.org wrote:
>>> Paul,
>>> can you give us a bit more detail? Which package, which build and 
>>> where you got the errors? Older builds may not have the latest 
>>> Matrix.
>>> Cheers,
>>> Simon
 On 31/10/2023, at 11:26 AM, Bailey, Paul via 
 R-package-devel  wrote:
 
 Hi,
 
 I'm the maintainer for a few packages, one of which 

Re: [R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently

[Martin Maechler]

>>>>> Henrik Bengtsson 
>>>>> on Sat, 14 Oct 2023 10:37:14 -0700 writes:

> On Sat, Oct 14, 2023 at 5:25 AM Martin Maechler
>  wrote:
>> 
>> >>>>> Ivan Krylov
>> >>>>> on Thu, 12 Oct 2023 18:50:30 +0300 writes:
>> 
>> > On Thu, 12 Oct 2023 11:32:24 -0400
>> > Mikael Jagan  wrote:
>> 
>> >> > mk <- file.path(R.home("share"), "make", "vars.mk")
>> >> > pp <- sub("^.*= +", "", grep("^R_PKGS_RECOMMENDED",
>> >> > readLines(mk), value = TRUE))
>> >> > sort(strsplit(pp, " ")[[1L]])
>> >> [1] "KernSmooth" "MASS"   "Matrix" "boot"   "class"
>> >> [6] "cluster""codetools"  "foreign""lattice""mgcv"
>> >> [11] "nlme"   "nnet"   "rpart"  "spatial" "survival"
>> >>
>> >> I grepped around and did not find variables in any base namespace
>> >> containing the names of these packages.  It wouldn't be too hard to
>> >> define such variables when R is configured/built, but maybe there are
>> >> "reasons" to not do that ... ?
>> 
>> > tools:::.get_standard_package_names does that at package installation
>> > time, but it's still not public API.
>> 
>> Within R-core, we have somewhat discussed this, and a few
>> minutes ago I committed a "public API" version of the above,
>> called
>> standard_package_names()
>> 
>> to R-devel (svn rev 85329), and hence probably in next year's
>> April release of R.

> Excellent. Will it be supported on all OSes?  Because, there's
> currently a source code comment saying the current implementation
> might not work on MS Windows:

> ## we cannot assume that file.path(R.home("share"), "make", "vars.mk")
> ## is installed, as it is not on Windows

Well, it does work nowadays on Windows {just checked}.
So the comment should probably be removed.

{{ I'm definitely not the expert, but AFAIK, the Windows
   installation of R has become considerably closer to the other platform
   ones, recently }}


> standard_package_names <-
> .get_standard_package_names <-
> local({
> lines <- readLines(file.path(R.home("share"), "make", "vars.mk"))
> lines <- grep("^R_PKGS_[[:upper:]]+ *=", lines, value = TRUE)
> out <- strsplit(sub("^R_PKGS_[[:upper:]]+ *= *", "", lines), " +")
> names(out) <-
> tolower(sub("^R_PKGS_([[:upper:]]+) *=.*", "\\1", lines))
> eval(substitute(function() {out}, list(out=out)), envir = topenv())
> })

> /Henrik

>> 
>> 
>> > A call to installed.packages() may take a long while because it has to
>> > list files in every library (some of which can be large and/or
>> > network-mounted) and parse each Meta/package.rds file, but at least
>> > list.files() is faster than that.
>> 
>> The above is another issue that we've wanted to improve, as some
>> of you are aware,  notably thinking about caching the result
>> .. there has been work on this during the R Sprint @ Warwick a
>> couple of weeks ago,
>> 
>> ==> https://github.com/r-devel/r-project-sprint-2023/issues/78
>> 
>> involving smart people and promising proposals (my personal view).
>> 
>> > If I had to make a choice at this point, I would hard-code the list of
>> > packages, but a better option may surface once we know what Tony needs
>> > the package lists for.
>> 
>> > --
>> > Best regards,
>> > Ivan
>> 
>> 
>> With thanks to the discussants here on R-devel,
>> and best regards,
>> Martin
>> 
>> --
>> Martin Maechler
>> ETH Zurich  and  R Core team
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently

[Martin Maechler]

>>>>> Ivan Krylov 
>>>>> on Thu, 12 Oct 2023 18:50:30 +0300 writes:

> On Thu, 12 Oct 2023 11:32:24 -0400
> Mikael Jagan  wrote:

>> > mk <- file.path(R.home("share"), "make", "vars.mk")
>> > pp <- sub("^.*= +", "", grep("^R_PKGS_RECOMMENDED",
>> > readLines(mk), value = TRUE))
>> > sort(strsplit(pp, " ")[[1L]])  
>> [1] "KernSmooth" "MASS"   "Matrix" "boot"   "class"
>> [6] "cluster""codetools"  "foreign""lattice""mgcv"
>> [11] "nlme"   "nnet"   "rpart"  "spatial" "survival"
>> 
>> I grepped around and did not find variables in any base namespace
>> containing the names of these packages.  It wouldn't be too hard to
>> define such variables when R is configured/built, but maybe there are
>> "reasons" to not do that ... ?

> tools:::.get_standard_package_names does that at package installation
> time, but it's still not public API.

Within R-core, we have somewhat discussed this, and a few
minutes ago I committed a "public API" version of the above,
called
   standard_package_names()

to R-devel (svn rev 85329), and hence probably in next year's
April release of R.


> A call to installed.packages() may take a long while because it has to
> list files in every library (some of which can be large and/or
> network-mounted) and parse each Meta/package.rds file, but at least
> list.files() is faster than that.

The above is another issue that we've wanted to improve, as some
of you are aware,  notably thinking about caching the result
.. there has been work on this during the R Sprint @ Warwick a
couple of weeks ago,

 ==> https://github.com/r-devel/r-project-sprint-2023/issues/78

involving smart people and promising proposals (my personal view).

  > If I had to make a choice at this point, I would hard-code the list of
  > packages, but a better option may surface once we know what Tony needs
  > the package lists for.

  > -- 
  > Best regards,
  > Ivan


With thanks to the discussants here on R-devel,
and best regards,
Martin

--
Martin Maechler
ETH Zurich  and  R Core team

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

Re: [R-pkg-devel] Question about Clang 17 Error

[Martin Maechler]

> Reed A Cartwright 
> on Wed, 11 Oct 2023 22:25:35 -0700 writes:

> Okay, I'll reach out to the CRAN team shortly.
> I wanted to run it by the group here first because my interactions with 
the
> CRAN team haven't always been positive and I need to make sure that I'm 
not
> missing something "obvious".

well..  one thing not enough obvious:  Simon Urbanek _is_
part of the CRAN team (*).   So at least you had a positive
interaction with "them", now ! ;-)

---
*) https://cran.r-project.org/CRAN_team.htm
  (which is the *first* hit when I web search "CRAN team" {with
  DuckDuckGo, a reasonable non-prying Google-alternative I})


Best,
Martin


> On Wed, Oct 11, 2023, 22:22 Simon Urbanek 
> wrote:

>> Reed,
>> 
>> please contact CRAN - this list can only help with general developer's
>> questions, not specific issues with a particular CRAN setup - only the
>> corresponding member of CRAN running the setup can help. I don't see
>> anything obvious - we can see that it's a mismatch of run-times between 
the
>> cmake build and the R linking, but from the package alone it's not clear 
to
>> me why.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> On Oct 12, 2023, at 3:51 PM, Reed A. Cartwright 
>> wrote:
>> 
>> Update: I submitted a new version of the package, but it did not fix the
>> issue. The package has now been archived and I do not have access to the
>> error log output anymore from r-devel-linux-x86_64-fedora-clang.
>> 
>> I did reproduce CRAN's configuration in a VM using the information
>> provided by CRAN for r-devel-linux-x86_64-fedora-clang. I still cannot
>> reproduce the error and at this point I believe that there is a chance 
that
>> CRAN's machine is misconfigured.
>> 
>> The specific error happens after rbedrock has been compiled and linked
>> successfully. The specific error is that the symbol
>> _ZNSt3__122__libcpp_verbose_abortEPKcz cannot be found when rbedrock.so 
is
>> loaded.This symbol was introduced into libc++ in Clang 15.0. What I 
believe
>> to be happening to cause the error is that Clang++ 17 is adding a 
reference
>> to this symbol when compiling and linking rbedrock.so but the dynamic
>> linker is loading an older version of libc++.so when trying to load
>> rbedrock.so and the symbol is not found.
>> 
>> If this is the cause, then I think that the CRAN machine needs to
>> configure the dynamic linker to use the Clang++ 17 libc++.so, or add the
>> proper command line options to R's config variables.
>> 
>> It's possible that the CRAN's r-devel-linux-x86_64-fedora-clang machine 
is
>> fine and I've missed something, and I would be happy if someone could 
help
>> me figure out what it is.
>> 
>> Also, a new issue cropped up when 0.3.1 was tested on the
>> r-oldrel-macos-x86_64 machine. /usr/bin/ar seems to have failed to 
produce
>> an archive. The other Mac versions did fine, so I'm not sure if this is a
>> random error or something related to my package. The error log is here:
>> 
https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/rbedrock-00install.html
>> 

>> 
>> If anyone can help me resolve this, I'd appreciate it.
>> 
>> 
>> On Wed, Sep 27, 2023 at 2:54 PM Reed A. Cartwright 

>> wrote:
>> 
>>> Is there any way to submit packages directly to the CRAN's clang17 
setup?
>>> I can enable verbose output for CMake and compare the output, but I'd
>>> rather not clog up the CRAN incoming queue just to debug a linker error?
>>> 
>>> On Wed, Sep 27, 2023 at 2:43 PM Simon Urbanek <
>>> simon.urba...@r-project.org> wrote:
>>> 
 It looks like a C++ run-time mismatch between what cmake is using to
 build the static library and what is used by R. Unfortunately, cmake 
hides
 the actual compiler calls so it's hard to tell the difference, but that
 setup relies on the correct sequence of library paths.
 
 The rhub manually forces -stdlib=libc++ to all its CXX flags
 
 
https://urldefense.com/v3/__https://github.com/r-hub/rhub-linux-builders/blob/master/fedora-clang-devel/Makevars__;!!IKRxdwAv5BmarQ!bAZgiOQaK4hd5BTk_Ldx9IEHgzHKVbC-uMkvYv5GOVkZDvbedcGwS8dQ4MWXRjukFfds7UpiR9NDZfEoUCWeoVnCfrDa$
 so it is quite different from the gannet tests-clang-trunk setup (also
 note the different library paths), but that's not something you can do
 universally in the package, because it strongly depends on the 
toolchain
 setup.
 
 Cheers,
 Simon
 
 
 > On 

Re: [R-pkg-devel] [Rd] is.atomic(NULL) will become FALSE

[Martin Maechler]

I've sent a longish post to the R-devel mailing list with this
topic here:
https://stat.ethz.ch/pipermail/r-devel/2023-September/082892.html

In the mean time, the plan is to effectuate the change in
R-devel (the in-development version of R) on Sep.28, ~ 9:30 CEST ( =UTC+2)

Martin

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

Re: [R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?

[Martin Maechler]

>>>>> Hiroaki Yutani 
>>>>> on Mon, 10 Jul 2023 17:24:37 +0900 writes:

[...]

Short answer to your questsion (from the 'Subject') is :NO !
For an example, see below:

> libR-sys assumes the path to R's shared libraries is
> `${R_HOME}/lib` on Unix-alike platforms.

In some configurations, R does not need *any* shared libraries,
and there,  $R_HOME/lib  does *not* exist.

E.g., I have one of my R-devel versions installed (on Fedora
Linux) with

../R/configure --with-blas=-lflexiblas 

using the nice, currently Fedora/Redhat-only "flexiblas"
approach, with which I can nicely switch the versions of BLAS
and Lapack libraries that R works with from within R.

As that version of R is not "shared", i.e., no libR.so , *and*
gets both its BLAS and Lapack libraries from "external" (not
from R), there's no need for a ./lib/  and so none is created.

Martin Maechler
ETH Zurich  and  R Core Team


> Is it possible
> that this path doesn't exist on the MKL server? 

> Actually, it compiles fine on the other Linux platforms,
> so I'm wondering what's different there from the other
> servers.


> Best, Yutani
>   [[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Warning 'as.data.frame.POSIXct()' is deprecated

[Martin Maechler]

>>>>> Tim Taylor 
>>>>> on Thu, 6 Jul 2023 15:11:41 +0100 writes:

> Ah yes ... and reading the as.data.frame help we see (emphasis mine):
> "... Direct calls to as.data.frame.() are still possible (*base 
> package!*), for 12 atomic base classes, but will deprecated ..."

> So it does seem that a lot of these warnings are triggered by base R and 
> updating this code may be a work in progress.


> A little tangential (but related) to this though is still the fact that 
> we can trigger the warning with:

> lapply(Sys.Date(), as.data.frame)

> so I wonder if the code in base/R/zzz.R 
> 
(https://github.com/wch/r-source/blob/9f1940663f902174034a01197e55fd17c767213a/src/library/base/R/zzz.R#L664-L686)
 
> does need tweaking?

> At this stage this is probably more a question for R-devel though.

Indeed. ... and so I've sent a long reply to you, Enrico,
Vincent *AND* the R-devel mailing list.  In its archives you see it here

 https://stat.ethz.ch/pipermail/r-devel/2023-July/082725.html

With thanks to Vincent, Tim, Enrico, (and Mikael who started
"moving" this to R-devel, see there).

Martin

--
Martin Maechler
ETH Zurich   and   R Core team

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

Re: [R-pkg-devel] help fixing CRAN package sos-now fails on GitHub

[Martin Maechler]

> Duncan Murdoch 
> on Mon, 22 May 2023 15:38:10 -0400 writes:

> On 22/05/2023 3:07 p.m., Ivan Krylov wrote:
>> I fed your vignette to R CMD Sweave, and here's the
>> relevant fragment from the resulting *.tex file:
>> 
>>> This returned a {\tt "findFn"} object identifying 405
>>> help pages.  When this was run while preparing this
>>> manuscript, the sixth row was {\tt pspline_checker} in
>>> the \pkg{JOPS} package, which has a {\tt Score} of
>>> 47. (On another day, the results could be different,
>>> because CRAN changes over time.)  This was the sixth row
>>> in this table, because it is in the \pkg{JOPS} package,
>>> which had a total of 54 help pages matching the search
>>> term, but this was the only one whose name matched the
>>> {\tt pattern} passed to {\tt grepFn}.
>> 
>> This corresponds to the following part of the vignette:
>> 
>>> This returned a {\tt "findFn"} object identifying
>>> \Sexpr{nrow(g)} help pages.  When this was run while
>>> preparing this manuscript, the sixth row was {\tt
>>> \Sexpr{gFunc6}} in the \pkg{\Sexpr{gPac6}} package,
>>> which has a {\tt Score} of \Sexpr{gScore6}.
>> 
>> So, you need to escape the underscores in
>> gFunc6. Probably not gPac6 because underscores are not
>> allowed in package names.
>> 

> Nice find.  Just in case Spencer has trouble with escaping
> the escapes, I think he should change

>"{\tt \Sexpr{gFunc6}}"

> to

>"{\tt \Sexpr{sub("_", "_", gFunc6)}}

> Even better would be to write a little function
> "sanitizeForLatex" that did this and any other necessary
> changes, and call that.

Yes, indeed (2 x).

If I grep the base R package sources, I find three occurrences
of something like the above:

grep --color -nH --null -e 'sub *(.*_' */R/*.R

 tools/R/Rd2latex.R:295:x <- fsub("\\_", "_", x)
 tools/R/Rd2latex.R:303:x <- fsub("\\_", ".Rul.", x)
 tools/R/Rd.R:681:txt <- gsub("\\_", "_", txt, fixed=TRUE)

all of which do the transformation in the other direction
(because *.Rd in those cases already *is* LaTeX-alike, and needs
 to convert for non-LaTeX use).

Note that the last one gives a hint to be more general --- gsub()
also working a.g. for 'parse_me_not' ---
*and* possibly faster (fixed=TRUE)  leading to

 "{\tt \Sexpr{gsub("_", "_", gFunc6, fixed=TRUE)}}

Martin

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

Re: [R-pkg-devel] Intrinsic UTF-8 use in aspired CRAN package

[Martin Maechler]

> Schuhmacher, Dominic 
> on Wed, 17 May 2023 12:05:49 + writes:

> Dear list, I have a package
> https://github.com/dschuhmacher/kanjistat whose very
> purpose depends on working with Japanese kanji characters
> (in UTF-8 encoding). Such characters appear vitally in the
> data sets, examples, tests, the vignette and the .Rd
> files.

> My package checks fine with devtools::check on my system
> and via Github Actions produced with
> usethis::use_github_action_check_standard().  However, I
> would like to release the package on CRAN, and running R
> CMD check --as-cran gives me a number of headaches, mainly
> related to the production of pdf documents via latex as it
> seems to be not so easy to convince latex to typeset
> Japanese, see
> https://www.overleaf.com/learn/latex/Japanese

> For the vignette, I can set in the Rmarkdown file
> pdf_document: latex_engine: lualatex includes: in_header:
> preamble.tex and in the file preamble.tex
> \usepackage{luatexja} \usepackage{microtype} This gives me
> a pdf-vignette that looks and checks fine (except that the
> abovementioned GitHub Actions don't seem to find lualatex,
> which is why the pdf output is commented out in the main
> branch on GitHub).

> Unfortunately, I fail to find a similar solution for the
> pdf manual. R CMD check yields
> --
> checking PDF version of manual ... WARNING LaTeX errors
> when creating PDF version.  This typically indicates Rd
> problems.  LaTeX errors found: ! Package inputenc Error:
> Unicode character 冷 (U+51B7) (inputenc) not set up for
> use with LaTeX.  [and many more of the same] * checking
> PDF version of manual without index ... ERROR
> --
> It seems that the pdf manual is generated by first
> producing a texinfo file and then running texi2dvi. From
> 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Inserting-Unicode.html
> I take the message that texinfo does not do Japanese... Is
> there any way to work around the use of texinfo and use
> lualatex (with a preamble) instead? If not, is there a way
> to keep the UTF-8 encoded characters in the html help (I
> think this is very useful for the user!) and still produce
> a pdf that passes the check, e.g. by replacing the kanji
> characters automatically by their codepoints (or even a
> generic placeholder symbol) when generating the pdf
> manual?

I cannot help much more,
but be assured that  texinfo is *not* used in the process
It's just a "historical coincidence"  that  texi2dvi , a "simple"
shell script, typically comes from the texinfo ("software
package", i.e., in Linux distributions the texi2dvi command
(shell script, see above) is provided by the 'texinfo'
(Debian/Ubuntu/..) package

man texi2dvi  tells you about a sleuth of environment variables,
notably  PDFLATEX  TEX etc and I guess you can just set one of
these to 'lualatex' .. .. and of course lualatex must be
findable on the CRAN servers but I'd bet that to be the case.

Best,
Martin



> Any thoughts and suggestions on this would be greatly
> appreciated! I think/hope then that the remaining problems
> in R CMD check are acceptable to the CRAN team given the
> nature of my package. They are:

> 1. Examples and tests fail if the check is not run in an
> UTF-8 locale.

> 2. checking data for non-ASCII characters ... NOTE Note:
> found 111752 marked UTF-8 strings

> Many thanks, Dominic Schuhmacher




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

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

Re: [R-pkg-devel] Please install cmake on macOS builders

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Wed, 10 May 2023 21:31:29 +0200 writes:

  >>>>> Dirk Eddelbuettel 
  >>>>> on Wed, 10 May 2023 07:01:37 -0500 writes:

>> Simon,

>> Explicitly declaring

>> SystemRequirements: cmake

>> appears to be insufficient to get a build on the
>> (otherwise lovely to have) 'macOS builder', and leads to
>> failure on (at least) 'r-oldrel-macos-x86_64'.

>> Would it be possible to actually have cmake installed?

>> These daus cmake is for better or worse becoming a
>> standard, and I rely on it for one (new) package to
>> correctly configure a library. It would be nice to be
>> able to rely on it on macOS too.

> Somewhat 'ditto' from here {about wanting 'cmake' to
> become +/- standard tool for R packages use, *not* at all
> related to macOS} :

> The SuiteSparse C library on parts of which our Matrix
> package builds extensively has also switched their setup
> to use cmake instead of make ... and this was actually one
> reason we have not yet updated to the latest versions of
> SuiteSparse for the Matrix package.

> As Matrix is formally recommended, I would even be happy
> if 'cmake' became a +/- required OS tool for R ...

I've been told in private that the above "be happy if"
may *not* be a good idea,
or rather even close to impossible as   cmake  seems to not fit
well, at all, with the quite sophisticated
autoconf -> configure -> make
setup we have with building R + recommended packages
cross-platform compatibly as well as possible.

Martin


--
Martin Maechler ETH Zurich and R Core team

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

Re: [R-pkg-devel] Please install cmake on macOS builders

[Martin Maechler]

>>>>> Dirk Eddelbuettel 
>>>>> on Wed, 10 May 2023 07:01:37 -0500 writes:

> Simon,

> Explicitly declaring

> SystemRequirements: cmake

> appears to be insufficient to get a build on the (otherwise lovely to 
have)
> 'macOS builder', and leads to failure on (at least) 
'r-oldrel-macos-x86_64'.

> Would it be possible to actually have cmake installed?

> These daus cmake is for better or worse becoming a standard, and I rely 
on it
> for one (new) package to correctly configure a library. It would be nice 
to
> be able to rely on it on macOS too.

Somewhat 'ditto' from here {about wanting 'cmake' to become +/-
standard tool for R packages use, *not* at all related to macOS} :

The SuiteSparse C library on parts of which our Matrix package
builds extensively  has also switched their setup to use  cmake
instead of make ... and this was actually one reason we have not
yet updated to the latest versions of SuiteSparse for the Matrix
package.

As Matrix is formally recommended, I would even be happy if
'cmake' became a +/- required OS tool for R ...

Martin

> Thanks,  Dirk

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

--
Martin Maechler
ETH Zurich  and  R Core team

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

Re: [R-pkg-devel] Package submission rejected as it fails checks on Debian

[Martin Maechler]

> Spencer Graves 
> on Tue, 21 Feb 2023 05:25:39 -0600 writes:

> On 2/21/23 2:34 AM, Vasileios Nikolaidis wrote:
>> Yes, with all this I can think where I may have messed up. So thanks for 
>> the help, at least it verified it is indeed an issue with the code. As 
>> far as OSs, I use Ubuntu variants a lot and (on several machines) but 
>> these days I have easier access to Windows (with WSL2 btw). I also like 
>> a strict compiler (and linker), there is usually a reason why they are 
>> strict. So if it is not obvious from examining the code,  I will set up 
>> something (be it WSL, VM or Docker) for testing.


> If you have NOT tried "GitHub Action" yet, I highly recommend it. 
> For my packages, every time I do "git push", it automatically runs "R 
> CMD build / check" on 5 different platforms -- with no further effort on 
> my part other than checking the results.

[ Sorry, but for once I'd like to raise this here ...]:

well... how many "trees" does that cost every time you push?
I guess it will be less than one, but I'd also guess it be more
than 1% of one.. and even if that was more than reality, ...

I hope you are all aware that even though this looks "free", all
this mostly unnecessary (rebuilding some of the things *every*
time from scratch, downloading lots of stuff, even though from a
closeby server) traffic and server run time will partly be paid
by the kids and grand kids of people living in Bangladesh,
Polynesia, ... (and maybe even in say Amsterdam)
Global Warming *is* a threat, and we living in rich nations letting run
more and more computer networks and servers (cooling, heating,
gray energy including lots of CO2 produce by building construction, ...)
does add to it.

[[[yes, I may be partly wrong,  and
no, it's a loss of time if we start a flame/mud/... war here about this;
just consider it a small outlier voice ...
]]]


> It should be easy to get something to work following the instructions 
> in Wickham and Bryan, R Packages[1] or copying the code from another 
> package.[2] If that fails, you might be able to get help from this list. 
> I got valuable suggestions from Dir Eddelbuettel and Duncan Murdoch.


> I don't know if any version of Debian is available on GitHub Action. 
> However, if CRAN is rejecting your package on GitHub Action, a question 
> about that to this list might help make it available.  If you have 
> special Ubuntu configuration issues that are not provided in the 
> standard GitHub Action configurations, asking here might help you with 
> that.


> Hope this helps,
> Spencer Graves


> [1]


> https://r-pkgs.org


> [2] e.g.,


> https://github.com/JamesRamsay5/fda

>> 
>> Thanks again,
>> 
>> Vasilis
>> 
>> 
>> 
>> Στις 2023-02-20 23:09, Dirk Eddelbuettel έγραψε:
>>> On 20 February 2023 at 22:37, Vasileios Nikolaidis wrote:
>>> | Thanks for taking the time to check it. The hint about the virtual
>>> | 'layer' class is valuable.
>>> | I will look into it.
>>> 
>>> Sounds good, glad to have been of assistance.  On a lark, I also tried 
>>> your
>>> most recent CRAN release, and it installs and loads fine here.
>>> 
>>> | PS I am tempted to set up a Debian test platform to speed up fixing 
the
>>> | package.
>>> | (Or abandon submitting the package to CRAN alltogether.)
>>> 
>>> I love working on Linux. And these days I hear from some friends that 
>>> having
>>> WSL2 on a (recent enough) Windows computer is also good as it 
effectively
>>> gives a second machine with Ubuntu on it.  Docker can also be helpful, 
>>> as are
>>> the online resources -- rhub has helped me with both macos and windows 
>>> builds.
>>> 
>>> Dirk
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

Re: [R-pkg-devel] cross-ref possible ext.pkg's --not mentioned in DESCRIPTION file-- in non-code sections in .Rd files

[Martin Maechler]

> Andrew Simmons 
> on Mon, 7 Nov 2022 12:19:48 -0500 writes:

> Packages in Suggests and Enhances do not create a circular dependency, 
only
> the packages in the Depends and Imports need to be installed at INSTALL 
and
> loaded at load time. Packages in Suggests and Enhances are only needed at
> check time, and even then it's more of a desire to be loaded than actually
> needing to be loaded.

> I would just put them in Suggests or Enhances

Thank you, Andrew.

'Enhances'  I think would be preferable.

Still, as Peter, I am not very happy about this NOTE.
Notably as I guess people will use (even) less \link{..} in
their R documentation (*).

... but yes, we can live with it, and I'm sure Peter will keep
his Rd files well maintained in spite ..

Martin


--
*) which is often lacking anyway, in my view
   because things like roxygen implicitly/indirectly suggest to
   many package authors that documentation is something you do as
   quickly and as shortly as possible..

> On Mon, Nov 7, 2022, 11:10 Peter Ruckdeschel 
> wrote:

>> Hi,
>> 
>> triggered by some new NOTEs uncovering infallacities in my packages on
>> CRAN, I stumbled upon
>> 
>> Result: NOTE Undeclared packages ‘distrMod’, ‘RobAStBase’ in Rd xrefs
>> 
>> which is issued in R-devel-linux-x86_64-fedora-clang (but not otherwise).
>> 
>> Digging into it, this comes from a text in a \seealso section where
>> through something like
>> 
>> \code{\{link}[]{}
>> 
>> we want to link to a method provided in some extension package 
>> for a generic
>>  documented in Rd-file of the current package.
>> 
>> In this case, we intentionally do not have  in any of the 
entries
>> "Depends", "Suggests",
>> "Imports", "Enhances" in the DESCRIPTION file, as  is neither
>> needed visible for the
>> user, nor for the code in the current package nor for testing code nor 
for
>> example code and vignettes
>> of the current package, and because having it in "Suggests" would produce
>> a circular dependence
>> as  has the current package in its "Imports" section.
>> 
>> Of course, in "Writing R extesions" we find that
>> 
>> "Packages referred to by these ‘other forms’ should be declared in the
>> DESCRIPTION file, in
>> the ‘Depends’, ‘Imports’, ‘Suggests’ or ‘Enhances’ fields. "
>> 
>> so I am aware that this is my fault, as I use these 'other forms'  
without
>> declaration in the DESCRIPTION file.
>> Now I guess I could wrap my conditional cross-ref into some R-code,
>> testing whether  is available,
>> i.e., something like
>> 
>> \Sexpr[eval=TRUE,stage=render,results=text]{if("" %in%
>> installed.packages()[,1] )
>> cat("\\code{\\{link}[]{}") else cat(" from
>> package \\pkg{})
>> 
>> and so produce the link only if  is installed at rendering time,
>> but I would guess such a
>> conditional linkage would be something which could be of interest to a
>> broader scope of R-package
>> developers and hence could and should be implemented in a less 
cumbersome,
>> and more
>> efficient way.
>> 
>> Any suggestions welcome,
>> best, Peter
>> 
>> --
>> %**
>> % Prof. Dr. Peter Ruckdeschel
>> % Institut fuer Mathematik, Fakultaet V - Mathematik und
>> Naturwissenschaften
>> % Carl von Ossietzky Universitaet Oldenburg,
>> % Postfach 5634,  26111 Oldenburg
>> % Office: Wechloy W1 02-227 Tel: +49 (0)441 798-3240  Fax: +49 (0)441
>> 798-193240
>> %peter.ruckdesc...@uni-oldenburg.de
>> %http://www.uni-oldenburg.de/peter-ruckdeschel
>> %**
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 

> [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] CRAN index replaces ampersand in BugReports URL with HTML entity

[Martin Maechler]

> Mikael Jagan 
> on Mon, 7 Nov 2022 10:48:34 -0500 writes:

> Hello,

> It was raised on the Matrix bug tracker [1] that the BugReports URL
> on the CRAN index [2] is broken.  The URL in our DESCRIPTION file [3]
> is fine, but contains an ampersand, which is improperly replaced with
> the corresponding HTML entity in the HTML sources of the index.

> Hence this does not affect bug.report(package="Matrix"), but _does_
> make our bug tracker inaccessible to people accustomed to visiting
> the CRAN page for links.

> Can this be repaired?

> Mikael

> [1] 
https://r-forge.r-project.org/tracker/?func=detail=6787_id=61=294
> [2] https://cran.r-project.org/package=Matrix
> [3] https://r-forge.r-project.org/tracker/?atid=294_id=61

This has been fixed already, by Kurt Hornik -- thank you very
much!

Martin

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

Re: [R-pkg-devel] Cannot submit package due to false-positive rejection

[Martin Maechler]

> Jamie Lentin 
> on Sat, 29 Oct 2022 13:14:20 +0100 writes:

> On 2022-10-28 20:48, Ying Li via R-package-devel wrote:
>>> Flavor: r-devel-windows-x86_64 Check: examples, Result:
>>> NOTE Examples with CPU (user + system) or elapsed time >
>>> 10s user system elapsed RDM 40.05 0.89 40.94
>> 
>> Explain: This is because a large dataset is used in the
>> example. An example with large dataset is necessary, as
>> this package is meant for analyzing large datasets.

> Wrapping with \donttest{} may help here. Despite the name,
> CMD check --as-cran *will* run these tests, but will not
> be subject to the same time restrictions.

> On submission of your package, the examples will be run
> with and without \donttest{}. However, the periodic
> (daily?) checks that get run skip the \donttest{} checks,
> to keep the CPU time these require manageable, and this is
> what the NOTE is about.

> Cheers,

Sorry to be blunt but I think only Roy's is good here:
Make a small data example even though the package is for large
data ... maybe adding a comment about the really large data
example, in a vignette or possibly simply commented out (or \donttest{..}).

Do - by all means - have examples in your code  which run --
also always on CRAN.
\donttest{} or some sneaky tricks to circumenvent CRAN checks
running the example are only cheap workarounds, but not really
good.

Reasons:
- Users new to your package may just want to try a new
  function  via   example()   {or nowadays also
  clicking "Run example" in some setups}

  I do tend to misttrust (or worse) packages which do nothing in
  a such case.

- When we, as R Core, consider tweaking / changing R we do
  sometimes in advance and the CRAN processes do very regularly
  run all the checks of all CRAN with "R-devel", the development
  version and hence potential "next version" of R.
  Your package's example will be run (if they are ..!) and you
  as package author may be notified well in advance should the
  examples stop running.


With regards,
Martin

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

Re: [R-pkg-devel] Error when install binary from CRAN but not if install from source - Macintosh, lme4, Matrix, buildmer

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Wed, 19 Oct 2022 14:55:24 -0400 writes:

> It seems that this could be mostly avoided if instead of caching copies 
> of Matrix methods when buildmer was installed, R would cache promises to 
> get those methods.  Then if the method for some particular signature 
> changed, on first use buildmer would retrieve the current version.

> There would still be a problem if Matrix completely dropped a method or 
> it migrated to a different package, but I think that's less frequent 
> than a change to the internal implementation.

> Has any thought been given to making this change for R 4.3.0?

> Duncan Murdoch

Not that I know of.

It sounds like a very promising (pun! ;-) idea, that could solve
many subtle  inter-package installation/update  problems.

Note that the methods *and* classes  caching had been introduced
a longer while ago as part of a concerted effort to make the
loading of packages with (many) S4 methods and classes considerably faster.

Before that effort, all these class and method "tables"/"lists"
(environments effectively) were (re-)computed at package load
time which was quite costly [time consuming].
I was not very much involved in that effort and I don't know if
using promises instead had been considered at the time.

(I've added Michael and the other Martin M to the CC , hoping
 they will know / remember more )

Martin Maechler


> On 19/10/2022 3:39 a.m., Martin Maechler wrote:
>>>>>>> Duncan Murdoch
>>>>>>> on Tue, 18 Oct 2022 15:17:33 -0400 writes:
>> 
>> > I see the same thing.  This sounds like a problem in the handling of
>> > methods that has been discussed somewhat recently:
>> 
>> > https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html
>> 
>> > The problem is that when the binary is built, some code from other
>> > packages is kept as part of it.  When that other package is updated, 
you
>> > need a new source install of your own package (or a rebuild at CRAN to
>> > replace the binary) to cache the new code.
>> 
>> > This can also be done explicitly by package startup code; I think this
>> > thread
>> 
>> > https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html
>> 
>> > turned out to be a case where rstan was caching something, and an 
update
>> > to ggplot2 didn't work with the cached data.  Given the error message,
>> > your issue sounds more like the first one.
>> 
>> > I don't recall if there was a resolution.  Maybe you can ask the CRAN
>> > maintainers to rebuild buildmer.
>> 
>> > Duncan Murdoch
>> 
>> Yes, thank you, Duncan!
>> 
>> The binary version of 'buildmer' (or also lme4 ?) must have been created
>> with an older version of Matrix  (which did not have the
>> dgeMatrix_getDiag C code)  and the respective maintainer of the
>> binary builds (*) must rebuild the binary versions of those
>> Matrix-reverse-dependant packages,
>> ---
>> *) in this case the macOS ones (both for Intel and ARM Macs)
>> 
>> Martin Maechler
>> (maintainer of Matrix)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
>> >> I've run into a problem where if you install the lme4, Matrix, and 
buildmer
>> >> packages using the binaries from CRAN on a Mac, I get an error message
>> >> about a missing method, but if I install the same packages from 
SOURCE, the
>> >> code runs fine.
>> >>
>> >> I would have thought that installing from source or using the binary
>> >> should look the same.
>> >>
>> >> Any suggestions on how to proceed to resolve this issue?
>> >>
>> >> The maintainer of buildmer is also puzzled.
>> >> You can follow the issue in more detail at:
>> >> https://github.com/cvoeten/buildmer/issues/20
>> >>
>> >> This is way above my paygrade...
>> >>
>> >> Carl Schwarz
>> >>
>> >> --
>> >>
>> >> Tried this on an intel-Mac and arm-Mac with the same result.
>> >> Works fine on Windows machines under both scenarios.
>> >>

Re: [R-pkg-devel] Error when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Tue, 18 Oct 2022 15:17:33 -0400 writes:

> I see the same thing.  This sounds like a problem in the handling of 
> methods that has been discussed somewhat recently:

> https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html

> The problem is that when the binary is built, some code from other 
> packages is kept as part of it.  When that other package is updated, you 
> need a new source install of your own package (or a rebuild at CRAN to 
> replace the binary) to cache the new code.

> This can also be done explicitly by package startup code; I think this 
> thread

> https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html

> turned out to be a case where rstan was caching something, and an update 
> to ggplot2 didn't work with the cached data.  Given the error message, 
> your issue sounds more like the first one.

> I don't recall if there was a resolution.  Maybe you can ask the CRAN 
> maintainers to rebuild buildmer.

> Duncan Murdoch

Yes, thank you, Duncan!

The binary version of 'builmer' (or also lme4 ?) must have been created
with an older version of Matrix  (which did not have the
dgeMatrix_getDiag C code)  and the respective maintainer of the
binary builds (*) must rebuild the binary versions of those
Matrix-reverse-dependant packages,
---
*) in this case the macOS ones (both for Intel and ARM Macs)

Martin Maechler
(maintainer of Matrix)








> On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
>> I've run into a problem where if you install the lme4, Matrix, and 
buildmer
>> packages using the binaries from CRAN on a Mac, I get an error message
>> about a missing method, but if I install the same packages from SOURCE, 
the
>> code runs fine.
>> 
>> I would have thought that installing from source or using the binary
>> should look the same.
>> 
>> Any suggestions on how to proceed to resolve this issue?
>> 
>> The maintainer of buildmer is also puzzled.
>> You can follow the issue in more detail at:
>> https://github.com/cvoeten/buildmer/issues/20
>> 
>> This is way above my paygrade...
>> 
>> Carl Schwarz
>> 
>> --
>> 
>> Tried this on an intel-Mac and arm-Mac with the same result.
>> Works fine on Windows machines under both scenarios.
>> 
>> Here is a test example
>> 
>> library(buildmer)
>> library(lme4)
>> 
>> nrow <- 100
>> 
>> test <- data.frame(x01=runif(nrow),
>> y=runif(nrow)<.1, block=as.factor(floor((1:nrow)/50)))
>> head(test)
>> 
>> 
>> fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
>> family=binomial(link="logit"))
>> fit.model # this works
>> 
>> class(fit.model)
>> 
>> summary(fit.model)
>> # gives the following error message
>> Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not found
>> 
>> A pdf document showing output is attached (shows the sessionInfo etc).
>> 
>> When you install the buildmer and Matrix packages from SOURCE, it runs 
fine.
>> 
>> I've tried all combinations of installing binary/source and only if both
>> packages (Matrix and buidmer) are installed from source, does the code 
run.
>> 
>> Same issue on an intel-Mac.
>> Same issue when running under the R directly rather than Rstudio on a 
Mac.

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

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

[Martin Maechler]

> Ben Bolker 
> on Mon, 10 Oct 2022 16:59:35 -0400 writes:

> Right now as.POSIXlt.Date() is just
> function (x, ...)
> .Internal(Date2POSIXlt(x))

It has been quite a bit different in R-devel  for a little
while.  NEWS entries  (there are more already, and more coming
on the wide topic)

* The as.POSIXlt() and as.POSIXct() default
  methods now do obey their tz argument, also in this case.

* as.POSIXlt() now does apply a tz (timezone) argument, as
  does as.POSIXct(); partly suggested by Roland Fuss on the R-devel
  mailing list.

and indeed it would have been good had you used (and read) the
R-devel mailing list  which is much more appropriate on the
topic of *changing* base R behavior.




> How expensive would it be to throw a warning when '...' is provided by 
> the user/discarded ??

> Alternately, perhaps the documentation could be amended, although I'm 
> not quite sure what to suggest. (The sentence Liam refers to, "Dates 
> without times are treated as being at midnight UTC." is correct but 
> terse ...)


> On 2022-10-10 4:50 p.m., Alexandre Courtiol wrote:
>> Hi Simon,
>> 
>> Thanks for the clarification.
>> 
>> From a naive developer point of view, we were initially baffled that the
>> generic as.POSIXlt() does very different things on a character and on a
>> Date input:
>> 
>> as.POSIXlt(as.character(foo), "Europe/Berlin")
>> [1] "1992-09-27 CEST"
>> 
>> as.POSIXlt(foo, "Europe/Berlin")
>> [1] "1992-09-27 UTC"
>> 
>> Based on what you said, it does make sense: it is only when creating the
>> date/time that we want to include the time zone and that only happens 
when
>> we don't already work on a previously created date.
>> That is your subtle but spot-on distinction between "parsing" and
>> "changing" the time zone.
>> 
>> Yet, we do find it dangerous that as.POSIXlt.Date() accepts a time zone 
but
>> does nothing of it, especially when the help file starts with:
>> 
>> Usage
>> as.POSIXlt(x, tz = "", ...)
>> 
>> The behaviour is documented, as Liam reported it, but still, we will 
almost
>> certainly not be the last one tripping on this (without even adding the
>> additional issue of as.POSIXct() behaving differently across OS).
>> 
>> Thanks again,
>> 
>> Alex & Liam
>> 
>> 
>> 
>> 
>> On Mon, 10 Oct 2022 at 22:13, Simon Urbanek 
>> wrote:
>> 
>>> Liam,
>>> 
>>> I think I have failed to convey my main point in the last e-mail - which
>>> was that you want to parse the date/time in the timezone that you care
>>> about so in your example that would be
>>> 
 foo <- as.Date(33874, origin = "1899-12-30")
 foo
>>> [1] "1992-09-27"
 as.POSIXlt(as.character(foo), "Europe/Berlin")
>>> [1] "1992-09-27 CEST"
>>> 
>>> I was explicitly saying that you do NOT want to simply change the time
>>> zone on POSIXlt objects as that won't work for reasons I explained - 
see my
>>> last e-mail.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
 On 11/10/2022, at 6:31 AM, Liam Bailey 
>>> wrote:
 
 Hi all,
 
 Thanks Simon for the detailed response, that helps us understand a lot
>>> better what’s going on! However, with your response in mind, we still
>>> encounter some behaviour that we did not expect.
 
 I’ve included another minimum reproducible example below to expand on
>>> the situation. In this example, `foo` is a Date object that we generate
>>> from a numeric input. Following your advice, `bar` is then a POSIXlt 
object
>>> where we now explicitly define timezone using argument tz. However, even
>>> though we are explicit about the timezone the POSIXlt that is generated 
is
>>> always in UTC. This then leads to the issues outlined by Alexandre 
above,
>>> which we now understand are caused by DST.
 
 ``` r
 #Generate date from numeric
 #Not possible to specify tz at this point
 foo <- as.Date(33874, origin = "1899-12-30")
 dput(foo)
 #> structure(8305, class = "Date")
 
 #Convert to POSIXlt specifying UTC timezone
 bar <- as.POSIXlt(foo, tz = "UTC")
 dput(bar)
 #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
 #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =
>>> c("POSIXlt",
 #> "POSIXt"), tzone = "UTC")
 
 #Convert to POSIXlt specifying Europe/Berlin.
 #Time zone is still UTC
 bar <- as.POSIXlt(foo, tz = "Europe/Berlin")
 dput(bar)
 #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
 #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =
>>> c("POSIXlt",
 #> 

Re: [R-pkg-devel] Examples taking too long depend on object that takes a while to generate

[Martin Maechler]

>>>>> John Harrold 
>>>>> on Thu, 15 Sep 2022 05:11:15 -0700 writes:

> Not to be pedantic but it's not a dataset per-se. It's an R object that 
the
> examples need.

Yes.
(and see below)

> On Thu, Sep 15, 2022 at 2:49 AM Duncan Murdoch 
> wrote:

>> On 15/09/2022 5:29 a.m., Martin Maechler wrote:
>> >>>>>> Duncan Murdoch
>> >>>>>>      on Thu, 15 Sep 2022 04:42:04 -0400 writes:
>> >
>> >  > On 15/09/2022 3:45 a.m., Martin Maechler wrote:
>> >  >>>>>>> Duncan Murdoch
>> >  >>>>>>> on Wed, 14 Sep 2022 13:02:28 -0400 writes:
>> >  >>
>> >  >> > On 14/09/2022 12:43 p.m., Ivan Krylov wrote:
>> >  >> >> On Wed, 14 Sep 2022 12:31:49 -0400
>> >  >> >> Duncan Murdoch  wrote:
>> >  >> >>
>> >  >> >>> It's also possible to put .R files in the data directory, 
and they
>> >  >> >>> are executed to create the data object.  I think that 
happens at the
>> >  >> >>> time when you call data() rather than at install time, so 
it might
>> >  >> >>> not be helpful.
>> >  >> >>
>> >  >> >> Some time ago I was hoping to compress a package of mine by 
generating a
>> >  >> >> dataset during a data() call instead loading it from an 
.rda file, but
>> >  >> >> it turned out that the .R file is executed during R CMD 
build:
>> >  >> >>
>> 
https://github.com/r-devel/r-svn/blob/03df313ad37456c6a62158328d4e373408ce4d59/src/library/tools/R/build.R#L794
>> >  >>
>> >  >> > Thanks for that info.  That's not good for John, because the
>> >  >> > architecture isn't known at build time.
>> >  >>
>> >  >> > Duncan Murdoch
>> >  >>
>> >  >> Sorry to muddy the water, but what *is* "build time"?
>> >  >> There's the big difference between building
>> >  >> 1) a  Source tarballand
>> >  >> 2) a  MacOS or Windows binary package
>> >  >>
>> >  >> Unfortunately, the two situations are very different notably in
>> >  >> this case, where '(2)' is really much closer to the
>> >  >> "install time" you mention.
>> >  >>
>> >
>> >  > I meant building the tarball, and assumed that was what Ivan 
was talking
>> >  > about as well.
>> >
>> >  > Duncan Murdoch
>> >
>> > Ok, thank you, for the clarification.
>> >
>> > Note that  `R CMD build --help`  mentions (among more)
>> >
>> >--resave-data=re-save data files as compactly as possible:
>> >  "no", "best", "gzip" (default)
>> >--no-resave-data  same as --resave-data=no
>> >
>> > so when building the package,
>> > Ivan should get what he wanted with
>> >
>> >  R CMD build --no-resave-data  
>> >
>> > no ?
>> 
>> It's actually John Harrold who has the problem:  a dataset that he wants
>> to use in examples that takes a long time to build, causing his examples
>> to exceed the CRAN 5 second limit.
>> 
>> So what I was suggesting is that he should arrange for it to be created
>> before running the example; the problem is that the dataset depends on
>> the architecture of the machine that's running the example.  To follow
>> my suggestion he would need to have the dataset created when the package
>> was installed (or the binary was built).

and now John can use the data() "trick" Ivan recommended *if*
John builds his source tar ball using
   R CMD build --no-resave-data

*and* puts the code that creates the R object into a  /data/myRobj.R  
file
*and* adds a

  data(myRobj)

into his .onLoad() hook.

This would *not* create the object at package installation time
but each time the package is loaded .. which is at least only
once for all the examples in  R CMD check 

OTOH, I do agree with you Duncan, that in this case your
suggestion seems preferable and we add the R code which creates
the object somewhere "nakedly" in /R/zzz.R  {zzz: to be alphabetically 
last}
and hence the object would live (hidden) in his_pkg namespace.

He'd ideally also provide an *exported* function, say

myData <- function(name = "")  get(name, 
asNamespace(""))

and then would use  myData()  {or myData(".") } in his
package examples.

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

Re: [R-pkg-devel] tryCatch() doesn't capture errors due to && or || with R CMD check --as-cran

[Martin Maechler]

> Lionel Henry 
> on Thu, 1 Sep 2022 18:47:36 +0200 writes:

> Hi Martin,
> I'm not sure I understand what you mean regarding suppressed warnings
> in testthat.

> - All warnings are reported to users by `devtools::test()`, with
> accompanying backtraces. They are not hidden.

> - R CMD check doesn't report warnings emitted from files in `tests/`.

but you can easily grep them in the tests/*.Rout files.
There are none of these in the testthat case,
and it's own summary only *counts* the number of warnings.

At least for me just now in a development version of lme4 (github),
running with increased (non-default) testlevel
export LME4_TEST_LEVEL=2

I get useful *.Rout files (with only one warning, easily greppable)
for the non-testthat tests whereas  for the testthat ones I only get


[ FAIL 3 | WARN 1 | SKIP 1 | PASS 829 ]

══ Skipped tests ═══
• On CRAN (1)

══ Failed tests 
── Failure (test-methods.R:878:9): parallel influence ──
`i1` not equal to `i2`.
Component "vcov[-case]": Component "1": Attributes: < Length mismatch: 
comparison on first 1 components >
.
.
Component "vcov[-case]": Component "9": Attributes: < Length mismatch: 
comparison on first 1 components >
...
── Failure (test-summary.R:33:3): lmer ─
tfun(cc1) not equal to c(...).
Lengths differ: 5 is not 10
── Failure (test-summary.R:46:3): lmer ─
tfun(cc2) not equal to c(...).
Lengths differ: 5 is not 10

[ FAIL 3 | WARN 1 | SKIP 1 | PASS 829 ]
Error: Test failures
Execution halted


Telling me (twice) that there was  1 warning, but
I don't know of any way to *see* that warning
(after everything is run, and I have  lme4.Rcheck/  to look
into).


> If you need some sort of warning to surface as errors, warnings, or
> notes in R CMD check, it should be possible to come up with
> something.

Yes, that would be important for some of us.

IIRC, It does not help to just add

  options(warn = 2)

at the beginning of the main tests/*.R  file, or inside the
tests/testthat/*.R files , even though that would be standard R
behavior,  no ?

> This could take the form of special classes of conditions
> that R CMD check would catch and emit corresponding diagnostics
> for. We would change testthat to make sure all such conditions are
> properly emitted during checks.

If they are emitted as in R from warning() or stop() -- from R or C,
that would be a big step forward for us (R core) who'd like to
see effects of changing base R, and for all package maintainers considering
changing their API or just deprecating something, and using  .Deprecated()
{or equivalent} for that.

Thank you, Lionel!

Martin

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

Re: [R-pkg-devel] a problem with the underscore in a R function document

[Martin Maechler]

> Yaoyong Li 
> on Sat, 11 Jun 2022 12:29:25 +0100 writes:

> Hello,

> I just got a problem in a function document in a package I developed.The
> file containing the document is generatingCDSaaFile.Rd. The problem is
> related to the underscore I used in the following sentence

> and the last part is ‘\_AAseq.txt.gz’

> I got a 'note' message when the package was checked in the CRAN:

> checkRd: (-1) generatingCDSaaFile.Rd:72: Escaped LaTeX specials: \_

> I don't think I saw this kind of message in the past (say six months
> ago). 

Yes, you are right.. this is quite new.  Some of my
/man/*.Rd  files have been affected similarly.

AFAIK there is a history behind, where the   Rd -> LaTeX
translation code was partly buggy  for quite a long time, and hence
such  `\`-escapes where necessary in *.Rd such that the produced
*.tex was LaTeX-able.

However, these Rd2latex bugs/problems have been fixed and now
almost all such \-escapes are not only unneeded but actually the
`\` become visible, hence ugly looking
==> hence the NOTE.

> A copy of the check result in CRAN is appended below. As you can
> see, I also got the same problem in other places in the document. I
> have been trying to fix the problem via searching Google. I have tried
> to replace "\_" with "\textunderscore " as some internet post
> suggested, but this did not solve the problem.

> So I just wonder if anyone can help me with the problem. Please let me
> know if any more information is needed.

In all cases in my packages,  just removing the `\` (or
sometimes `\\` ?)  was perfect, so I think you can and should do
just that.

Best,
Martin


> Best regards,

> Yaoyong

> #

> CRAN Package Check Results for Package geno2proteo
> 

> Last updated on 2022-06-11 11:52:26 CEST.
> FlavorVersionTinstallTcheckTtotalStatusFlags
> r-devel-linux-x86_64-debian-clang
> 

> 0.0.5 17.31 170.54 187.85 NOTE
> 

> r-devel-linux-x86_64-debian-gcc
> 

> 0.0.5 12.00 130.58 142.58 NOTE
> 

> r-devel-linux-x86_64-fedora-clang
> 

> 0.0.5 220.04 NOTE
> 

> r-devel-linux-x86_64-fedora-gcc
> 

> 0.0.5 229.54 NOTE
> 

> r-devel-windows-x86_64
> 

> 0.0.5 242.00 470.00 712.00 NOTE
> 

> r-patched-linux-x86_64
> 

> 0.0.5 12.58 164.99 177.57 OK
> 

> r-release-linux-x86_64
> 

> 0.0.5 OK
> 

> r-release-macos-arm64
> 

> 0.0.5 65.00 OK
> 

> r-release-macos-x86_64
> 

> 0.0.5 89.00 OK
> 

> r-release-windows-x86_64
> 

> 0.0.5 195.00 363.00 558.00 OK
> 

> r-oldrel-macos-arm64
> 

> 0.0.5 57.00 OK
> 

> r-oldrel-macos-x86_64
> 

> 0.0.5 84.00 OK
> 

Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

[Martin Maechler]

>>>>> Georgi Boshnakov 
>>>>> on Mon, 8 Nov 2021 09:46:00 + writes:

> You need to define the generic with a default value for
> this parameter. Methods can then have a different default
> value for it. 
> I remember reading this in S4's documentation but don't remember where.

> Georgi Boshnakov

interesting ... and would make quite some sense.

Can others confirm / disprove ?

Even as co-author of the "using S4 almost everywhere" package 'Matrix'
I wouldn't have known this.

If this is seen to be true (I don't have time for checking just now),
I think it's something we really *should* add to one or more of
the related help pages.

Martin Maechler


> 

> Sent: Monday, November 8, 2021 5:37:18 AM
> To: Dario Strbenac 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>> From the line `function(A, B) standardGeneric("SetOfParams")`, A and B 
will
> always have default values of R_MissingArg
> Providing default values within the methods does nothing since A and B 
have
> already been initialized before arriving at the method.
> You could do something like:


> if (missing(A))
> A <- ...
> if (missing(B))
> B <- ...


> within each method, and that would emulate having default values for A and
> B.

> On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac 

> wrote:

>> Good day,
>> 
>> How can a parameter take a default value from a vector of permitted ones,
>> if it is missing?
>> 
>> setClassUnion("characterOrMissing", c("character", "missing"))
>> setClassUnion("integerOrMissing", c("integer", "missing"))
>> setClass("SetOfParams", representation(A = "characterOrMissing", B =
>> "integer"))
>> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>> 
>> setMethod("SetOfParams", c("missing", "missing"), function() # Empty 
constructor
>> {
>> new("SetOfParams", A = "M", B = 100L)
>> })
>> 
>> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
>> function(A = c("L", "M", "N"), B = 100L)
>> {
>> A <- match.arg(A)
>> new("SetOfParams", A = A, B = B)
>> })
>> 
>> SetOfParams(B = 500L)
>> Error in match.arg(A) : argument "A" is missing, with no default.
>> 
>> How can I avoid the error about A having no default? I thought I 
specified
>> it so that it does have one, which match.arg would set for me if the user
>> did not specify one.
>> 
>> --
>> Dario Strbenac
>> University of Sydney
>> Camperdown NSW 2050
>> Australia
>> __
>> R-package-devel@r-project.org mailing list

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

Re: [R-pkg-devel] Is there a better way ...?

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Thu, 21 Oct 2021 08:09:02 -0400 writes:

> I agree with almost everything Deepayan said, but would add one thing:
> On 21/10/2021 3:41 a.m., Deepayan Sarkar wrote:
> ...

>> My suggestion is having a package-specific environment, and Duncan's
>> is to have a function-specific environment. If you only need this for
>> this one function, then that should be good enough. If you eventually
>> want to access the persistent information from multiple functions,
>> having a package-specific environment would be more useful.

> I agree with that statement, but those aren't the only two choices. 
> Your local() call can create several functions and return them in a 
> list; then just those functions have access to the local variables.  For 
> example,

> createFns <- local({

> .fooInfo <- NULL

> fn1 <- function (...) { ... }
> fn2 <- function (...) { ... }

> list(fn1 = fn1, fn2 = fn2)
> })

> fns <- createFns()
> fn1 <- fns$fn1
> fn2 <- fns$fn2

> Now fn1 and fn2 are functions that can see .fooInfo, and nobody else can 
> (without going through contortions).

> One other difference between this approach and the package-specific 
> environment:  there's only one package-specific environment in 
> Deepayan's formulation, but I could call createFns() several times, 
> creating several pairs of functions, each pair with its own independent 
> version of .fooInfo.

> I don't know if that's something that would be useful to you, but 
> conceivably you'd want to maintain partial plots in several different 
> windows, and that would allow you to do so.

Note that the above approach has been how  nls()  has been
implemented for R ... a very long time ago {before R 1.0.0}

e.g. from  example(nls) :

DNase1 <- subset(DNase, Run == 1)
fm1 <- nls(density ~ SSlogis(log(conc), Asym, xmid, scal), DNase1)
str(fm1 $ m)
> List of 16
>  $ resid :function ()  
>  $ fitted:function ()  
>  $ formula   :function ()  
>  $ deviance  :function ()  
>  $ lhs   :function ()  
>  $ gradient  :function ()  
>  $ conv  :function ()  
>  $ incr  :function ()  
>  $ setVarying:function (vary = rep_len(TRUE, np))  
>  $ setPars   :function (newPars)  
>  $ getPars   :function ()  
>  $ getAllPars:function ()  
>  $ getEnv:function ()  
>  $ trace :function ()  
>  $ Rmat  :function ()  
>  $ predict   :function (newdata = list(), qr = FALSE)  
>  - attr(*, "class")= chr "nlsModel"

## so 16 functions, all sharing the *same* environment very
## efficiently and nicely

## this is *the* environment for the fitted model :
fmE <- environment(fm1$m[[1]])
ls.str(fmE)
> convCrit : function ()  
> dev :  num 0.00479
> env :  
> form : Class 'formula'  language density ~ SSlogis(log(conc), Asym, xmid, 
> scal)
> getPars : function ()  
>  
>  
>  

so the environment "contains" the functions themselves (but quite
a few more things) and for an environment that means it only
has pointers to the same function objects which are *also* in  `fm1$m`.

So, there has been a nice convincing and important example on
how to do this - inside R for more than two decennia.

Martin Maechler

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

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Martin Maechler]

> Lenth, Russell V 
> on Tue, 21 Sep 2021 18:43:07 + writes:

> As I suspected, and a good point. But please note that the term "retired" 
causes angst, and it may be good to change that to "superceded" or something 
else.

well,  some of us will  become "retired" somewhere in the
future rather than "superseded" .. ;-)

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

Re: [R-pkg-devel] Workaround for code/documentation mismatch

[Martin Maechler]

> Hello,
> 
> I've written two functions to emulate do while/until loops seen in other
> languages, but I'm having trouble documenting its usage. The function is
> typically used like:
> 
> do ({
> expr1
> expr2
> ...
> }) %while% (cond)

I understand that you did *not* ask .. but really
why don't you want to use R's own
builtin, fast, well documented, present everywhere *and* simpler syntax

while(cond) {
  expr1
  expr2
  ...
}   

???

and also

   repeat {
 expr1
 expr2
 
 if(cond) break
   }

instead of your   %until%  below?


> so I want to document it something like:
> 
> do(expr) %while% (cond)
> do(expr) %until% (cond)
> 
> to look like the documentation for 'while' and 'if', but R CMD check
> produces a "Code/documentation mismatch" warning, complaining that the
> documentation should look like:
> 
> expr %while% cond
> expr %until% cond
> 
> So, my question is, is there a way to bypass the
> * checking for code/documentation mismatches
> portion of R CMD check, at least for one file? Some way to acknowledge that
> the code and documentation will mismatch, but that's okay.
> 
> 
> Thank you!

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

Re: [R-pkg-devel] Tools beyond roxygen2 to write Rd documentation

[Martin Maechler]

>>>>> Iago Giné-Vázquez 
>>>>> on Thu, 05 Aug 2021 08:09:48 + writes:

> Dear all, Are there any tools to edit .Rd files by hand
> (so avoiding roxygen2), as an editor (like could be
> *RdStudio*, à la RStudio or TeXstudio) or a plugin for ViM
> or another editor (like could be *vim-Rd*, à la
> vim-latex)?

> Thanks for your answers,

> Stay safe, Iago

Yes, of course:
"All good" R package authors edit *.Rd files by hand
((;-), well no, I know it's not true ..
 I personally use roxygen (in ESS, see below) only sometimes at the very
 beginning of writing a new function, or for functions that I
 do *not* export, because there's a nice key stroke to create
 the outline). ... and if I export that function use the
 Roxygen -> Rd *once* only, and from then on, I edit the *.Rd nicely
 including using descriptions lists, some math, etc... all well
 indented, nicely human-readable etc, much nicer than hidden in
 roxygen R comments)

Rstudio has supported *.Rd in the past but as I'm not using it
regularly .. I don't know if they dropped it now... that would
honestly surprise me, though.

Rather  ESS (Emacs Speaks Statistics) has always well supported
Rd editing, and I thought the  vim - plugin for R would also
support *.Rd  but probably not ??

Best,
Martin

--
Martin Maechler
ETH Zurich,  R Core Team  (*and* ESS Core team)

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

Re: [R-pkg-devel] package test returns error when R version 4.1.0

[Martin Maechler]

>>>>>   
>>>>> on Mon, 5 Jul 2021 17:46:54 -0400 writes:

> Gm:


> Did you try completely removing the LazyData line from the
> description file?


> David

Dear David,

where did you get this "idea" that 'LazyData'  is not good  for
 R 4.1.0 and newer ?

R's own  {datasets} package  *does* use lazyloading, and so do
most (formally) recommended packages, and I think most packages
I (co-)maintain, i.e., around two dozen CRAN packages do use
lazyloaded data.

---
*) The `Matrix` package is a big exception with 'Lazyload: No'
because its datasets partly are (S4-) classed objects from the package
itself, and -- as the "WRE" ('Writing R Extensions') manual
states -- package datasets must not *need* the package itself when
they should be lazy loaded.

Martin

--
Martin Maechler
ETH Zurich  and  R Core Team

 
> From: Gianmarco Alberti ..
> Sent: Monday, July 5, 2021 5:13 PM 
...

> Hello,

> Thank you all for the suggestions.

> I am starting being a bit worried because I seem not being
> able to fix the issue.

[..]

> I also tried to keep the new dependency and to drop the
> lazy download instead (in DESCRIPTION I have put LazyData:
> false). I got the same results as above.

> The package checks perfectly on my MAC, and checked
> perfectly when I asked a Win users to test the package on
> his PC (with the latest version of R).

> I am really scratching my head.

[]

> On 5 Jul 2021, 13:25 +0200, dbosa...@gmail.com
> <mailto:dbosa...@gmail.com> , wrote:


> For the lazy loading error, if you are not intentionally
> lazy loading data, you should remove the lazy loading
> entry from the description file. Previously this was not
> causing any problems with the CRAN checks, but now it is.

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

Re: [R-pkg-devel] How to communicate WARNINGS fixed from *last* CRAN version of a package

[Martin Maechler]

> Alberto Garre 
> on Tue, 22 Jun 2021 10:52:26 +0200 writes:

> Thanks! It is the first time I got this message, so I was a bit puzzled
> about what to do. I will be patient, then :)

> Alberto

well, as Sebastian said

>> The auto-check e-mail said "Hence please reply-all and explain". If you
>> followed these instructions, you will just need some more patience.

so, did you "reply-all" to that automated e-mail and explain
that you fixed them?

You need to do this even when you had it in the "submitter's comments".

Martin



> El mar, 22 jun 2021 a las 10:50, Sebastian Meyer ()
> escribió:

>> Am 22.06.21 um 10:11 schrieb Alberto Garre:
>> > Hi,
>> >
>> > I submitted yesterday a new version of the biogrowth package (
>> > https://cran.r-project.org/package=biogrowth). In the automatic
>> response, I
>> > got the following message:
>> >
>> > The auto-check found additional issues for the *last* version released 
on
>> > CRAN:
>> >   donttest 
>> >   M1mac 
>> > CRAN incoming checks do not test for these additional issues.
>> > Hence please reply-all and explain: Have these been fixed?
>> >
>> > I resubmitted mentioning in cran-comments.md that these problems had 
been
>> > resolved, but I got again the same automatic response. Then, I answered
>> > directly to the automatic email with no effect.
>> >
>> > How should I communicate these issues have been fixed? Is there any
>> > additional issue I am not seeing?
>> 
>> The auto-check e-mail said "Hence please reply-all and explain". If you
>> followed these instructions, you will just need some more patience. You
>> submitted only yesterday evening and these checks require manual
>> inspection by the CRAN team. I can see your submission in the "inspect"
>> folder of the incoming queue (https://CRAN.R-project.org/incoming/).
>> 
>> Best regards,
>> 
>> Sebastian Meyer
>> 
>> >
>> > Thank you,
>> > Alberto
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>> 

> [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Martin Maechler]

>>>>> Avraham Adler 
>>>>> on Wed, 2 Jun 2021 15:28:25 -0400 writes:

> Exactly. Is square is just brow=ncol, is positive definite can be
> implemented as a check that all eigenvalues > 0, which can be done with
> base, and is.symmetric can be simply brute forced in a loop comparing i,j
> with j,i.

> The fewer dependencies a package has, the more robust it is. It’s a fine
> balance between not reinventing the wheel and ceding too much stability to
> other packages.

> Thanks,
> Avi

Indeed.  Further,

-  isSymmetric()  has been part of base for a long time
   so the definition of an alternative in matrixcalc  had been @_*#^$%
   It's also supported by methods in the Matrix package
   e.g. for sparse matrices etc  so definitely something you
   "should" use instead.

-  is.square() is trivial and I think an explicit check such as
   { d <- dim(x);  d[1] == d[2] }
   is often more sensical, notably as in many of your functions
   you'd need either nrow(.) or ncol(.) of your matrix anyway.

- A remark on Positive Definiteness (or also, often what you really want,
   "Positive Semi-definitness", allowing 0 eigen values):
  The  Matrix  package has an (S4) class  "dpoMatrix"
  of dense positive-definite (actually 'positive semi-definite') matrices.
  In its validation method (yes, formal classes have validation!), we
  use a cheap test instead of an expensive test with eigenvalues
  (which is "too expensive": there are faster ones at least in theory,
   e.g., trying an  LDL' Cholesky decomposition and returning as soon as
   a non-positive / negative entry in D would appear).

  The really cheap "pre-test" you may want to use  before or instead
  of doing one of the more expensive ones is simply checking the diagonal:

   if(any(diag()) <  0) "not positive-semidefinite"
   if(any(diag()) <= 0) "not positive-definite"

Martin Maechler
(Maintainer of 'Matrix').


> On Wed, Jun 2, 2021 at 3:15 PM John Harrold 
> wrote:

>> To add another option. In the past when this has happened to me I've 
found
>> other packages that provide similar functionality.
>> 
>> I'm assuming that is.square just checks the number of columns == number 
of
>> rows? And the others can probably be implemented pretty easily.
>> 
>> On Wed, Jun 2, 2021 at 10:41 AM Ben Staton  wrote:
>> 
>> > My package uses the MIT license, so would that not meet the 
compatibility
>> > requirements?
>> >
>> > I will attempt to reach out to the package author - thanks for your 
help!
>> >
>> > On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:
>> >
>> > > That all sounds exactly right.
>> > >GPL >= 2 allows you to use the material without asking permission 
as
>> > > long as your package is compatibly licensed (e.g. also GPL).
>> > >Under normal circumstances it would be polite to ask permission, 
but
>> > > if the reason for doing this is that the maintainer is unreachable in
>> > > the first place ...
>> > >
>> > >   If you want to try a little harder, it seems quite possible that 
you
>> > > can reach the matrixcalc maintainer at the (personal) e-mail address
>> > > shown in this page:
>> > >
>> > >
>> >
>> 
https://www.facebook.com/photo/?fbid=10208324530363130=ecnf.1000413042
>> > >
>> > >(Possibly an identity confusion, but I rate that as unlikely based
>> on
>> > > other facebook snooping)
>> > >
>> > >I don't think a short, polite e-mail request would be out of 
bounds,
>> > > they can always ignore it or tell you to go away.
>> > >
>> > >cheers
>> > > Ben Bolker
>> > >
>> > > On 6/2/21 1:15 PM, Ben Staton wrote:
>> > > > Hello,
>> > > >
>> > > > Thank you for your detailed list of solutions.
>> > > >
>> > > > I was initially tempted to go with option 1 (move matrixcalc to
>> > suggests
>> > > > and check for its existence before using functions that rely on 
it),
>> > but
>> > > as
>> > > > mentioned, this is not a long term fix.
>> > > >
>> > > > I unfortunately can't take on the responsibilities of option 2
>

Re: [R-pkg-devel] Using ggplot2 within another package

[Martin Maechler]

> Ben Bolker 
> on Thu, 22 Apr 2021 17:27:49 -0400 writes:

> For some reason that I don't remember, an R core member once told me 
> that they prefer x <- y <- NULL to utils::globalVariables(c("x","y")) - 

That could have been me.  Even though I think I still have some
globalVariables() statements in some of my package sources, I've
decided that it *harms* really, notably for relatively common variable names 
such
as "x":   It declares them "global"
{ for the purpose of codetools::globalVariables() } everywhere,
i.e. for all functions in the package namespace and that
basically kills the reliability of  globalVariables() checking
for the whole package.


> although I have also encountered problems with that strategy in edge 
cases.

well, when?

> Here's an example from StackOverflow from today where for some reason 
> I don't understand, evaluation of function arguments interacts with 
> non-standard/lazy evaluation within a dplyr function such that 'foo' 
> works while 'x$foo' doesn't ... don't know if it's a similar case.

> 
https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198


{ ceterum censeo ... to use NSE (non-standard-evaluation) for
  user convenience and to call this (together with really good
  ideas)  "tidy" has been one of the biggest euphemisms in the history of
  statistical computing ...  but yes, that's just my personal opinon  }

> On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
>> Thanks.
>> 
>> Obviously, long. long ago, (in a galaxy not far enough away), Paul's
>> suggestion of using "aes_string" was the correct one, since "aes" uses
>> non-standard evaluation. (And to quote somebody from an R fortune
>> cookie, "The problem with non-standard evaluation is that it is
>> non-standard.") But teh documentation at the end oft he link provided by
>> Robert explivityl tells you not to do that, since "aes_string is
>> deprecated".  And reading more carefully into the manual page for
>> aes_string, one does indeed find the statement that the function is
>> "soft deprecated". I'm not sure what that means, other than someone on
>> the development team doesn't like it.
>> 
>> Instead, the vignette says you should
>>    importFrom("rlang", ".data")
>> in your NAMESPACE, and write
>>    ggplot(myData, aes(x = .data$myX, y = .data$myY))
>> 
>> And now my dinosaur question: That looks like using one non-standard
>> hack to cover up the problems with another non-standard hack. Why the
>> heck  is that any better for the developer than writing
>>    ggplot(myData, aes(x = myData$myX, y = myData$myY))
>> 
>> or using Dirk Eddelbuettel's suggestion of calling 
utils::globalVariables ??
>> 
>> It's time to tell those kids to get off of my lawn.
>>   Kevin
>> 
>> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
>>> Kevin,
>>> 
>>> This vignette from ggplot2 itself gives the "officially recommended"
>>> ways to avoid the warnings from R CMD check
>>> 
>>> https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
>>> 
>>> 
>>> Cheers,
>>> 
>>> -Robert
>>> 
>>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
>>> mailto:paul.sav...@univ-fcomte.fr>> wrote:
>>> 
>>> Hi Kevin,
>>> 
>>> I was faced to the same problem and I used 'aes_string()' instead
>>> of 'aes()'. You can then just write the name of the columns
>>> containing the data to plot as character strings.
>>> 
>>> Example:
>>> 
>>> myPlot <- function(myData, ...) {
>>>     # get ready
>>>     ggplot(myData, aes_string(x = "myX", y = "myY")) +
>>>        # add my decorations
>>>        theme_bw()
>>> }
>>> 
>>> It is probably already the case for your function but you need to
>>> include #' @import ggplot2 in your function preamble (if I am not
>>> wrong).
>>> 
>>> Kind regards
>>> Paul
>>> 
>>> - Mail original -
>>> De: "Kevin R. Coombes" >> >
>>> À: "r-package-devel" >> >
>>> Envoyé: Jeudi 22 Avril 2021 22:28:55
>>> Objet: [R-pkg-devel] Using ggplot2 within another package
>>> 
>>> Hi,
>>> 
>>> I'm trying to help clean up an R package for someone else to
>>> submit to
>>> CRAN. He has used ggplot2 to implement a plotting function for the
>>> kinds
>>> of things that his packages generates. His plotting routine basically
>>> looks like (after changing names to protect the innocent):
>>> 
>>> myPlot <- fucntion(myData, ...) {
>>>     # get ready
>>>     ggplot(myData, aes(x = myX, y = myY)) +
>>>    # add my decorations
>>>    theme_bw()
  

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Fri, 13 Nov 2020 17:45:44 -0500 writes:

> On 13/11/2020 4:32 p.m., Gábor Csárdi wrote:
>> On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch 
 wrote:
>> [...]
>>> Things may have changed since Henrik and I wrote the code, but his
>>> description matches my understanding as well (and I think he's
>>> contributed more recently than I have).
>>> 
>>> The way non-Sweave vignettes work is that some packages register
>>> themselves to recognize vignette files in the vignettes directory.  The
>>> default one recognizes .Rnw files as vignettes (and a few other
>>> extensions too); the knitr::rmarkdown one recognizes .Rmd files and some
>>> others.  The only way for a package's registration code to be called is
>>> for it to be listed as a VignetteBuilder.  See ?tools::vignetteEngine
>>> for details of the engine.
>> 
>> Can one of you please fix WRE then? The part that says
>> 
>> "...then knitr provides the engine but both knitr and rmarkdown are
>> needed for using it, so both these packages need to be in the
>> ‘VignetteBuilder’ field..."
>> 

> No, neither of us are members of R Core.  Only R Core can edit the 
manuals.

> Duncan Murdoch

I've (finaly) followed this thread to here  ((too many e-mails, too many ...)).

I think I have understood what you wrote and why R Core should
change WRE in this part.

Notably as I have not written it, there needs to be consultation
--> Forwarding to R-core  ((i.e., a very rare cross-post !))

Thank you, very much for the discussion, Gábor, Henrik and Duncan!
Martin

--
Martin Maechler
ETH Zurich  and  R Core team

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

Re: [R-pkg-devel] Usage of internet resources in examples

[Martin Maechler]

> Ben Bolker 
> on Tue, 20 Oct 2020 17:07:10 -0400 writes:

> On 10/20/20 4:51 PM, Gábor Csárdi wrote:
>> On Tue, Oct 20, 2020 at 9:45 PM Ben Bolker  wrote:
>> [...]
>>> if (testthat::skip_on_cran())
>>> 
>>> all seem like reasonable solutions.
>> 
>> I don't think you can use `testthat::skip_on_cran()` for this, it does
>> not return a logical flag:
>> 
>> ❯ isTRUE(testthat::skip_on_cran())
>> Error: Reason: On CRAN
>> 
>> It only works in testthat tests.
>> 
>> Gabor
>> 
>> [...]
>> 

> oh OK, sorry.  The guts of the function are (in testthat:::on_cran(), 
> which can't be used because it's not exported)

> !identical(Sys.getenv("NOT_CRAN"), "true")

I still disagree with that part of your recommendations, for this reason:
I think a "perfect" solution would keep the example(s) running
fine when the user calls

 example()

(hence it is very good recommendation to  *not* misuse \dontrun{.} here)
*and* have the   example(.)  call  *not* stop on error, but (say)
produce a warning in the case the internet connection isn't
stable at the time the user calls   example(.),
e.g., myself in a train ride in the Swiss alps ..

Hence, your (Ben's) first two suggestions make more sense to me,
and I'd clearly favor

try(.)

or possibly slightly more sophsticated versions such as

  if(inherits(try({
 ...
 }), "try-error"))  warning()

Or then your 2nd suggestion,  if(interactive())
in the case (as it seems here) where the package author
really wants the user to get an error when the internet
connection fails.


Martin

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

Re: [R-pkg-devel] checking windows timing?

[Martin Maechler]

> Ben Bolker 
> on Tue, 13 Oct 2020 12:46:11 -0400 writes:

>Following up on my questions from yesterday:

>I've been advised to (drastically) reduce the checking
> time of my package on CRAN's Windows platform (currently
> at 23 min). I've gone through and added a lot of
> conditionals to skip tests on CRAN.  I could reduce it
> farther but I'm starting to encounter seriously
> diminishing returns, e.g.


>   * do I condition out some particular test that takes 6
> seconds? (e.g., a little slow, but not egregious) * do I
> put \dontrun{} around an example that takes 6 seconds [I'm
> a bit confused about this, but as I understand it CRAN
> checks with --run-donttest ? \dontrun{} also sometimes
> provokes complaints from CRAN, because "you should only
> use \dontrun{} for code that cannot be run by users" ...]

Really don't use \dontrun{}.  You'll stop running those examples
even for the users of  your package who  do

 example()

Rather do use an environment variable - based setup (as Uwe
mentioned).

In several packages of mine, I use

if(:::doExtras()) { 
  ...  ## longer running examples / tests
}

sometimes also using withAutoprint({  })  which is important
when the longer running code is producing output that I'd want
to continue showing.


In my 'robustbase' package, I have somewhere in robustbase/R/.R

## Not exported, and only used because CRAN checks must be faster
doExtras <- function() {
interactive() || nzchar(Sys.getenv("R_robustbase_check_extra")) ||
identical("true", unname(Sys.getenv("R_PKG_CHECKING_doExtras")))
}

so doExtras()  is true for me,  *either* if I set the

package-specificR_robustbase_check_extra  variable to non-empty
*or* the more globalR_PKG_CHECKING_doExtras   variable to non-empty.

That way, I can have all these check running in my own checks
(say by default, but can turn them off by unsetting the env.var.)

and yes, I use  doExtras  extensively in the tests, but very
much on purpose also in examples, there sometimes  combined with

 if(interactive()) { ... }

which keeps help page examples running interactively, but not in
'R CMD check' ..

Martin

>I don't want to spend forever tweaking things, and I
> don't want to comment/condition out all of my tests, but I
> would really prefer to avoid bouncing from CRAN again. I
> don't know a *reliable* way to test whether CRAN-checking
> on Windows will take <10 mins or not ...

>I don't have a local Windows test platform.

>win-builder gives timings for long-running components,
> but not for the whole run.

>r-hub gives a time for the entire build (19 min in my
> case) - but this includes the time to set up the virtual
> machine, install all packages, etc..

>I can approximately predict that most examples and
> tests will take twice as long on CRAN's windows machines
> (and four times as long since tests, at least, are checked
> on both i386 and x86_64 architectures).

>Testing is currently taking 6 minutes on my local
> machine (newish Ubuntu 18.04 laptop), so I guess have more
> work to do, but I wonder if anyone has suggestions ...

>cheers Ben Bolker

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

Re: [R-pkg-devel] How do you Rd reference parallel::mclapply() so it works also on Windows?

[Martin Maechler]

> Henrik Bengtsson 
> on Tue, 7 Jul 2020 18:11:00 -0700 writes:

> Here's another "Non-file package-anchored link(s) ..."
> issue.  I'd like to reference parallel::mclapply() in my
> help pages.  With the new R-devel requirements, you have
> to link to the file and not the topic.  However, there is
> no cross-platform stable file reference for
> parallel::mclapply();

> # According to R on Linux
>> basename(help("mclapply", package="parallel"))
> [1] "mclapply"

> # According to R on Windows
>> basename(help("mclapply", package="parallel"))
> [1] "mcdummies"

Indeed, another example, why we should move away from the
'file' instead of 'topic' (<-> \alias{.}) paradigm and requirement.

I'm optimistic we will do that soonish ...

Apropos: Today starts the virtual [useR! 2020] conference with
 an R-core Keynote and an R-core Panel for asking
 questions :

  https://user2020.r-project.org/program/agenda/ 

  https://twitter.com/useR2020stl/status/1280655009714233346?s=20

Martin


> How can I provide a \link{} reference to the
> help("mclapply", package="parallel") documentation?

> Thanks,
> Henrik

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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Martin Maechler]

> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:

> I agree with almost everything you wrote, except one thing:  this isn't 
> newly enforced, it has been enforced since the help system began.  What 
> I think is new is that there are now tests for it.  Previously those 
> links just wouldn't work.

> Duncan Murdoch

Yes, to all... including Duncan's agreement with Gábor.

Also, Duncan M earlier did mention that he had wanted to
*change* the link-to-file behavior for these cases (when he
wrote most of the Rd2html source code) but somehow did not get it.

And that's why we had partial workarounds (as the dynamic server
still finding the links under some circumstances).

My personal opinions was also that "we" (the R community; i.e.,
people providing good patches to the R sources / collaborating
with R core / ...) should rather work to fix the current
design/implementation "infelicity" than the current checks
starting to enforce something which is really a wart in my view,
and indeed, as Gábor also notes, will create R source
documentation that depends on implementation details of other
package's documentation.
I don't like it either, not at all.

Martin

> On 14/06/2020 6:26 a.m., Gábor Csárdi wrote:
>> On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
>>  wrote:
>> [...]
>>> 
>>> I think the argument was that static builds of the help pages would have
>>> trouble resolving the links.  With the current system, you can build a
>>> help page that links to a page in package foo even if package foo is not
>>> installed yet, and have the link work later after you install foo.
>> 
>> That is true, but it is also not a big problem, I think. The CRAN
>> Windows R installer does indeed build static help pages by default.
>> But the built-in web server that serves these works around broken
>> links by treating them as help topics instead of files. As you know.
>> :) So this would only be a problem if you wanted to serve the static
>> help pages with another web server. (Which is not a bad use case, but
>> then maybe Rd2HTML() can just resolve them as topics and avoid the
>> broken links.)
>> 
>> Btw. the problem of linking to the wrong page is even worse with
>> static builds of help pages, because if a link w/o a package (e.g.
>> \link{filter}) picks up the wrong package at install time, then the
>> wrong link is hard-coded in the html. If you are building binary
>> packages, then they will link to the wrong help pages.
>> 
>> WRE says that specifying the package in the link is rarely needed.
>> This was probably the case some time ago, especially when packages did
>> not have (compulsory) namespaces. But I am not sure if it still holds.
>> I would argue that it is better to specify the package you are linking
>> to. But the newly enforced requirement that we need to link to files
>> instead of topics makes this more error prone.
>> 
>> Gabor
>> 
>> [...]

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

Re: [R-pkg-devel] Forward function call

[Martin Maechler]

> Göran Broström 
> on Mon, 8 Jun 2020 23:02:30 +0200 writes:

> Thanks for the responses!
> I found the suggestion

> Call[[1]] <- quote(survival::coxph)

> easiest to implement. And it works.

and it is what we use in R's own R source code in several
places (and that's where/how I assume it also came to  Ben
Bolker, lme4, etc) :

A simple grep inside current R's source /src/library/ gives

grep -r --color -nHF -e 'quote(stats::'

./stats/R/acf.R:28:m[[1L]] <- quote(stats::pacf)
./stats/R/aggregate.R:154:m[[1L]] <- quote(stats::model.frame)
./stats/R/aov.R:36:lmcall[[1L]] <- quote(stats::lm)
./stats/R/bartlett.test.R:86:m[[1L]] <- quote(stats::model.frame)
./stats/R/cor.test.R:213:m[[1L]] <- quote(stats::model.frame)
./stats/R/factanal.R:73:mf[[1L]] <- quote(stats::model.frame)
./stats/R/friedman.test.R:92:m[[1L]] <- quote(stats::model.frame)
./stats/R/ftable.R:150:m[[1L]] <- quote(stats::model.frame)
./stats/R/glm.R:52:mf[[1L]] <- quote(stats::model.frame)
./stats/R/glm.R:863:fcall[[1L]] <- quote(stats::glm)
./stats/R/lm.R:34:mf[[1L]] <- quote(stats::model.frame)
./stats/R/lm.R:546:fcall[[1L]] <- quote(stats::model.frame)
./stats/R/loess.R:34:mf[[1L]] <- quote(stats::model.frame)
./stats/R/manova.R:22:fcall[[1L]] <- quote(stats::aov)
./stats/R/model.tables.R:485:fcall <- c(list(quote(stats::model.frame)), 
args)
./stats/R/nls.R:570:mf[[1L]] <- quote(stats::model.frame)
./stats/R/ppr.R:30:m[[1L]] <- quote(stats::model.frame)
./stats/R/prcomp.R:69:mf[[1L]] <- quote(stats::model.frame)
./stats/R/princomp.R:30:mf[[1L]] <- quote(stats::model.frame)
./stats/R/quade.test.R:102:m[[1L]] <- quote(stats::model.frame)
./stats/R/spectrum.R:220:m[[1L]] <- quote(stats::plot.spec.coherency)
./stats/R/spectrum.R:226:m[[1L]] <- quote(stats::plot.spec.phase)
./stats/R/t.test.R:141:m[[1L]] <- quote(stats::model.frame)
./stats/R/ts.R:744:m[[1L]] <- quote(stats::window)
./stats/R/var.test.R:97:m[[1L]] <- quote(stats::model.frame)
./stats/R/xtabs.R:40:m[[1L]] <- quote(stats::model.frame)


> Best, Göran

> On 2020-06-08 21:42, Ben Bolker wrote:
>> I think quote(survival::coxph) will work in place of as.name() ?
>> 
>> On Mon, Jun 8, 2020 at 3:12 PM Göran Broström  
wrote:
>>> 
>>> Hello,
>>> 
>>> the function 'coxreg' in my package 'eha' is often just a wrapper for
>>> 'coxph' in survival, so I have code like
>>> 
>>> if (cox.ph){
>>> Call <- match.call()
>>> Call[[1]] <- as.name("coxph")
>>> fit <- eval.parent(Call)
>>> return(fit)
>>> }
>>> 
>>> which works since eha depends on survival. Now I am thinking of changing
>>> Depends to Imports, and I would like to change the code to
>>> 
>>> if (cox.ph){
>>> Call <- match.call()
>>> Call[[1]] <- as.name("survival::coxph")
>>> fit <- eval.parent(Call)
>>> return(fit)
>>> }
>>> 
>>> but this doesn't work, because the function name is turned into
>>> `survival::coxph` (with the backticks) and the evaluation fails.
>>> 
>>> How can I solve this?
>>> 
>>> Thanks, G,
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

Re: [R-pkg-devel] [R] a question of etiquette

[Martin Maechler]

> Adelchi Azzalini 
> on Tue, 2 Jun 2020 08:32:37 +0200 writes:

> Thanks for this information, Mark.  Given the phrase
> "small but important function my package uses", it seems
> that you included in your package some code, reproducing
> it verbatim.  Do I understand correctly?  In my case, the
> code which I am actually using is the R porting of code
> originally written in another language, namely Matlab.

> Best wishes,
> Adelchi


Indeed. I would definitely not list the original Matlab authors as
'aut', but just as 'ctb' (= contributor).

e.g., for the 'robustbase' package, I have, among authors@R

  , person("Peter", "Rousseeuw", role="ctb", comment = "Qn and Sn")

Personally, I'd always use a  comment = "..."  tag mentioning
*what* the contributor (or "co-author") has contributed to.

Best,
Martin


>> On 1 Jun 2020, at 23:37, R. Mark Sharp 
>> wrote:
>> 
>> Adelchi,
>> 
>> I have a similar situation where I had made all of the
>> typical academic references within the code and
>> documentation for a small but important function my
>> package uses. I was asked by the CRAN reviewers to add
>> the author of that function to the DESCRIPTION Authors@R
>> section. I added the following: person("Terry",
>> "Therneau", role = c("aut”))
>> 
>> Mark R. Mark Sharp, Ph.D.  Data Scientist and Biomedical
>> Statistical Consultant 7526 Meadow Green St.  San
>> Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Adelchi Azzalini  Subject:
>>> [R] a question of etiquette Date: June 1, 2020 at
>>> 11:34:00 AM CDT To: r-h...@r-project.org
>>> 
>>> The new version of a package which I maintain will
>>> include a new function which I have ported to R from
>>> Matlab.  The documentation of this R function indicates
>>> the authors of the original Matlab code, reference to
>>> their paper, URL of the source code.
>>> 
>>> Question: is this adequate, or should I include them as
>>> co-authors of the package, or as contributors, or what
>>> else?  Is there a general policy about this matter?
>>> 
>>> Adelchi Azzalini http://azzalini.stat.unipd.it/
>>> 
>>> __
>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and
>>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>> http://www.R-project.org/posting-guide.html and provide
>>> commented, minimal, self-contained, reproducible code.
>> 

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

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

Re: [R-pkg-devel] Rmarkdown vignette yields r inline warning on windows build [EXT]

[Martin Maechler]

> Matthew Young 
> on Mon, 4 May 2020 09:09:55 + writes:

> I progressively chopped bits out of the vignette till the
> error stopped to identify the error.  It was being caused
> by inline latex, where I had two %% marks.  I'm not really
> sure why this broke things, but removing it fixed it.

"fascinating" .. yes, unfortunately, the Rmarkdown related
engines (I suspect pandoc, but haven't thought or digged about it)
are clearly not bug free.

That's been my experience quite frequently when I "exaggerate"
in my use of LaTeX "tricks" in Rmarkdown documents ..

If somebody knows where exactly such cases should be sent, it
may help improving the situation.. I'm really no expert here.

Martin

> Thanks,
> Matthew

> On 02/05/2020, 16:54, "Uwe Ligges"
>  wrote:

> My wild guess is that 'r ' indicates there is an
> invisible char after the r that is not representable in
> the chosen encoding.

> Best, Uwe Ligges



> On 02.05.2020 01:12, Matthew Young wrote:
>> I’ve tried both ways (with and without a space after the
>> backtick) and get the same error.
>> 
>> From: Max Turgeon  Date:
>> Friday, 1 May 2020 at 20:39 To: Matthew Young
>> , "r-package-devel@r-project.org"
>>  Subject: Re: Rmarkdown
>> vignette yields r inline warning on windows build [EXT]
>> 
>> 
>> Since you're looking for suggestions and that's all I
>> have:
>> 
>> 
>> 
>> Could it be the space between the tick mark and the r?
>> For example, does replacing ` round` with `round` (and
>> all other instances) fix the issue?
>> 
>> 
>> Max Turgeon Assistant Professor Department of Statistics
>> Department of Computer Science University of Manitoba
>> maxturgeon.ca
>> 
[maxturgeon.ca]
>> 
>> 
>> 
>>  From: R-package-devel
>>  on behalf of
>> Matthew Young  Sent: May 1, 2020
>> 2:24:40 PM To: r-package-devel@r-project.org Subject:
>> [R-pkg-devel] Rmarkdown vignette yields r inline warning
>> on windows build
>> 
>> 
>> Caution: This message was sent from outside the
>> University of Manitoba.
>> 
>> 
>> I am trying to submit a package to CRAN that includes a
>> vignette built using rmarkdown.  It passes fine on the
>> machines I have access to (ubuntu and osx).  When I
>> submit to CRAN using the form, it passes the Debian
>> checks, but fails on windows with the following WARNING:
>> 
>> ! Missing $ inserted.   $ l.1030
>> 
>> You may need to add $ $ around a certain inline R
>> expression `r `
>> 
>> 
>> I’m really not sure what is causing this error or how to
>> debug it.  I do not have any inline r expressions in my
>> vignette (code here
>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_constantAmateur_SoupX_blob_devel_vignettes_pbmcTutorial.Rmd=DwIDaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=XXcY8t_J1mVMCDTmi3629g=ES3UP2LbqvhOCSwVRP53v_p9EkdNJSwmYuIlfmKly28=R9IaPh1UjnNyLSsE8CxG_GorvzRQPg8160TkSZoRoac=
>> 
[github.com]).
>> I do have back-ticked expression such as `round`, but
>> they are not executed code.  Can anyone suggest what
>> might be causing this issue?
>> 
>> Many thanks,
>> 
>> Matthew
>> 
>> 
>> 
>> --
>> The Wellcome Sanger Institute is operated by Genome
>> Research Limited, a charity registered in England with
>> number 1021457 and a company registered in England with
>> number 2742969, whose registered office is 215 Eu...{{dropped:26}}

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

Re: [R-pkg-devel] Error creating union class: object ‘.__C__compMatrix’ not found

[Martin Maechler]

   >>> R Under development (unstable) (2020-04-07 r78175)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Ubuntu 16.04.6 LTS
>>> 
>>> Matrix products: default
>>> BLAS/LAPACK: /usr/lib/libopenblasp-r0.2.18.so
>>> 
>>> locale:
>>> [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>>> [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>>> [9] LC_ADDRESS=C   LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>>> 
>>> other attached packages:
>>> [1] Matrix_1.2-18
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.1.0  grid_4.1.0  lattice_0.20-41
>>> 
>>> Bill Dunlap
>>> TIBCO Software
>>> wdunlap tibco.com
>>> 
>>> On Wed, Apr 8, 2020 at 7:35 AM Martin Maechler 
 wrote:
>>> 
>>>>>>>>> renozao
>>>>>>>>> on Mon, 30 Mar 2020 21:20:43 + writes:
>>>> 
>>>> > Hi,
>>>> > when R CMD check is run under R-devel (2020-03-29 r78108) I get the 
following error at installation:
>>>> 
>>>> > Error in get(cname, envir = cwhere, inherits = FALSE) :
>>>> > object ‘.__C__compMatrix’ not found
>>>> > Error in setClassUnion("mMatrix", c("Matrix", "matrix")) :
>>>> > unable to create union class:  could not set members "Matrix"
>>>> 
>>>> > This does not happen on R 3.6.3.
>>>> 
>>>> > I tried with Matrix listed in Depends but I still get the same error.
>>>> 
>>>> > Is this linked to some changes in union classes or the Matrix 
package?
>>>> 
>>>> > Thank you.
>>>> 
>>>> > Bests,
>>>> > Renaud
>>>> 
>>>> Hi Renaud,
>>>> One reason you got no response here, is because we don't even
>>>> know about which package you are talking.
>>>> 
>>>> So there's nothing, anybody can reproduce from your posting.
>>>> 
>>>> There have been changes in R's dealing with class unions etc,
>>>> notably even *relating* to an earlier bug report on class unions
>>>> exactly for such a case which was *triggered* when people built
>>>> on such Matrix classes.
>>>> 
>>>> But we would really want to be able to reproduce what you are seeing..
>>>> 
>>>> Best regards,
>>>> Martin Maechler
>>>> 
>>>> ETH Zurich, R Core Team *and* maintainer("Matrix")
>>>> 
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] Error creating union class: object ‘.__C__compMatrix’ not found

[Martin Maechler]

>>>>> renozao  
>>>>> on Mon, 30 Mar 2020 21:20:43 + writes:

> Hi,
> when R CMD check is run under R-devel (2020-03-29 r78108) I get the 
following error at installation:

> Error in get(cname, envir = cwhere, inherits = FALSE) :
> object ‘.__C__compMatrix’ not found
> Error in setClassUnion("mMatrix", c("Matrix", "matrix")) :
> unable to create union class:  could not set members "Matrix"

> This does not happen on R 3.6.3.

> I tried with Matrix listed in Depends but I still get the same error.

> Is this linked to some changes in union classes or the Matrix package?

> Thank you.

> Bests,
> Renaud

Hi Renaud,
One reason you got no response here, is because we don't even
know about which package you are talking.

So there's nothing, anybody can reproduce from your posting.

There have been changes in R's dealing with class unions etc,
notably even *relating* to an earlier bug report on class unions
exactly for such a case which was *triggered* when people built
on such Matrix classes.

But we would really want to be able to reproduce what you are seeing..

Best regards,
Martin Maechler

ETH Zurich, R Core Team *and* maintainer("Matrix")

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

Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS

[Martin Maechler]

> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:

 > Hi Tomas and others:
 > Here is the session Info.  I also used the str example both without and
 > with changing the locale.

 > sI <- sessionInfo()
>> str(sI)
 > List of 10
 > $ R.version :List of 14
 > ..$ platform  : chr "x86_64-w64-mingw32"
 > ..$ arch  : chr "x86_64"
 > ..$ os: chr "mingw32"
 > ..$ system: chr "x86_64, mingw32"
 > ..$ status: chr ""
 > ..$ major : chr "3"
 > ..$ minor : chr "6.3"
 > ..$ year  : chr "2020"
 > ..$ month : chr "02"
 > ..$ day   : chr "29"
 > ..$ svn rev   : chr "77875"
 > ..$ language  : chr "R"
 > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
 > ..$ nickname  : chr "Holding the Windsock"
 > $ platform  : chr "x86_64-w64-mingw32/x64 (64-bit)"
 > $ locale: chr "LC_COLLATE=English_United
 > States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United
 > States.125"| __truncated__
 > $ running   : chr "Windows 10 x64 (build 18362)"
 > $ RNGkind   : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
 > $ basePkgs  : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
 > $ loadedOnly:List of 1
 > ..$ compiler:List of 9
 > .. ..$ Package: chr "compiler"
 > .. ..$ Version: chr "3.6.3"
 > .. ..$ Priority   : chr "base"
 > .. ..$ Title  : chr "The R Compiler Package"
 > .. ..$ Author : chr "Luke Tierney "
 > .. ..$ Maintainer : chr "R Core Team "
 > .. ..$ Description: chr "Byte code compiler for R."
 > .. ..$ License: chr "Part of R 3.6.3"
 > .. ..$ Built  : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC; windows"
 > .. ..- attr(*, "class")= chr "packageDescription"
 > .. ..- attr(*, "file")= chr
 > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
 > $ matprod   : chr "default"
 > $ BLAS  : chr ""
 > $ LAPACK: chr ""
 > - attr(*, "class")= chr "sessionInfo"


 > Running the str example WITHOUT changing the locale:
>> ## Truncation behavior (<-> correct width measurement) for "long"
 > non-ASCII:
>> idx <- c(65313:65338, 65345:65350)
>> fwch <- intToUtf8(idx) # full width character string: each has width 2
>> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>> (ncc <- c(c.ch = nchar(ch),   w.ch = nchar(ch,   "w"),
 > +   c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
 > c.ch w.ch c.fw w.fw
 > 64   64   32   64
>> stopifnot(unname(ncc) == c(64,64, 32, 64))
>> ## nchar.max: 1st line needs an increase of  2  in order to see  1  (in
 > UTF-$
>> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
 > chr " chr " chr " chr " chr " chr ""| __truncated__
 > chr "<"| __truncated__
>> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 is 1"
 > he$
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._Q._R._S._T._U._V"
>> 

 > Running the str example WITH changing the locale:

 > oloc <- Sys.getlocale("LC_CTYPE")
>> mbyte.lc <- if(.Platform$OS.type == "windows")
 > +  "English_United States.28605" else "en_GB.UTF-8"
>> try(Sys.setlocale("LC_CTYPE", mbyte.lc))
 > [1] "English_United States.28605"
>> ## Truncation behavior (<-> correct width measurement) for "long"
 > non-ASCII:
>> idx <- c(65313:65338, 65345:65350)
>> fwch <- intToUtf8(idx) # full width character string: each has width 2
>> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>> (ncc <- c(c.ch = nchar(ch),   w.ch = nchar(ch,   "w"),
 > +   c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
 > c.ch w.ch c.fw w.fw
 > 64   64   32   64
>> stopifnot(unname(ncc) == c(64,64, 32, 64))
>> ## nchar.max: 1st line needs an increase of  2  in order to see  1  (in
 > UTF-$
>> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
 > Error in strtrim(x.lrg, nchar.max - nc) :
 > unsupported conversion from 'UTF-8' in codepage 28605
>> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 is 1"
 > he$
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"| __truncated__
 > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"| 

Re: [R-pkg-devel] Help on Windows CRAN Check

[Martin Maechler]

> John Lawson 
> on Thu, 5 Mar 2020 20:34:00 -0700 writes:

> I see this error on windows CRAN Check
> --- failure: the condition has length > 1 ---
> --- srcref ---
> :
> --- package (from environment) ---
> daewr
> --- call from context ---
> ihstep(y, x, m, c)
> --- call from argument ---
> if (t1 == "I" & t2 == "(") {
> iquad = TRUE
> }

> t1 and t2 are both characters of length 1, therefore I assume they are
> scalars. The check on my own computer or R forge gives no errors. When
> I change if(t1 == "I" & t2 =="(") {iquad=TRUE} to

> if(t1 == "I" && t2 =="(") {iquad=TRUE}

> I get the following error when I try the check on my own computer

> --- FAILURE REPORT --
> --- failure: length > 1 in coercion to logical ---
> --- srcref ---
> :
> --- package (from environment) ---
> daewr
> --- call from context ---
> ihstep(y, x, m, c)
> --- call from argument ---
> t1 == "I" && t2 == "("
> --- R stacktrace ---
> where 1: ihstep(y, x, m, c)
> where 2: eval(expr, pf)
> where 3: eval(expr, pf)
> where 4: withVisible(eval(expr, pf))
> where 5: evalVis(expr)
> where 6: capture.output(res <- ihstep(y, x, m, c))
> where 7: withCallingHandlers(expr, warning = function(w)
> invokeRestart("muffleWarning"))

> I am not sure what this means. Using one &, I am able to check and
> build the package on my computer or R forge but not on CRAN. When
> using two && I can't check and build on my own computer. Any advice on
> what to do would be greatly appreciated.

Well, to me it seems clear that your claim

  "t1 and t2 are both characters of length 1, therefore .."

must be wrong sometimes and that's why you these problems:
In both cases, the respective error is triggered *if and only if*
at least one of t1 or t2 is *not* of length 1.

Martin

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

Re: [R-pkg-devel] For reproducibility issue

[Martin Maechler]

>>>>> وليد خلف معوض المطيرى 
>>>>> on Fri, 17 Jan 2020 19:10:53 + writes:

> Hi all,

> I think what I�ve done is something different.

yes, but ...

> Inside the Fortran subroutine, I have a subroutine for setting the seed 
value of the RNG of GNU Fortran which I think it is not related to the R RNG 
like the one below:

> subroutine initrandomseedsinr(temp)
> implicit none
> integer :: n
> integer, intent(in):: temp
> integer, dimension(:), allocatable :: seed

> call random_seed(size = n)
> allocate(seed(n))
> seed = temp
> call random_seed(PUT = seed)
> deallocate(seed)

> end subroutine initrandomseedsinr
> , 
> where temp is an argument of the Fortran subroutine as well as in the 
wrapper R function. This will be related to the RNG method used in the GNU 
Fortran that build on GCC not to the R. I am not sure if I am right on this, 
but tried with using RNGkind(sample.kind = "Rounding") and it doesn�t help.

indeed, it has no effect on your Fortran / run time random
generator.

But really really truly :  a "decent" R package should use R's
random number generators rather than (C library / Fortran
library / ...).
When using R's RNGs, your package behaves "R like" e.g.,
set.seed() has the desired effect, etc etc.

What Avi Adler describes below is what I strongly believe you
*really* should change your package to do as well.

Best regards,

Martin Maechler
ETH Zurich and R Core Team


> The difference in the results were not major. The output at the end of 
running the functions kept having very similar results, but still have the 
issue of reproducing exact results which I need it for relating work that is 
based on the package.

> Many thanks,

> Waleed




> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for 
Windows 10

> From: Avraham Adler<mailto:avraham.ad...@gmail.com>
> Sent: �Friday,� �January �17,� �2020 �06:30 ��
> To: Ivan Krylov<mailto:krylov.r...@gmail.com>
> Cc:  ���  ���<mailto:wkmtie...@qu.edu.sa>; R Package 
Development<mailto:r-package-devel@r-project.org>
> Subject: Re: [R-pkg-devel] For reproducibility issue

> Hi.

> If it helps, I call the R RNG from Fortran in my Delaporte package
> [1], also using iso_c_bindings. Specifically, I have the following C
> code [2]:

> void F77_SUB(unifrnd) (int *n, double *x){
> GetRNGstate();
> for (int i = 0; i < *n; ++i){
> *(x + i) = unif_rand();
> }
> PutRNGstate();
> }
> and call it in Fortran like so [3]:

> subroutine rdelap_f(n, a, na, b, nb, l, nl, vars) bind(C, 
name="rdelap_f_")

> external unifrnd

> integer(kind = c_int), intent(in), value :: n, na, nb, nl
> real(kind = c_double), intent(out), dimension(n) :: vars
> real(kind = c_double), intent(in) :: a(na), b(nb), l(nl)
> real(kind = c_double), dimension(n) :: p
> integer(kind = c_int) :: lg, lt

> call unifrnd(n, p)
> lt = 1_c_int
> lg = 0_c_int
> call qdelap_f(p, n, a, na, b, nb, l, nl, lt, lg, vars)

> end subroutine rdelap_f

> The package passes CRAN tests (at least as of now) on anything between
> GCC 4 and GCC9 [4].

> Hope that helps,

> Avi

> [1] https://bitbucket.org/aadler/delaporte/src/master/
> [2] 
https://bitbucket.org/aadler/delaporte/src/master/src/utils_and_wrappers.c
> [3] https://bitbucket.org/aadler/delaporte/src/master/src/delaporte.f95
> [4] https://cran.r-project.org/web/checks/check_results_Delaporte.html


> On Fri, Jan 17, 2020 at 2:39 PM Ivan Krylov  wrote:
>> 
>> On Fri, 17 Jan 2020 13:55:39 +
>>  ���  ���  wrote:
>> 
>> > So, does anyone have an idea of how to solve this issue.
>> 
>> "Writing R Extensions", 1.6. Writing portable packages:
>> 
>> >> Compiled code should not call the system random number generators
>> >> such as rand, drand48 and random, but rather use the interfaces to
>> >> R�s RNGs described in Random numbers. In particular, if more than
>> >> one package initializes the system RNG (e.g. via srand), they will
>> >> interfere with each other.
>> 
>> >> Nor should the C++11 random number library be used, nor any other
>> >> third-party random number generators such as those in GSL.
>> 
>> It somewhat less convenient to call the R random number generator from
>> Fortran than it would be from C or C++, but still possible. There is a
>>

Re: [R-pkg-devel] New Package olr 4 NOTES

[Martin Maechler]

> Mat Fok via R-package-devel 
> on Wed, 4 Dec 2019 22:25:47 + writes:

> Hi,
> Thank you. I am wondering why the log would output .Rproj.user when it 
was already in the .Rignorefile. Hope the .Rignore file is correct anyways as I 
have mentioned below.

If you really use .Rignore then no wonder you have problems.
The correct file name is  .Rbuildignore

Martin

> Thanks,
> Mathew

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

Re: [R-pkg-devel] R package which creates a directory in the user home dir

[Martin Maechler]

> Sigbert Klinke 
> on Thu, 17 Oct 2019 14:29:54 +0200 writes:

> Hi,
> I'am developing a package that circumvents the R package size limitation 
> for data sets. For this I store the data set in the internet (currently 
> GitHub) and download if it is requested.

> To avoid unnecessary downloads and internet connections I create a 
> directory in the users home directory to store the data there. However, 
> this violates the "CRAN Repository Policy" which says

> - Packages should not write in the user’s home filespace (including 
> clipboards), nor anywhere else on the file system apart from the R 
> session’s temporary directory (or during installation in the location 
> pointed to by TMPDIR: and such usage should be cleaned up).

> Do I have any chance to get the package to CRAN, if I submit it?

> Best Sigbert

> https://hu.berlin/sk
> https://hu.berlin/mmstat3


I you *prompt* the user about writing, i.e., ask them explicitly
if  is fine and only if "yes", you write there,
otherwise try to write to tempdir()  then your package is fine,
otherwise it is not, i.e,
"not okay" according to many, even if *not* on CRAN..

Best,
Martin

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

Re: [R-pkg-devel] R, BLAS, and FCLEN

[Martin Maechler]

> Göran Broström 
> on Wed, 11 Sep 2019 13:36:40 +0200 writes:

> A followup question: Is it possible to call a BLAS/LAPACK subroutine, 
> where one parameter is character, from FORTRAN (77) code called by 
> .Fortran? (No problem "in the past".)

[as there wasn't a reply till now : ]

Yes, that should continue to be possible.

> And if yes, how?

I'm sorry I don't know (and currently lack the time to try to find out)...

Martin

>   Documentation describes calls from C to Fortran and 
> vice versa, but not this situation (AFAICS).

> Yes, I know that .Fortran is not well seen these days, but my fortran 
> code is ancient, from the before-R era, and I would like to leave it 
as-is.

> G,

> Den 2019-09-01 kl. 21:46, skrev Göran Broström:
>> 
>> 
>> On 2019-08-31 18:47, Göran Broström wrote:
>>> I'm having difficulties updating my package eha: When I run standard 
>>> checks 'at home' everything is fine, but 'CRAN-submissions' reports 
>>> (among other things):
>>> 
>>> geomsup.f:324:9: warning: type of ‘dgemv’ does not match original 
>>> declaration [-Wlto-type-mismatch]
>>>    324 |  & one, score, ione)
>>>    | ^
>>> /home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch 
>>> in parameter 12
>>>    107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
>>>    | ^
>>> 
>>> This is odd since the LAPACK subroutine dgemv takes only 11 
>>> parameters. However, in include/R_ext/BLAS.h we have
>>> 
>>> F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
>>>  const double *alpha, const double *a, const int *lda,
>>>  const double *x, const int *incx, const double *beta,
>>>  double *y, const int *incy FCLEN);
>>> 
>>> with a 12th parameter FCLEN?? How am I supposed to fix this, and what 
>>> the ... is FCLEN? googling leads to nothing useful (for me). It seems 
>>> as if R is redefining some standard LAPACK routines.
>>> 
>>> Also a note I do not understand (in this context):
>>> 
>>> note: type ‘void’ should match type ‘long int’
>>> 
>>> Any help is much appreciated.
>>> 
>>> Best, Göran
>>> 
>>> PS. How can I trigger these Warnings 'at home'?
>> 
>> See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks to Uwe 
>> Ligges).
>> 
>> Another relevant document seems to be (2019-05-15):
>> 
>> 
https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html
 
>> 
>> 
>> First sentence:
>> "Recent version of the GNU Fortran compiler (7, 8, 9) include 
>> optimizations that break interoperability between C and Fortran code 
>> with BLAS/LAPACK."
>> 
>> And later:
>> "For the time being, everyone should use -fno-optimize-sibling-calls 
>> with GFortran version 7 and newer."
>> 
>> G,
>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Martin Maechler]

>>>>> Ralf Stubner 
>>>>> on Fri, 6 Sep 2019 11:22:15 +0200 writes:

> On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
>  wrote:
>> For me (on Fedora 30)
>> 
>> $ R CMD config LDFLAGS
>> -L/usr/lib64

> This looks wrong. I would expect that /usr/lib64 is one of the
> standard directories that are searched anyway. So why put it into the
> very beginning of the search? BTW, this does not happen on Debian:

> $ R CMD config LDFLAGS
> -Wl,-z,relro

Thank you very much, Ralf!
Indeed my conclusion was wrong .. If I use Fedora's own R package,
then I also get something like the above :

 $ /usr/bin/R CMD config LDFLAGS
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld

(amazingly long ..)

It's just when I -- as in 99.9% of cases, as an R Core developer --
use my own built version of R, I get what you call "wrong".

... and it's  "of course" from my  ~/.R/config  settings
where added a comment for this explicit LDFLAGS setting, mentioning that
otherwise it would take -L/usr/local/lib64 and that *is*
unfortunately still true:

In current R incl R-devel's  /configure.ac  (lines 157-167)
LDFLAGS *is* set to this :

: ${LIBnn=$libnn}
## We provide these defaults so that headers and libraries in
## '/usr/local' are found (by the native tools, mostly).
if test -f "/sw/etc/fink.conf"; then
  : ${CPPFLAGS="-I/sw/include -I/usr/local/include"}
  : ${LDFLAGS="-L/sw/lib -L/usr/local/lib"}
else
  : ${CPPFLAGS="-I/usr/local/include"}
  : ${LDFLAGS="-L/usr/local/${LIBnn}"}
fi
AC_SUBST(LIBnn)


and that setting *did* harm me in the (relatively distant, ~ 7 years?)
past, and so I had replaced it with the  /usr/lib64  setting.

Hmm, maybe this should all have been on the  R-devel  mailing
list instead, and we should start asking if R's  configure.ac
(and hence configure) should be changed ?

Martin

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Thu, 5 Sep 2019 18:36:03 +0200 writes:

>>>>> Dirk Eddelbuettel 
>>>>> on Thu, 5 Sep 2019 10:14:21 -0500 writes:

>> On 5 September 2019 at 16:53, Ralf Stubner wrote:
>> | I don't know what is best, but here are three alternatives:
>> | 
>> | * Use PKG_CHECK_MODULES which sets up default variables with _CFLAGS
>> | and _LIBS suffix after searching for a library with pkg-config, c.f.
>> | https://autotools.io/pkgconfig/pkg_check_modules.html
>> | * Call pkg-config by hand in configure.ac (and hence configure).
>> | Example: 
https://github.com/eddelbuettel/rcppredis/blob/master/configure.ac#L47-L60
>> | * Call pkg-config within an "Anticonf" configure script. Example:
>> | https://github.com/jeroen/curl/blob/master/configure#L16-L24

>> Make it four alternatives:

>> * Call pkg-config from an autoconf configure script.  Examples:

>> edd@rob:~$ grep -l pkg-config git/*/configure.{ac,in}
>> git/libxls/configure.ac
>> git/nloptr/configure.ac
>> git/rcppmlpack2/configure.ac
>> git/rcppredis/configure.ac
>> git/rprotobuf/configure.ac
>> edd@rob:~$

>> I know all the cool kids these days hate autoconf, but it a) really is 
just
>> careful (and more portable) shell scripting (plus some extra glue).  And 
it
>> b) avoids having users on some marginal OSs yell at you when they do not 
have
>> bash (just yesterday a Nix user had to comment on a five year old bug in 
that
>> is no longer valid as we went back to autoconf there too).  As an extra 
bonus
>> it c) also works on Slowlaris.

>> Best, Dirk

> Thank you, Ralf, and Dirk that was very useful already !

> However, the real problem I am fighting still is not related to
> `pkg-config` and friends at all, but to the fact that my OS has
> a version of libmpfr in the main system library and that seems
> to be used in *any* case when the final .so file is linked
> together:

> For me (on Fedora 30)

> $ R CMD config LDFLAGS
> -L/usr/lib64

> $ ls -l /usr/lib64/libmpfr*
> lrwxrwxrwx. 1 root root 16 Feb  2  2019 /usr/lib64/libmpfr.so -> 
libmpfr.so.4.1.6
> lrwxrwxrwx. 1 root root 16 Feb  2  2019 /usr/lib64/libmpfr.so.4 -> 
libmpfr.so.4.1.6
> -rwxr-xr-x. 1 root root 827872 Feb  2  2019 /usr/lib64/libmpfr.so.4.1.6

> and for that reason, when R CMD INSTALL Rmpfr ...

> gets to the final linking, it uses

> gcc -shared -L/usr/lib64 -o Rmpfr.so Ops.o  utils.o 
-L/usr/local.../mpfr/4.0.2/lib -lmpfr -lgmp

> and the early -L/usr/lib64  just "ensures" that my package lib
> (Rmpfr.so) is linked against  /usr/lib64/libmpfr.so.4.1.6  which
> is old and I "hate" rather than against the much better
> libmpfr.so.6.0.2 which would be found in /usr/local.../mpfr/4.0.2/lib

> Yes, on a machine with root permission I can hack around to get
> what I want,  but of course I'd really like   'R CMD INSTALL ..'
> to do the "right thing"
> just from my  configure  plus src/Makevars{.in}  files.
> Yes, I tried  'LDFLAGS = ' (to set it to "empty") in
> src/Makevars*  but that did not help either.

> Martin

I now finally did what most of us should do before posting here:
Carefully consulting the famous WRE "Writing R Extensions" R
Manual, notably the section ('1.2.1' currently),
named "Using Makevars" :
   https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars

and came to the conclusion that at least for now,
I have to revert to using a 'src/Makefile' instead of just
Makevars files, the main reason being that  R's own
/etc/Makevars  file is included *after* the package src/Makevars
file  and so it does not help if I (un)set LDFLAGS in the latter.

Thank you for listening - it helped me to get to a more systematic
answer (and if you find that my conclusion has been wrong, I'm
happy to hear about that).

Martin

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Martin Maechler]

> Sameh M Abdulah 
> on Fri, 30 Aug 2019 18:50:55 + writes:

> Hi,
> I recently asked some questions about my R package which were well 
responded by Dirk.

> I have another question related to pkg_config path,

> I am using this command to add the installation path to the 
PKG_CONFIG_PATH   so that all cmake commands can get the required libraries 
from this path,

> 
Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))

> Is there a simple way to set this path without explicitly calling this 
line before installing my package? OR is there any other path that I can use so 
that all software CMake commands can easily find the required libraries?

> --Sameh

Not an answer, but a  #METOO   with a hopefull very related
question, also on using 'pkg-config' (Note: "-", not "_" here)
for package configuration.

I'm maintainer of CRAN package Rmpfr (for arbitrary precise arithmetic..),
https://cran.r-project.org/package=Rmpfr
development & source on R-forge
 http://rmpfr.r-forge.r-project.org/
and  https://r-forge.r-project.org/scm/viewvc.php/pkg/?root=rmpfr
which "down there"  is principally an interface to the GNU MPFR
C library (which also needs the GNU  GMP C library).

I do have a  Rmpfr/configure.ac from which to produce
Rmpfr/configure which then ensures that both libraries (MPFR and GMP)
are found and are "working".
The 'configure' script then (supposedly, but not on Windows?) takes
either src/Makevars.in  (non-Windows)
or src/Makevars.win (Windows)
to produce  src/Makevars
which then is used during compilation of the C sources of my
package.

Notably it will contain   '-lmpfr -lgmp'  among the LDFLAGS in
any case.

Now back to the 'pkg-config' : The compiler *also* needs correct

-I  (the path used  by ' #include <...> ' statement)

and for linking a correct  -L.

Now, my main OS,  Linux Fedora (as all other decent Linux distributions)
does provide MPFR and GMP libraries (and include headers) as OS
packages, installed in  /usr/lib/ (actually /lib64 nowadays)
and /usr/include respectively.

However, for some reasons I don't know the *version* of the MPFR
library that the OS provides is outdate (to my taste), and I'd
really want a newer version of MPFR,  which I easily install in
a version of /usr/local/. *and* I also make sure that

pkg-config --libs mpfr
and pkg-config --cflags mpfr

list the corresponding LDFLAGS  and CFLAGS

(the first giving

  -L/usr/local.../mpfr/4.0.1/lib -lmpfr -lgmp 

 the 2nd

  -I/usr/local.../mpfr/4.0.1/include 
)

Now what is the officially / best way to have either 'configure'
or  Makevars.{in,win}  use the 'pkg-config' information
*dynamically*, i.e.,
if I update my MPFR from 4.0.1 to 4.0.2  the newer 4.0.2 is found ?

My current setup would not even work on some platforms to really
end up using my local version of MPFR instead of the system-wide
OS default (using /lib64 and /usr/include/ and then
which even with quite new Fedora 30 is still MPFR 3.1.6 .. much
too old for some of the things I want).

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

Re: [R-pkg-devel] Note on winbuilder-develop

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Wed, 24 Jul 2019 06:12:35 -0400 writes:

    > On 24/07/2019 3:08 a.m., Martin Maechler wrote:
>>>>>>> Roy Mendelssohn
>>>>>>> on Tue, 23 Jul 2019 18:44:24 -0700 writes:
>> 
>> > Thanks, I was looking at the raw files, not the .Rd files.
>> > There are \keyword arguments in those file, will have to
>> > search to see why they are getting generated.  -Roy
>> 
>> just to rub the obvious into everybody's face ;-) :-D
>> { apology for any offence ! } :
>> 
>> If you'd use roxygen only initially and not anymore from then
>> on, but rather then would keep hand-editing nicely humanly
>> formatted  man/*.Rd  files,
>> you would never see this (and quite a few "similar") problems.

> I don't think that's a great idea, unless the initial use is basically 
> no more than using prompt().  If you have comments in your source that 
> look like help text, and different help text in your Rd file, it's going 
> to lead to confusion.  I don't think Roxygen is capable of updating your 
> source file comments when you edit your Rd file.

> Duncan Murdoch

Ok,  now you're triggering me  ... probably I should have
refrained from that first e-mail  ...

What I *meant* and failed to say more explicitly:

I would use roxygen comments for functions I write
"somewhere", possibly outside a package and I do *not* export (yet?)
when inside a package.  Once I decide it should become an
exported function I use the roxygen stuff to create the very
first version of my help page *AND THEN* delete most of the
roxygen text comments (maybe leave 2 lines or so) and from then
on only use *.Rd files, which I keep nicely indented, and even *commented*
(is that possible at all inside roxygen?), add math
formula, add examples, enumeration lists, \describe{..} lists
etc in much more nicely readable form than wrapped inside the
"roxygen language"  and never go back to using Roxygen there.
The same with the nicely human-annotated and sorted  NAMESPACE
file.

As you know, R works from the NAMESPACE and man/*.Rd files
anyway, and so I don't add an extra translation layer .. and keep
*.Rd and NAMESPACE files that are both much nicer readable than
as part of roxygen comments blowing up the size of the *.R
source files.
By taking the *.Rd out of the source, I'm much less tempted to
keep the documentation minimal and almost unuseful, as I see it
in many packages built using Roxygen..

[... end of trigger]

Martin

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

Re: [R-pkg-devel] Note on winbuilder-develop

[Martin Maechler]

>>>>> Roy Mendelssohn 
>>>>> on Tue, 23 Jul 2019 18:44:24 -0700 writes:

> Thanks, I was looking at the raw files, not the .Rd files.
> There are \keyword arguments in those file, will have to
> search to see why they are getting generated.  -Roy

just to rub the obvious into everybody's face ;-) :-D
{ apology for any offence ! } :

If you'd use roxygen only initially and not anymore from then
on, but rather then would keep hand-editing nicely humanly
formatted  man/*.Rd  files, 
you would never see this (and quite a few "similar") problems.

Martin Maechler
ETH Zurich and  R Core

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

Re: [R-pkg-devel] "Progress reports" for examples in packages.

[Martin Maechler]

> Henrik Bengtsson 
> on Mon, 1 Jul 2019 20:36:26 -0700 writes:

> FWIW, when running R CMD check mypkg_1.0.tar.gz

> the example output is captured to the file
> 'mypkg.Rcheck/mypkg-Ex.Rout', so you could monitor that
> one for what's going on.

> /Henrik

Yes, indeed, that's what we have been doing "all the time";  e.g.,
on a unix-alike (or in a 'bash'-like (powershell?) on Windows);
you can   'tail -f /mypkg-Ex.Rout' in another shell/terminal

Martin

> On Mon, Jul 1, 2019 at 7:00 PM Rolf Turner
>  wrote:
>> 
>> 
>> I am currently working on a package such that when "R CMD
>> check" is run the procedure seems to disappear into a
>> black hole when it gets to the "* checking examples ..."
>> stage.
>> 
>> Strangely, when I run the examples individually, although
>> they take a rather long time, they do not take an
>> "endless" amount of time, so I am puzzled.  I would like
>> to be able to isolate where the hang-up is occurring so
>> that I can rectify the problem.
>> 
>> I guess I could, successively, wrap all but one of the
>> examples in \dontrun{} and see what happens in each case.
>> But this is rather tedious.  Is there any to get some
>> diagnostic output as to, e.g. which example is being
>> checked at the given moment?  Doing R CMD check --help
>> does not reveal any useful looking options.
>> 
>> Thanks for any tips.
>> 
>> cheers,
>> 
>> Rolf Turner
>> 
>> --
>> Honorary Research Fellow Department of Statistics
>> University of Auckland Phone: +64-9-373-7599 ext. 88276
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

Re: [R-pkg-devel] .Rd, LaTeX and Unicode

[Martin Maechler]

>>>>> Hugh Parsonage 
>>>>> on Tue, 18 Jun 2019 20:03:41 +1000 writes:

> utf8x is deprecated
> https://tex.stackexchange.com/questions/13067/utf8x-vs-utf8-inputenc#13070

Hmm... interestingly, I've tried quite a few versions of the
above which started in 2011, but had been updated in April 2016 :
   https://tex.stackexchange.com/a/203804/7228
from where it seems that

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

should be sufficient.  Further, note that from
  https://tex.stackexchange.com/a/238135/7228 
the {ucs} package should no longer be needed since ca. 2013,
hence your \usepackage[mathletters]{ucs}  would not be needed either.

HOWEVER:  After losing at least half an hour now, trying many
variants I found that the only version that works correctly for
me (with a teTeX / TeXlive version of 2018) is the version
Serguei Sokol proposes (below), including the use of the 'utf8x'
option *and* the 'ucs' package ...

which is pretty surprising after having read the
tex.statexchange threads ...

> On Tue, 18 Jun 2019 at 7:52 pm, Serguei Sokol 
> wrote:

>> Hi,
>> 
>> I am preparing a package where I would like to use UTF characters in .Rd
>> files. When the LaTeX comes to play, I got well known errors e.g.:
>> ! Package inputenc Error: Unicode character ∂ (U+2202)
>> (inputenc)not set up for use with LaTeX.
>> 
>> It is coherent with what is said on this page
>> https://developer.r-project.org/Encodings_and_R.html :
>> "Since LaTeX cannot handle Unicode we would have to convert the encoding
>> of latex help files or use Lambda (and tell it they were in UTF-8)."

That whole document has been very important and crucial, written
by Prof Brian Ripley  who had worked a *LOT* to bring unicode to R,
-- but it has been written 2004-2005  and indeed, I think it is
probably fair to say that the above sentence no longer applies
to current LaTeX engines (including "simple" pdflatex)... though really,
I'm not the expert here, but I think it's a good point in time
to reconsider how much UTF8 should be allowed/supported in *.Rd files.

One problem: This is (slightly) the wrong mailing list; this would have
been a perfect topic for 'R-devel' (discussing about new
features etc for R) instead
( but we'd rather keep it here for now.)

Martin Maechler
ETH Zurich and R Core Team



>> But LaTeX can support UTF8 as shown with this small example:

 \documentclass{article}
 \usepackage[mathletters]{ucs}
 \usepackage[utf8x]{inputenc}
 
 \begin{document}
 The vorticity ω is defined as $ω = ∇ × u$.
 \end{document}

>> I can compile it with my LaTeX without problem. May be you too?
>> So my suggestion would be to place these two lines somewhere in LaTeX
>> header generated by R doc system:
>> \usepackage[mathletters]{ucs}
>> \usepackage[utf8x]{inputenc}
>> 
>> Note "utf8x" and not just "utf8" which is crucial for this example.
>> With a hope that it would fix unicode errors from LaTeX.
>> 
>> Best,
>> Serguei.

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

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

[Martin Maechler]

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

> Mark,
> I used

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

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

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

   RNGversion("3.5.0")

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

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

Martin


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

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

Martin


> Best, Ulrike

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


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

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

__
R-package-devel@r-project.org mailing list

Re: [R-pkg-devel] package cartograflow_0.0.0.9000.tar.gz

[Martin Maechler]

> cartograflow@gmail com 
> on Wed, 3 Apr 2019 18:11:10 + writes:

> Hi, 
> I come back to you  because I have always the problem with 
devtools::check of my package. 

But we've told you repeatedly now *NOT* to use it in this case, but
rather use

R CMD build ...
and R CMD check --as-cran ...   

> I used the command to check my package with R-devel : 
> sylvain@sylvain:~/svn$ bash R-devel.sh CMD check --as-cran 
/home/sylvain/work/12_R_studio/package/cartograflow_0.0.0.1.tar.gz

> When I start the rmd file there is a warning due to package dplyr : 
> Attaching package: 'dplyr'
> The following objects are masked from 'package:stats':
>     filter, lag
> The following objects are masked from 'package:base':
>     intersect, setdiff, setequal, union

> The solve this issue I added in rmd file, description file and the 
namespace the package conflicted. 
> So, the package conflicted avoid to have this warning. 

> But when I run R-devel CMD check I have a new issue that is Error in 
loadNamespace...no package called ‘conflicted’ (see below)

> Can you help me to solve this issue if tit's possible? 
> Thanks in advance to your help ! 
> Sylvain
> -
> Below extract of 00check.log 
> * checking whether package ‘cartograflow’ can be installed ... ERROR
> Installation failed.
> See ‘/home/sylvain/svn/cartograflow.Rcheck/00install.out’ for details.
> * DONE
> Status: 1 ERROR, 1 NOTE

> Below 00install.out 
> * installing *source* package ‘cartograflow’ ...
> ** using staged installation
> ** R
> ** inst
> ** byte-compile and prepare package for lazy loading
> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = 
vI[[i]]) : 
>   there is no package called ‘conflicted’
> Calls:  ... loadNamespace -> withRestarts -> withOneRestart -> 
doWithOneRestart
> Exécution arrêtée
> ERROR: lazy loading failed for package ‘cartograflow’
> * removing ‘/home/sylvain/svn/cartograflow.Rcheck/cartograflow’







> Le mardi 26 mars 2019 à 22:42:21 UTC+1, Henrik Bengtsson 
 a écrit :  
 
> FWIW, you should be able to reproduce at least the following NOTEs
> with your current R 3.5.2 and R CMD check --as-cran:

> * checking CRAN incoming feasibility ... NOTE
> Maintainer: ‘cartogRaflow ’

> New submission

> Version contains large components (0.0.0.9000)

> Possibly mis-spelled words in DESCRIPTION:
>   flowmapping (7:41)

> Author field should be Authors@R.  Current value is:
>   c(person("Françoise", "Bahoken", email =
> "francoise.baho...@ifsttar.fr", role = c("cre","aut")),
>             person("Sylvain", "Blondeau", email =
> "blondeau.sylv...@yahoo.fr", role = c("aut"))

> The Title field should be in title case. Current version is:
> ‘thematic cartography of flows and movements’
> In title case that is:
> ‘Thematic Cartography of Flows and Movements’

> Those are all classical mistakes ("we've all been there").  The
> vignette errors may or may not be specific to R devel.

> /Henrik

> On Tue, Mar 26, 2019 at 2:29 PM cartograf...@gmail.com
>  wrote:
>> 
>> Hi,  l've made R CMD check --as-cran on rstudio 3.5.2Why I have to use 
r-devel?
>> I confirm that I didn't received à error message when I've made 
dev_tool::check.
>> How can I solve my problem ?
>> Thanks in advance Sylvain
>> 
>> 
>> nvoyé depuis Yahoo Mail pour Android
>> 
>>   Le lun., mars 25, 2019 à 23:38, Uwe 
Ligges a écrit :  I cannot beloeve it. But 
this is certainly not R-devel?
>> 
>> Not sure about devtools which we do not use on CRAN, but simply
>> 
>> R CMD check --as-cran
>> 
>> with a recent R-devel  version on the package tarball should reproduce
>> the findings.
>> 
>> Best,
>> Uwe Ligges
>> 
>> 
>> On 25.03.2019 23:12, cartograf...@gmail.com wrote:
>> > Hello,
>> > I've submitted my package cartograflow and I received an email from 
your teeam that it does not pass the incoming checks automatically.Debian: 

>> > Status: 1 ERROR, 2 WARNINGs, 1 NOTE
>> >
>> > So, I've made the new check on my plateform (linux ubuntu) and the 
check is OK.I used : ==> devtools::check(args = 
c('--no-manual','--as-cran'))Status is :
>> > ── R CMD check results  cartograflow 
0.0.0.9000 
>> > Duration: 54.6s
>> > 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
>> > R CMD check succeeded
>> > Can you  help me to fix the problem?
>> > Thanks in advance to your replySylvain
>> >    [[alternative HTML version deleted]]
>> >
>> > 

Re: [R-pkg-devel] Cran submission - warning with windows (cpp build library gmp)

[Martin Maechler]

> Kevin Ushey 
> on Fri, 22 Feb 2019 10:09:15 -0800 writes:

> The 'long long' type does not exist in the C++98
> standard, so you need to explicitly request C++11 or
> C++14 (the former which is now fairly broadly supported
> across compilers on different systems).

> For more detail, see in the R extensions manual:

> 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-C_002b_002b11-code

> Best, Kevin

Indeed, thank you, Kevin.

In this case, it simply needs an extra line
   CXX_STD = CXX11
added to gmp/src/Makevars.in
(already done now).

Martin

> On Fri, Feb 22, 2019 at 5:08 AM Antoine Lucas
>  wrote:

>> Dear all
>> 
>> I would like to update gmp package - this package link to
>> a c++ library gmp.
>> 
>> But windows c++ compilation warns at:
>> d:/Compiler/gcc-4.9.3/local330/include/gmp-x64.h:140:23:
>> warning: ISO C++ 1998 does not support 'long long'
>> [-Wlong-long]
>> 
>> I have not this warning on linux.  On my computer I build
>> latest version on gmplib, and header is a little
>> different and should not define a long long. I wonder if
>> the warning could be fixed by an update of external c++
>> library gmp.
>> 
>> How could I fix my package in order to pass the cran
>> submission ?
>> 
>> Regards,
>> 
>> Antoine Lucas
>> 
>> gmp.h at line 140: #ifdef __GMP_SHORT_LIMB typedef
>> unsigned int mp_limb_t; typedef int mp_limb_signed_t;
>> #else #ifdef _LONG_LONG_LIMB typedef unsigned long long
>> int mp_limb_t; typedef long long int mp_limb_signed_t;
>> #else typedef unsigned long int mp_limb_t; typedef long
>> int mp_limb_signed_t; #endif #endif

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

Re: [R-pkg-devel] New CRAN internet policy

[Martin Maechler]

> Hadley Wickham 
> on Thu, 6 Dec 2018 10:22:47 -0600 writes:

> Hi all,
> I'd love to get some clarification on what the new internet policy
> means for packages like httr:

>> Packages which use Internet resources should fail gracefully with an 
informative
>> message if the resource is not available (and not give a check warning 
nor error).

> It's not clear what "internet resource" means here? If it means
> dataset, then I think the httr tests and examples are ok. If it means
> any use of the internet, I'm not sure what do - httr critically
> depends on internet access, so I can't see any way to make it fail
> gracefully.

> Hadley

I cannot answer your question, notably as I'm not part of the CRAN
team, but as R Core developer, I've encountered the problem
many times which this policy tries to mitigate
(but I also think we should consider to go further than the
 above "policy") :

As R developer, I'd like to see the effect of a change to the
sources of base R, and so eventually, I may want to run the
equivalent of 'R CMD check' on all existing CRAN and
Bioconductor packages. If I have access to a server with many
cores and very fast hard disks, I can hope to finish running the
tests with 1--2 days.
But then I have to deal with the result.  The few times I've
done this, the result has been "a mess" because many many
packages  nowadays assume in their examples and their regression/unit
tests that internet access to some resources works, ... which it
"often" does not, and so  download.file(),
read.table("http://.;) etc result in errors sooner or later.

Because of that some packages fail their checks "randomly" (in
the sense that internet resources are not available "randomly").
Ideally we'd find a very good way that these failures are
communicated back to the person / process running (a version of)
'R CMD check', because in the above scenario, I'd like to weed
out the 300 packages that just failed because of internet
resource access failures,  and only look at the other packages
that got a change in their 'R CMD check' results.

The recent introduction in R-devel of classed error conditions
(in some cases), e.g., 
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2018/10/04#n2018-10-04,
  and the similar and somewhat earlier
effort of Lionel Henry to use classed error conditions (in
rlang only, unfortunately, rather than as a patch proposal to R ..)
maybe one step towards a nice solution here.

Ideally we'd not just get  'ERROR'  in the check 'Status:' line,
but qualified errors, and if for a package the only errors are caused by
internet resource access failures, I could easily filter them out.

Martin

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

Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION meta-information" when I run devtools::build_win()

[Martin Maechler]

>>>>> Eggleston, Barry 
>>>>> on Wed, 25 Jul 2018 21:53:30 + writes:

> This is great news Roman.
> The "rth" role stands for "Research team head", and I got it from the 
http://www.loc.gov/marc//relators/relaterm.html website.

and it *IS*  a correct role also in R,  using non-API function
(non-API: do *not* use it in reproducible code, pkgs, etc !) :

  > utils:::.canonicalize_person_role("rth")
  [1] "rth"

tells us that this is a correct role,
whereas these are not :

> utils:::.canonicalize_person_role("Rth")
character(0)
Warning message:
In utils:::.canonicalize_person_role("Rth") :
  Invalid role specification: ‘Rth’.
> utils:::.canonicalize_person_role("Foobar")
character(0)
Warning message:
In utils:::.canonicalize_person_role("Foobar") :
  Invalid role specification: ‘Foobar’.
> 

So the bug is really in the Windows version of R that was
running for you when you've used devtools::build_win()   or in
build_win()  itself.

"rth" is a correct role and you should *NOT* replace it by
something less appropriate ...

Martin Maechler
ETH Zurich and R Core Team


> This issue here is Diane Catellier provided the funds and management for 
us to develop this package.  I did not know about the person() function.  When 
I looked at the help page for person(), I see that I can use "fnd" for funder 
and that will define Diane's role sufficiently well.  I'll make the change and 
run through my checks again.

> Thank you,
> Barry

> -Original Message-
> From: Roman Flury  
> Sent: Wednesday, July 25, 2018 5:27 PM
> To: Eggleston, Barry 
> Cc: Hugh Parsonage ; 
r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION 
meta-information" when I run devtools::build_win()

> Barry,

> sorry did not anticipate the behaving of the emailer. I could reproduce 
your error with the DESCRIPTION file below with a helloworld pkg

> Package: test
> Type: Package
> Title: What the Package Does (Title Case)
> Version: 0.1.0
> Authors@R: c(person("Roman", "Flury", email = "roman.fl...@math.uzh.ch", 
role = c("aut", "cre")),
>  person("Test", "person", email = "testm...@test.org", role = 
c("fnd", "rth")))
> Description: Short description to describe this package.
> Depends: R (>= 3.5.0)
> License: GPL-3
> Encoding: UTF-8
> LazyData: true
> Imports: eha (>= 2.5.1),
>     ggplot2 (>= 2.2.1),
>     survival (>= 2.41-3),
>     reshape2 (>= 1.4.3),
>     stats (>= 3.5.0)
> RoxygenNote: 6.0.1

> this passes R CMD check --as-cran on a unix system, but not on windwos. 
> The problem seems to be the role "rth", which is also not listed in 
?person. What does this role stand for?

> best, Roman

> On 25.07.2018 16:21, Eggleston, Barry wrote:
>> Roman,
>> 
>> Not sure why my emailer added all those <mailto:a...@bbb.ccc> items, but 
none of them are in my original DESCRIPTION file.  So my Maintainer line, for 
example, simply reads Barry Eggleston , where email address is 
simply beggles...@rti.org.
>> 
>> Thanks for the observation,
>> Barry
>> 
>> 
>> -Original Message-
>> From: Roman Flury 
>> Sent: Wednesday, July 25, 2018 9:42 AM
>> To: Eggleston, Barry 
>> Cc: Hugh Parsonage ; 
>> r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION 
>> meta-information" when I run devtools::build_win()
>> 
>> Hello,
>> 
>> after https://cran.r-project.org/doc/manuals/r-release/R-exts.html the 
‘Maintainer’ field should give a single name followed by a valid (RFC 2822) 
email address in angle brackets.
>> but beggles...@rti.org<mailto:beggles...@rti.org> is not a valid RFC 
>> 2822 email address, you could check this for instance with 
>> https://proxy2.de/email-validation.php
>> 
>> you could omit the 'Maintainer' field, since a suitable ‘Authors@R’ 
field is given..
>> does this solve your problem?
>> 
>> best, Roman
>> 
>> - Original Message -
>> From: "Eggleston, Barry" 
>> To: "Hugh Parsonage" 
>> Cc: r-package-devel@r-project.org
>> Sent: Wednesday, July 25, 2018 3:00:35 PM
>> Subject: Re: [R-pkg-devel] Get an 

Re: [R-pkg-devel] Conditional use of suggested package in example code

[Martin Maechler]

> Christian Sigg 
> on Wed, 30 May 2018 11:08:38 +0200 writes:

> I am updating the ’nsprcomp’ package to follow the recommendations of 
Section 1.1.3.1 of the Writing R Extensions manual.
> Before the update, the example code for the `nsprcomp` function looked 
like this:

>> library(MASS)
>> set.seed(1)
>> 
>> # Regular PCA, with the tolerance set to return five PCs
>> prcomp(Boston, tol = 0.36, scale. = TRUE)
>> 
>> # Sparse PCA with different cardinalities per component. The number of 
components
>> # is derived from the length of vector k.
>> nsprcomp(Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
>> 
>> (…)

First, a only a "stylistic" remark to you (and many others):
If you only need a dataset from a package, you typically should not attach the
package [to the search() path] via library()/require(), but typically use

   data(Boston, package="MASS")

which only loads MASS' namespace *and* is self-describing that
indeed you only use MASS for getting that data set.

... but see below for your real question

> The unconditional use of the suggested package ‘MASS’ produces an error 
on systems where ‘MASS’ is not installed. 

> I personally think that this is fine in an interactive session. The error 
makes it obvious what the user has to do to run the example - install the 
missing package. But I understand that it would increase the complexity of 
automated checking of examples, where one would have to distinguish between 
this kind of error and an actual bug in the example code.

> In any case, the WRE manual recommends conditional use of suggested 
packages via `requireNamespace`. A straightforward way to follow the 
recommendation is to wrap the whole example in a conditional statement:

>> if (requireNamespace("MASS", quietly = TRUE)) {
>> set.seed(1)
>> 
>> # Regular PCA, with the tolerance set to return five PCs
>> prcomp(MASS::Boston, tol = 0.36, scale. = TRUE)
>> 
>> # Sparse PCA with different cardinalities per component. The number of 
components
>> # is derived from the length of vector k.
>> nsprcomp(MASS::Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
>> 
>> (…)
>> }

> I don’t like this for two reasons:

> 1. The if statement and the indentation add clutter to the example code, 
making the help page harder to read.

> 2. The if statement breaks the output of `example(“nsprcomp”, 
“nsprcomp”)`. Now only the statement before the closing curly brace has its 
output printed to the console. I would have to add explicit print statements 
that further clutter up the example.

> Is there a coding pattern that satisfies the WRE recommendations, but 
avoids these two problems?

A very good question:

I have introduced the function   withAutoprint( . )  into R 3.4.0  
to address your '2.'  -- not perfectly but at least
transparently,
so the if would going to be

  if (requireNamespace("MASS", quietly = TRUE)) withAutoprint({


  })

{and you'd have to add  'Depends: R (>= 3.4.0)'}

To address '1.'  you could wrap  \dontshow{ * } around the two
if()-related lines in your example code which makes the code
*look* better to the help page readers. 

These two "techniques" together get you quite far, though I
agree it's a bit of fiddling..

Last but not least - of course you know that, I'm just stating
the obvious here:  The small 'datasets' that comes with R
does not need any conditionals (nor does simple random-generated
data that you could use).

Best,
Martin


> Regards
> Christian

> —
> Christian Sigg
> https://sigg-iten.ch/research

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

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

Re: [R-pkg-devel] Creating S3 methods for S4 classes

[Martin Maechler]

>>>>> Georgi Boshnakov 
>>>>> on Thu, 24 May 2018 16:07:43 + writes:

> Hi Joris, At least some aspects of this topic are of
> interest on this list, given its complexity.

I'm sorry, Georgi, but "of interest" (to some readers) still
does not make this the correct mailing list for the topic,
rather really *does* belong to R-devel instead :

This has been about 

- if an S4 generic for "predict" and similar
  generics should be instantiated in the (base R) 'stats4' package
  (==> change of R, not of a developer's package)

- and about good strategies to define S3 and S4 methods and generics
  (==> general advanced R programming, not directly related get a
   package accepted by CRAN standards)

Followups please on R-devel
((Unfortunately, because of severe spamming of people posting to
  the list, we have delayed archiving the official archives considerably for 
now;
  to still see the current thread on R-devel, you can use one of
  the *other* archives: ==> https://marc.info/?t=15271693562=1=2 ))


Best,
Martin Maechler

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

Re: [R-pkg-devel] File link does not exist : how to get the correct one?

[Martin Maechler]

> Duncan Murdoch 
> on Fri, 18 May 2018 11:42:53 -0400 writes:

> On 18/05/2018 11:37 AM, Duncan Murdoch wrote:
>> On 18/05/2018 11:29 AM, Duncan Murdoch wrote:
>>> On 18/05/2018 11:06 AM, Joris Meys wrote:
 Hi all,
 
 The latest changes in R cause a lot of Rd warnings about file links 
that
 don't exist and are treated as a topic. One example is
 
 \code{\link[stats]{fitted}}
 
 Now if I look at ?fitted , the name of the page (top left corner) is 
given
 as "fitted". So I would expect that the code above should just work 
fine,
 but it generates the warning.
 
 How can one get these names without having to browse through the 
directory
 with html files?
>>> 
>>> You could ask for HTML help on fitted, but don't use the class print 
method:
>> 
>> Sorry, forgot to edit that out:  it doesn't need to be HTML help, any
>> format would do.

> And this should be my last message on the topic:  a nicer solution is 
> simply to use basename():

>> basename(?fitted)
> [1] "fitted.values"

> Duncan Murdoch

Wow ... Awesome!

I had no idea about such an elegant a solution to this
problem...

Martin

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

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

[Martin Maechler]

> William Dunlap 
> on Thu, 17 May 2018 11:28:50 -0700 writes:

> Your explanation needs to be a bit more general in the
> case of identical eigenvalues - each distinct eigenvalue
> has an associated subspace, whose dimension is the number
> repeats of that eigenvalue and the eigenvectors for that
> eigenvalue are an orthonormal basis for that subspace.
> (With no repeated eigenvalues this gives your 'unique up
> to sign'.)

Thank you, Bill, notably for the concrete example of non-trivial
eigenspaces (per eigenvector). 
Note I did say

  "... such that at least for the good cases where all eigenspaces
   are 1-dimensional, ..."

knowing well that only in that case it "is easy".
I have a gut feeling but may be wrong that such simplistic post
processing may also help (to get cross-platform reproducibility)
in the case of MASS::mvrnorm() where repeated eigenvalues will
be common in practice.

Martin

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

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Thu, 17 May 2018 12:13:01 -0400 writes:

> On 17/05/2018 11:53 AM, Martin Maechler wrote:
>>>>>>> Kevin Coombes ... on Thu, 17
>>>>>>> May 2018 11:21:23 -0400 writes:

>>[..]

>> > [3] Should the documentation (man page) for "eigen" or
>> > "mvrnorm" include a warning that the results can change
>> > from machine to machine (or between things like 32-bit and
>> > 64-bit R on the same machine) because of difference in
>> > linear algebra modules? (Possibly including the statement 
>> > that "set.seed" won't save you.)

>> The problem is that most (young?) people do not read help
>> pages anymore.
>> 
>> help(eigen) has contained the following text for years,
>> and in spite of your good analysis of the problem you
>> seem to not have noticed the last semi-paragraph:
>> 
>>> Value:
>>> 
>>> The spectral decomposition of ‘x’ is returned as a list
>>> with components
>>> 
>>> values: a vector containing the p eigenvalues of ‘x’,
>>> sorted in _decreasing_ order, according to ‘Mod(values)’
>>> in the asymmetric case when they might be complex (even
>>> for real matrices).  For real asymmetric matrices the
>>> vector will be complex only if complex conjugate pairs
>>> of eigenvalues are detected.
>>> 
>>> vectors: either a p * p matrix whose columns contain the
>>> eigenvectors of ‘x’, or ‘NULL’ if ‘only.values’ is
>>> ‘TRUE’.  The vectors are normalized to unit length.
>>> 
>>> Recall that the eigenvectors are only defined up to a
>>> constant: even when the length is specified they are
>>> still only defined up to a scalar of modulus one (the
>>> sign for real matrices).
>> 
>> It's not a warning but a "recall that" .. maybe because
>> the author already assumed that only thorough users would
>> read that and for them it would be a recall of something
>> they'd have learned *and* not entirely forgotten since
>> ;-)
>> 

> I don't think you're really being fair here: the text in
> ?eigen doesn't make clear that eigenvector values are not
> reproducible even within the same version of R, and
> there's nothing in ?mvrnorm to suggest it doesn't give
> reproducible results.

Ok, I'm sorry ... I definitely did not want to be unfair.

I've always thought the remark in eigen was sufficient,  but I'm
probably wrong and we should add text explaining that it
practically means that eigenvectors are only defined up to sign
switches (in the real case) and hence results depend on the
underlying {Lapack + BLAS} libraries and therefore are platform
dependent.

Even further, we could consider (optionally, by default FALSE)
using defining a deterministic scheme for postprocessing the current
output of eigen such that at least for the good cases where all
eigenspaces are 1-dimensional, the postprocessing would result
in reproducible signs, by e.g., ensuring the first non-zero
entry of each eigenvector to be positive.

MASS::mvrnorm()  and  mvtnorm::rmvnorm() both use "eigen",
whereas mvtnorm::rmvnorm()  *does* have  method = "chol" which
AFAIK does not suffer from such problems.

OTOH, the help page of MASS::mvrnorm() mentions the Cholesky
alternative but prefers eigen for better stability (without
saying more).

In spite of that, my personal recommendation would be to use

  mvtnorm::rmvnorm(.., method = "chol")

{ or the 2-3 lines of R code to the same thing without an extra package,
  just using rnorm(), chol() and simple matrix operations }

because in simulations I'd expect the var-cov matrix  Sigma to
be far enough away from singular for chol() to be stable.

Martin

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

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

[Martin Maechler]

>>>>> Kevin Coombes <kevin.r.coom...@gmail.com>
>>>>> on Thu, 17 May 2018 11:21:23 -0400 writes:

> Hi, I wrote and maintain the Thresher package. It includes
> code to do simulations. In the "tests" directory of the
> package, I do some simple simulations and run the main
> algorithm, then write out summaries of the results

> The initial submission of the package to CRAN was delayed
> because the "Rout.save" files matched the "Rout" files on
> 64-bit R but *not* on 32-bit R on Windows. After
> investigating, I realized that when my simulation code
> called "MASS::mvrnorm", I got different results from
> 64-bit and 32-bit versions of R on the same machine.
> Pushing further, I determined that this was happening
> because mvrnorm used "eigen" to compute the eigenvalues
> and eigenvectors, and "eigen" itself gave different
> answers in the two R versions..

> The underlying issue (mathematically) is that the
> correlation/covariance matrix I was using had repeated
> eigenvalues, and so there is no unique choice of basis for
> the associated eigenspace. This observation suggests that
> the issue is potentially more general than 32-bit versus
> 64-bit; the results will depend on the implementation of
> the eigen-decomposition in whatever linear algebra module
> is compiled along with R, so it can change from machine to
> machine.

> I "solved" (well, worked around) the immediate problem
> with package submission by changing the test code to not
> write out anything that might differ between versions.

> With all of that as background, here are my main
> questions:

> [1] Is there any way to put something into the "tests"
> directory that would allow me to use these simulations for
> what computer scientists call regression testing? (That
> is, to make sure my changes to the code haven't changed
> results in an unexpected way.)

> [2] Should there be a flag or instruction to R CMD check
> that says to only run or interpret this particular test on
> a specific version or machine? (Or is there already such a
> flag that I don't know about?)

> [3] Should the documentation (man page) for "eigen" or
> "mvrnorm" include a warning that the results can change
> from machine to machine (or between things like 32-bit and
> 64-bit R on the same machine) because of difference in
> linear algebra modules? (Possibly including the statement
> that "set.seed" won't save you.)

The problem is that most (young?) people do not read help pages
anymore.

help(eigen) has contained the following text for years, and in
spite of your good analysis of the problem you seem to not have
noticed the last semi-paragraph:

> Value:
> 
>  The spectral decomposition of ‘x’ is returned as a list with
>  components
> 
>   values: a vector containing the p eigenvalues of ‘x’, sorted in
>   _decreasing_ order, according to ‘Mod(values)’ in the
>   asymmetric case when they might be complex (even for real
>   matrices).  For real asymmetric matrices the vector will be
>   complex only if complex conjugate pairs of eigenvalues are
>   detected.
> 
>  vectors: either a p * p matrix whose columns contain the eigenvectors
>   of ‘x’, or ‘NULL’ if ‘only.values’ is ‘TRUE’.  The vectors
>   are normalized to unit length.
> 
>   Recall that the eigenvectors are only defined up to a
>   constant: even when the length is specified they are still
>   only defined up to a scalar of modulus one (the sign for real
>   matrices).

It's not a warning but a "recall that" .. maybe because the
author already assumed that only thorough users would read that
and for them it would be a recall of something they'd have
learned *and* not entirely forgotten since ;-)

Martin Maechler
ETH Zurich

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

Re: [R-pkg-devel] vignette via devtools: sometimes found, sometimes not (same package)

[Martin Maechler]

>>>>> Thierry Onkelinx <thierry.onkel...@inbo.be>
>>>>> on Fri, 20 Apr 2018 09:14:44 +0200 writes:

> Dear Alex, Another idea is to use pkgdown
> (http://pkgdown.r-lib.org) to convert all the
> documentation of your package (include the vignettes) into
> a website. Then you make that available to your students,
> e.g. through github pages.

Hmm, sounds nice .. at first:  In teaching (and research!) I particularly
emphasize people use CRAN (or Bioconductor) packages.

Why on earth is pkgdown not on CRAN ?

Martin Maechler
ETH Zurich

> Best regards,

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




> 2018-04-19 18:33 GMT+02:00 Alexandre Courtiol
> <alexandre.court...@gmail.com>:
>> Thanks a lot Thierry, I was happy to discover and
>> implement a "drat" installation workflow.  Unfortunately
>> it did not solve the issue (but I will stick to drat).
>> Also, I checked the sessionInfo() and could not find any
>> package version discriminating accurately between
>> computers that shows vignettes from those who do not.
>> Only Windows computer have the issue but this proves
>> nothing (and other computers with the same OS version are
>> fine).  Goergi, I did not yet retried outside RStudio (I
>> am trying not to waste too much time at the beginning of
>> each course...  I wish I could hijack a problematic
>> laptop but they don't let me do it as they need them).
>> ++ Alex
>> 
>> 
>> On 17 April 2018 at 10:42, Thierry Onkelinx
>> <thierry.onkel...@inbo.be> wrote:
>>> 
>>> Dear Alex,
>>> 
>>> Have a look at drat
>>> (http://eddelbuettel.github.io/drat/DratForPackageAuthors.html). This
>>> makes it easier to distribute prepackaged R packages
>>> (including When you uploaded a new version, then the
>>> student would only have to do drat::addRepo("your_repo")
>>> and then install.pakages("LM2GLMM") or update.packages()
>>> 
>>> Best regards,
>>> 
>>> 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
>>> 
>>> 
///
>>> 
>>> 
>>> 
>>> 
>>> 2018-04-16 19:38 GMT+02:00 Alexandre Courtiol
>>> <alexandre.court...@gmail.com>: > Re,
>>> >
>>> > On 16 April 2018 at 17:35, Georgi Boshnakov < >
>>> georgi.boshna...@manchester.ac.uk> wrote:

Re: [R-pkg-devel] Rd files: using \link[pkg]{foo} when file names differ between OSs

[Martin Maechler]

>>>>> Duncan Murdoch <murdoch.dun...@gmail.com>
>>>>> on Mon, 16 Apr 2018 11:52:10 -0400 writes:

> On 16/04/2018 11:35 AM, Ramon Diaz-Uriarte wrote:
>> Dear All,
>> 
>> Two recent threads in the bioconductor devel mailing list
>> (https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html
>> and
>> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013259.html)
>> are related to packages that have different names of html
>> files in different operating systems.
>> 
>> For example, parallel has a file called mclapply in
>> Linux. So using, from the Rd file of another package,
>> \link[parallel]{mclapply} works fine under Linux, but
>> does not under Windows, because there is no mclapply.html
>> file in Windows (there is a mcdummies file).
>> 
>> 
>> Is there any recommended way to proceed in these cases?
>> 
>> 
>> Yes, section 2.5 of Writing R Extensions indicates that
>> \link[pkg]{foo} and \link[pkg:bar]{foo} are rarely
>> needed; so the simplest way to proceed would be to avoid
>> \link[pkg]{foo} and \link[pkg:bar]{foo}. I am asking for
>> the cases where, as noted in 2.5, "more than one package
>> offers help on a topic".

> You could make the links conditional on the OS.  For example,

> #ifdef windows
> See \link[parallel]{mcdummies}.
> #endif
> #ifdef unix
> See \link[parallel]{mclapply}.
> #endif

> The other possibility (useful if there are major differences between the 
> platforms) is to have two copies of the help file, one in man/unix, one 
> in man/windows, but that doesn't seem appropriate from your description.

> Duncan Murdoch

and mid-term, I really think R and (CRAN, Bioc, ...) packages
should not do what we (R core) did here.
Rather,  \alias{mclapply}  should exist both for windows and
non-windows, and hence \link{mclapply}  would just work.

Martin Maechler


>> Thanks,
>> R.

>> --
>> Ramon Diaz-Uriarte
>> Department of Biochemistry, Lab B-25
>> Facultad de Medicina
>> Universidad Autónoma de Madrid
>> Arzobispo Morcillo, 4
>> 28029 Madrid
>> Spain

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

Re: [R-pkg-devel] Warning: rBind is deprecated

[Martin Maechler]

>From a small thread over at the 'R-package-devel' mailing list,

this now goes to the R-devel mailing list
(CC'ing the original R-package-devel very exceptionally). 

Note that I, as maintainer("Matrix") had introduced rBind() and
cBind() to be used for Matrix package matrices as substitute for
rbind() and cbind() because back then it was not reasonably
possible to provide S4 methods for these.

But for almost three years now, they have been deprecated,
unfortunately *not* with a warning [which was a lapsus of mine].
The help page for these has started, for a long time now, as

| cBind  package:Matrix  R Documentation
| 
| Versions of 'cbind' and 'rbind' recursively built on cbind2/rbind2
| 
| Description:
| 
|  The base functions ‘cbind’ and ‘rbind’ are defined for an
|  arbitrary number of arguments and hence have the first formal
|  argument ‘...’.  For that reason, in the past S4 methods could
|  easily be defined for binding together matrices inheriting from
|  ‘Matrix’.
| 
|  For that reason, ‘cbind2’ and ‘rbind2’ have been provided for
|  binding together _two_ matrices, and we have defined methods for
|  these and the ‘'Matrix'’-matrices.
| 
|  Before R version 3.2.0 (April 2015), we have needed a substitute
|  for _S4-enabled_ versions of ‘cbind’ and ‘rbind’, and provided
|  ‘cBind’ and ‘rBind’ with identical syntax and semantic in order to
|  bind together multiple matrices (‘"matrix"’ or ‘"Matrix"’ and
|  vectors.  With R version 3.2.0 and newer, ‘cBind’ and ‘rBind’ are
|  _deprecated_ and produce a deprecation warning (via
|  ‘.Deprecated’), and your code should start using ‘cbind()’ and
|  ‘rbind()’ instead.

and finally, the next version of Matrix, which will be the
(recommended, hence bundled) Matrix package for R version 3.5.0
will produce warnings -- only once per session -- whenever
cBind() or rBind() are still used. 

This currently is true e.g., for lme4 and also for another
several dozens of CRAN packages, and unknown but probably
non-zero number of bioconductor packages.

There are even two CRAN packages which in their tests turn every
warning into an error and these packages will even fail their 'R
CMD check' in about a month when R 3.5.0 will appear.

Please package authors, do update the source of your packages:

a) replace  cBind() by cbind()  and rBind() by rbind()
b) Ensure that your package depends on at least R 3.2.0,
   i.e. possibly add a
  'Depends: R (>= 3.2.0)'
   to your DESCRIPTION file.

Of course feel free to comment / ask
privately or here {R-devel only} if necessary.

With best regards,

Martin Maechler
ETH Zurich

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

Re: [R-pkg-devel] Working with R-devel

[Martin Maechler]

> Uwe Ligges 
> on Wed, 24 Jan 2018 11:23:50 +0100 writes:

> On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
>> 
>> I am going in circles here and have lost my way. I used to have means to
>> build R-devel (still do) and use it for local testing (no longer do).
>> 
>> - Fresh build of R-devel
>> - One entry in .libPaths()
>> - I can install Rcpp, it ends up in that .libPaths()
>> - I can load
>> - With the _exact same settings_ starting R as R CMD check ... I fail on
>> 
>> ** preparing package for lazy loading
>> Error : package ‘Rcpp’ was installed by an R version with different 
internals; \
>> it needs to be reinstalled for use with this R version

> I guess you actually pick up anotehr version of R.
> Carefully check what is on your PATH and perhaps some Renviron files 
> that may be around?

> Best,
> Uwe

Yes exactly.  I've been bitten many times by similar issues in
recent weeks.

The problem here is that we have so many environment variables
governing the process.
I think I have mostly solved this by the following "strategy"
(Linux/Unixy bash-like shell):

--

## To check: one of 
env | grep '^R_'
env | grep -E '^_?R_'

## Before running:
unset R_PROFILE R_ENVIRON R_LIBS
export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel

## where my  check.Renviron*  basically only sets R_LIBS 
-

[In an ideal world, R functions involved here would *not* start
 other R processes...  but that seems necessary for other good reasons]

Martin



>> 
>> which is both false (see above) and irritating.
>> 
>> Does anybody have any tips, working guidelines or interpretations of the 
ever
>> changing manuals (which charmingly never document what changes) ?
>> 
>> Dirk
>> 

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

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

Re: [R-pkg-devel] Exited with status -1073741819.

[Martin Maechler]

>>>>> Rampal S Etienne <rampaletie...@gmail.com>
>>>>> on Wed, 29 Nov 2017 14:22:54 +0100 writes:

> Dear Marc, Martin, Dason,
> I agree that the status number is not very informative, but neither is:
> "Package does not build". The point is that I have no clue what is going
> on, and was just hoping that someone might have seen the exit status
> number before.

> I have done a clean install as suggested but still it won't work with
> R-devel, but it does with R-3.4.2.

> I don't see how my setup is special in any way. It never caused me any
> problems until installing the latest R-devel. What are the changes in
> the latest R-devel that affect the building of packages?

1000s of packages are built every day with R-devel, notably on
the machines that produce the CRAN checks, but also in several
if not many other places.

Consequently, it must be *your* problem, notably as your package
does build flawlessly on 5 different CRAN check machines running R-devel.

But of course, the purpose of *this* list (not of R-devel!) is
to help you with this problem,
hence back to what you wrote above:

"Package does not build"  is actually  more useful than a status
   number that looks random (and/or from a large integer overflow ..).

To me it would mean the package does not even build and
therefore *check*ing the package did not even properly start.

As next step (in solving the problem) you should probably learn
to either debug the devtools which you are probably using
[otherwise you would give us more information !],
or---even more useful in the long run---learn to build a package
in the shell (aka "terminal") instead of inside RStudio, because then,
using 'Rcmd build ' would almost surely give you more clues
than just "does not build".


> On 29-11-2017 11:16, Martin Maechler wrote:
>>>>>>> Rampal S Etienne <rampaletie...@gmail.com>
>>>>>>> on Wed, 29 Nov 2017 09:19:29 +0100 writes:
>> > Dear Dason,
>> > I don't get this error, but it crashes anyway. 
>> 
>> and you don't show what "crashes" means here.
>> (and yes, Dason is right: The RStudio status number in the
>> 'Subject' is not really useful)
>> 
>> > I've that if I use the
>> > stable version of R (3.4.2) I do NOT get the error anymore, so I assume
>> > there is something wrong with the current R-devel.
>> 
>> > Regards,
>> > Rampal Etienne
>> 
>> OTOH, the CRAN checks of your package run without any problem
>> with all 5 versions of R-devel there :
>> 
>> https://cran.r-project.org/web/checks/check_results_SADISA.html
>> 
>> so it may rather be something specific to your setup ??
>> 
>> Martin Maechler
>> 
>> 
>> > On 29-11-2017 0:36, Dason Kurkiewicz wrote:
>> >> Do you get the same error if you try to build on the command line
>> >> outside of RStudio?
>> >> 
>> >> On Nov 28, 2017 3:51 PM, "Rampal Etienne" <rampaletie...@gmail.com
>> >> <mailto:rampaletie...@gmail.com>> wrote:
>> >> 
>> >> Dear all,
>> >> 
>> >> I updated RStudio, Rtools and R-devel, and then I tried to build a
>> >> package in RStudio that I had been able to build before without
>> >> any problems. But now I got the following error:
>> >> 
>> >> Updating SADISA documentatiob
>> >> Loading SADISA
>> >> Exited with status -1073741819.
>> >> 
>> >> That's all. What is this exit status? I can still build other
>> >> packages, so it does not happen all the time. I can use "Load all"
>> >> and all functions sseem to work fine.
>> >> 
>> >> Any suggestions?
>> >> 
>> >> Kind regards, Rampal Etienne

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

Re: [R-pkg-devel] Exited with status -1073741819.

[Martin Maechler]

>>>>> Rampal S Etienne <rampaletie...@gmail.com>
>>>>> on Wed, 29 Nov 2017 09:19:29 +0100 writes:

> Dear Dason,
> I don't get this error, but it crashes anyway. 

and you don't show what "crashes" means here.
(and yes, Dason is right: The RStudio status number in the
'Subject' is not really useful)

> I've that if I use the
> stable version of R (3.4.2) I do NOT get the error anymore, so I assume
> there is something wrong with the current R-devel.

> Regards,
> Rampal Etienne

OTOH, the CRAN checks of your package run without any problem
with all 5 versions of R-devel there :

  https://cran.r-project.org/web/checks/check_results_SADISA.html

so it may rather be something specific to your setup ??

Martin Maechler


> On 29-11-2017 0:36, Dason Kurkiewicz wrote:
>> Do you get the same error if you try to build on the command line
>> outside of RStudio?
>> 
>> On Nov 28, 2017 3:51 PM, "Rampal Etienne" <rampaletie...@gmail.com
>> <mailto:rampaletie...@gmail.com>> wrote:
>> 
>> Dear all,
>> 
>> I updated RStudio, Rtools and R-devel, and then I tried to build a
>> package in RStudio that I had been able to build before without
>> any problems. But now I got the following error:
>> 
>> Updating SADISA documentatiob
>> Loading SADISA
>> Exited with status -1073741819.
>> 
>> That's all. What is this exit status? I can still build other
>> packages, so it does not happen all the time. I can use "Load all"
>> and all functions sseem to work fine.
>> 
>> Any suggestions?
>> 
>> Kind regards, Rampal Etienne
>> 
>> __
>> R-package-devel@r-project.org
>> <mailto:R-package-devel@r-project.org> mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>> 


> [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] [Rd] package check fail on Windows-release only?

[Martin Maechler]

> Paul Johnson 
> on Mon, 20 Nov 2017 14:59:26 -0600 writes:

> I mistakenly left a write in "/tmp" in the rockchalk package (version
> 1.8.109) that I uploaded last Friday. Kurt H wrote and asked me to fix
> today.

> While uploading a new one, I became aware of a problem I had not seen.
> The version I uploaded last Friday, 1.8.109, has OK status on all
> platforms except r-release-windows-ix86+x86_64. I get OK on
> oldrel-windows and also on devel-windows.

> https://cran.r-project.org/web/checks/check_results_rockchalk.html

> Can you please advise me on what to do? I don't understand, well,
> anything about this :(

Dear Paul,

something like this really should have been posted to the R-package-devel
list, not to R-devel; as it is here now, I'm crossposting to there for one msg
Please remove R-devel@.. from CC  if/when replying and keep it there.

> The error says:

> * installing *source* package 'rockchalk' ...
> ** package 'rockchalk' successfully unpacked and MD5 sums checked
> ** R
> ** data
> ** inst
> ** preparing package for lazy loading
> Warning: S3 methods 'print.sparseSummary', 'print.diagSummary',
> 'c.abIndex', 'c.sparseVector', 'as.array.Matrix',
> 'as.array.sparseVector', 'as.matrix.Matrix', 'as.matrix.sparseVector',
> 'as.vector.Matrix', 'as.vector.sparseVector' were declared in
> NAMESPACE but not found
> Error in namespaceExport(ns, exports) :
> undefined exports: %&%, Cholesky, .SuiteSparse_version, Diagonal,
> .symDiagonal, .sparseDiagonal, .trDiagonal, Hilbert, KhatriRao,
> Matrix, MatrixClass, spMatrix, sparseMatrix, rsparsematrix, Schur,
> abIseq, abIseq1, rep2abI, band, bandSparse, bdiag, .bdiag,
> c.sparseVector, condest, onenormest, .asmatrix, .dsy2mat, .dsy2dsp,
> .dxC2mat, .T2Cmat, ..2dge, .dense2sy, .C2nC, .nC2d, .nC2l, .diag.dsC,
> .solve.dgC.chol, .solve.dgC.qr, .solve.dgC.lu, diagN2U, diagU2N,
> .diagU2N, .diag2tT, .diag2sT, .diag2mat, drop0, expand, expm, facmul,
> fac2sparse, fac2Sparse, forceSymmetric, T2graph, graph2T,
> anyDuplicatedT, uniqTsparse, isTriangular, isDiagonal, isLDL,
> is.null.DN, invPerm, lu, nearPD, nnzero, formatSpMatrix,
> formatSparseM, .formatSparseSimple, printSpMatrix, printSpMatrix2,
> qrR, rankMatrix, readHB, readMM, sparse.model.matrix, sparseVector,
> symmpart, skewpart, tril, triu, updown, pack, unpack,
> .updateCHMfactor, .validateCsparse, writeMM, cBind, rBind
> ERROR: lazy loading failed for package 'rockchalk'
> * removing 'd:/Rcompile/CRANpkg/lib/3.4/rockchalk'
> * restoring previous 'd:/Rcompile/CRANpkg/lib/3.4/rockchalk'

all of these these are names of  Matrix-package objects..
and I know that yesterday Matrix package version changes (1.1-11
--> 1.1-12) happened on CRAN and hence in servers which update..

So it *could* be this is all just a temporary problem aka "race
situation" , where the check of your package very unhappily
happened exactly at a moment where the new Matrix package was
already there, but not quite 
seems quite improbable, but then your problem seems "rare"..

Martin

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

Re: [R-pkg-devel] Package required and available but unsuitable version: 'stats'

[Martin Maechler]

> Maxime Turgeon 
> on Thu, 20 Jul 2017 15:51:18 + writes:

> Hi Jernej,
> The check errors you get are for older releases of R (3.3.2 and 3.3.3). 
The issue arises from your requirement in DESCRIPTION that the version of stats 
should be 3.4.0. Therefore, the solution to your problem depends on whether you 
really need this requirement on the version of stats or not: if you don't, 
simply lower the requirements to whatever you need; if you do, then this check 
error is valid, in the sense that you don't want users to use your package if 
they don't have the appropriate version of the stats package.


> Note that if the latter applies, you should probably change your 
requirement on the version of R itself: currently you're requiring 3.1, which 
clashes with you're requiring 3.4 for stats.

I would go slightly further say that it is "conceptually wrong"
to use any version requirement on 'stats':  The version of
'stats' is *always* equal to the version of R.

So really, do replace
 "stats (>= 3.4.0)"
by   "stats" 


Also, are you sure that R 3.1.0 is sufficient for dendroExtra, i.e.,
can you check that, or did you at least check that for a
slightly older version of dendroExtra in the past?

The CRAN "robots" will not be able to check that, but as you see
checks for the "last before release" version, in this case R 3.3.x,
are made.

To be save, you'd say  "R (>= 3.3.3)"
whereas to be relaxed, you'd leave away any version requirement
for R unless you know that you are using a relatively new
feature of R (which includes 'stats', 'utils', etc). 

Best,
Martin

> Best,
> Max

>> Hi,

>> recently, my first R package dendroExtra
>>  was accepted on CRAN. I
>> still must fix one problem that is given by CRAN checks
>> .

>> It says: Package required and available but unsuitable version: 'stats'.

>> I see that probable I did not correctly import the stats package. If I
>> remove the 'stats' package, I get an error in R CMD check. Is there any
>> suggestion how to properly solve the issue? How to properly import stats
>> package?


>> Thank you for your help.


>> Bests, Jernej

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

Re: [R-pkg-devel] problem with package_native_routine_registration_skeleton

[Martin Maechler]

>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>> on Thu, 22 Jun 2017 09:57:41 +0200 writes:

>>>>> Mark van der Loo <mark.vander...@gmail.com>
>>>>> on Thu, 22 Jun 2017 07:33:49 + writes:

>> I have had no problems recently (having updated a pkg or two with this 
over
>> the last couple of weeks). Your question is not reproducible so its hard 
to
>> help...

>> best,
>> Mark

>> Op wo 21 jun. 2017 om 23:46 schreef Simon Barthelmé <
>> simon.barthe...@gipsa-lab.fr>:

>>> Dear list,
>>> 
>>> Is anybody else having problems with
>>> tools::package_native_routine_registration_skeleton?
>>> 
>>> > tools::package_native_routine_registration_skeleton("~/Repos/imager")
>>> 
>>> Error in native_routine_registration_db_from_ff_call_db(calls, dir,
>>> character_only) :
>>> no native symbols were extracted

> please carefully re-read the error message!

> Hint :  What is the name of the first argument of that function,
> and what is the name of the 2nd one ?

I'm sorry and do apologize: The above was not at all helpful.

'dir' _is_ the first argument of
package_native_routine_registration_skeleton()  and the error
message showed another function (with a similarly much much much
too long name, so nobody reads the name to an end).

Indeed, I get the same message as you when I use this on a
source package directory... though one that does already contain
everything perfect in the init.c file.

So maybe the function should not give an error but just
acknowledge that no *unregisterted* native symbols were found ?

Martin Maechler


>>> This used to work fine up until a few weeks ago, and I can't tell which
>>> update broke the function. Anybody else getting this?
>>> 
>>> Many thanks, best
>>> 
>>> Simon Barthelme

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

Re: [R-pkg-devel] multiple bibentry()s in CITATION

[Martin Maechler]

>>>>> Fox, John <j...@mcmaster.ca>
>>>>> on Mon, 16 Jan 2017 15:44:05 + writes:

> Dear Martin,
> Thanks for addressing this question, if belatedly!

> After a little bit of thought, perhaps a default somewhere between 1 and 
Inf makes sense, along with an additional argument to citation: 
citation(package="pkg", bibtex.max=n), with default bibtex.max= 
getOption("citation.bibtex.max"), where the citation.bibtex.max option is 
initially set to something like 4. If the number of available citations exceeds 
bibtex.max, then a message like "there are additional BiBTeX citations, enter 
'citation(package="pkg", bibtex.max=Inf)' to see all of them."

In the mean time, I have always used my proposed change.
I think any number between 1 and Inf is so much arbitrary that
inspite of your good thoughts I kept the *new* default at Inf.

and because of this open question, I have forgotten to commit
the change to the development version of R !

I have done so now, however not ported it yet to  "R 3.4.0 alpha".
If not much surfaces (in CRAN / Bioc checks), we may port it in
time for 3.4.0.


Martin

> Best,
> John

>> -Original Message-
>> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
>> Sent: Monday, January 16, 2017 10:02 AM
>> To: Fox, John <j...@mcmaster.ca>
>> Cc: r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] multiple bibentry()s in CITATION
>> 
>> >>>>> Fox, John <j...@mcmaster.ca>
>> >>>>> on Fri, 2 Sep 2016 15:42:46 + writes:
>> 
>> (which is more than 4 months ago)
>> 
>> > Dear list members,
>> > I've noticed that citation(package="pkg") generates both a text
>> citation and a BiBTeX entry when the CITATION file contains a single
>> call to bibentry() or citEntry(), but that only text citations are shown
>> if there are multiple calls to bibentry() or citEntry().
>> 
>> > Is this behaviour intentional? In my opinion, it's useful always
>> to show the BiBTeX (although it's available through
>> toBibtex(citation(package="pkg")) ).
>> 
>> > The Writing R Extensions manual says, "A CITATION file will
>> contain *calls* [my emphasis] to function bibentry."
>> 
>> > Thanks,
>> > John
>> 
>> and you did not get a reply
>> I had wanted but forgotten about it ... two parts :
>> 
>> 1)  On November 24, 2012,  I had improved R with an option to get this
>> so this has been a "hidden gem" ;-) for a while in R:
>> 
>> > options(citation.bibtex.max = Inf)
>> > citation(package = "Rcmdr")
>> 
>> To cite the 'Rcmdr' package in publications use:
>> 
>> Fox, J., and Bouchet-Valat, M. (2017). Rcmdr: R Commander. R package
>> version 2.3-2.
>> 
>> A BibTeX entry for LaTeX users is
>> 
>> @Manual{,
>> title = {{Rcmdr: R Commander}},
>> author = {John Fox and Milan Bouchet-Valat},
>> year = {2017},
>> note = {R package version 2.3-2},
>> url = {http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/},
>> }
>> 
>> Fox, J. (2017). Using the R Commander: A Point-and-Click Interface or
>> R. Boca Raton FL:
>> Chapman and Hall/CRC Press.
>> 
>> A BibTeX entry for LaTeX users is
>> 
>> @Book{,
>> title = {Using the {R Commander}: A Point-and-Click Interface for
>> {R}},
>> author = {John Fox},
>> year = {2017},
>> publisher = {Chapman and Hall/CRC Press},
>> address = {Boca Raton {FL}},
>> url = {http://socserv.mcmaster.ca/jfox/Books/RCommander/},
>> }
>> 
>> Fox, J. (2005). The R Commander: A Basic Statistics Graphical User
>> Interface to R.
>> Journal of Statistical Software, 14(9): 1--42.
>> 
>> A BibTeX entry for LaTeX users is
>> 
>> @Article{,
>> title = {The {R} {C}ommander: A Basic Statistics Graphical User
>> Interface to {R}},
>> author = {John Fox},
>> year = {2005},
>> journal = {Journal of Statistical Software},
>> volume = {14},
>> number = {9},
>> pages = {1--42},
>> url = {http://www.jstatsoft.org/v14/i09},
>> }
>> 
>> >
>> 
>> 
 

Re: [R-pkg-devel] Extending an S3 method, but putting the package in Suggests?

[Martin Maechler]

>>>>> David Hugh-Jones <davidhughjo...@gmail.com>
>>>>> on Tue, 14 Mar 2017 09:26:49 + writes:

> Just out of interest, what would happen if I used the hacky solution of
> simply  exporting my own method like:

> as.FlexTable <- function(x, ...) UseMethod("as.FlexTable")

> I am fairly sure you will tell me that fire and brimstone will rain down…
> But it sure seems simple  compared to writing another package and getting
> it on CRAN...

no fire etc, but pretty close ;-)

You will have two (internal) methods tables for as.FlexTable,
one in ReporteRs, one in your package, and from a user point of
view there's a deep abyss in functionality between working with

  require(ReporteRs); require(huxtable)

and working with

  require(huxtable); require(ReporteRs)

This is undesirable and error prone and can be resolved by
correct imports as those mentioned.

Martin

> David

> On Tue, 14 Mar 2017 at 09:06, Martin Maechler <maech...@stat.math.ethz.ch>
> wrote:

>> >>>>> David Hugh-Jones <davidhughjo...@gmail.com>
>> >>>>> on Tue, 14 Mar 2017 02:46:35 + writes:
>> >>>>> David Hugh-Jones <davidhughjo...@gmail.com>
>> >>>>> on Tue, 14 Mar 2017 02:46:35 + writes:
>> 
>> > Hi,
>> > Cross-posted from SO:
>> >
>> 
http://stackoverflow.com/questions/42776058/extending-an-s3-generic-from-an-optional-package
>> 
>> ((sent my answer there as well))
>> 
>> > I have a package which provides an as.FlexTable method for its
>> objects,
>> > extending the S3 generic from the ReporteRs package. So, my
>> NAMESPACE file,
>> > generated by roxygen, has lines:
>> 
>> > importFrom(ReporteRs,as.FlexTable)
>> > ...
>> > S3method(as.FlexTable,huxtable)
>> > ...
>> > export(as.FlexTable)
>> 
>> > I don't much want to put ReporteRs in Imports: in the DESCRIPTION
>> file,
>> > because it involves a big external dependency on Java. But, when I
>> put it
>> > into Suggests:, R CMD check gives me errors like "Namespace
>> dependency not
>> > required".
>> 
>> > Is there anyway I can extend the generic without making a hard
>> dependency?
>> 
>> No.  Importing is a hard dependency..
>> Some people do not import formally but use  '::'
>> instead, *and* conditionalize their code on the availability of
>> that namespace.
>> I don't recommend that at all, and particularly not for
>> extending a generic.
>> 
>> I recommend you talk with the maintainer of 'ReporteRs':
>> 1) You could use a common (yet-to-create) very small package say
>> 'flexS3generics'
>> which provides S3 generics (and S4 if ..) you want to use
>> both, and then both you and her/him import from that mini package.
>> You'd be both authors of that package.
>> 
>> 2) If your package is much smaller (in its footprint, incl
>> dependencies) than 'ReporteRs' she/he may agree to import the
>> S3 generic from your package instead of the other way around.
>> 
>> Both are clean solutions,
>> and both need some time-coordination when releasing to CRAN,
>> '1)' being easier: Once the 'flexS3generics' is released to
>> CRAN, change (both) your package(s) to
>> importFrom(flexS3generics,*) but these changes and CRAN
>> submissions are then independent of each other.
>> 
>> 
>> > Cheers,
>> > David
>> 
>> --
> Sent from Gmail Mobile

> [[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Extending an S3 method, but putting the package in Suggests?

[Martin Maechler]

> David Hugh-Jones 
> on Tue, 14 Mar 2017 02:46:35 + writes:
> David Hugh-Jones 
> on Tue, 14 Mar 2017 02:46:35 + writes:

> Hi,
> Cross-posted from SO:
> 
http://stackoverflow.com/questions/42776058/extending-an-s3-generic-from-an-optional-package

  ((sent my answer there as well))

> I have a package which provides an as.FlexTable method for its objects,
> extending the S3 generic from the ReporteRs package. So, my NAMESPACE 
file,
> generated by roxygen, has lines:

> importFrom(ReporteRs,as.FlexTable)
> ...
> S3method(as.FlexTable,huxtable)
> ...
> export(as.FlexTable)

> I don't much want to put ReporteRs in Imports: in the DESCRIPTION file,
> because it involves a big external dependency on Java. But, when I put it
> into Suggests:, R CMD check gives me errors like "Namespace dependency not
> required".

> Is there anyway I can extend the generic without making a hard dependency?

No.  Importing is a hard dependency..
Some people do not import formally but use  '::'
instead, *and* conditionalize their code on the availability of
that namespace.
I don't recommend that at all, and particularly not for
extending a generic.

I recommend you talk with the maintainer of 'ReporteRs':
1) You could use a common (yet-to-create) very small package say 
'flexS3generics'
   which provides S3 generics (and S4 if ..) you want to use
   both, and then both you and her/him import from that mini package.
   You'd be both authors of that package.

2) If your package is much smaller (in its footprint, incl
   dependencies) than 'ReporteRs' she/he may agree to import the
   S3 generic from your package instead of the other way around.

Both are clean solutions,
and both need some time-coordination when releasing to CRAN,
'1)' being easier: Once the 'flexS3generics' is released to
CRAN, change (both) your package(s) to
importFrom(flexS3generics,*) but these changes and CRAN
submissions are then independent of each other.


> Cheers,
> David

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

Re: [R-pkg-devel] tryCatch defensive programming guidance

[Martin Maechler]

> Berry Boessenkool 
> on Wed, 1 Mar 2017 14:52:10 + writes:

> Hi Glenn,


> Better late than never:
> couldn't you simply use try?

> result <- try( log("a") )

> The printing is horrible: people will think an error
> occured (but the function didn't stop!)

> I tend to use it like this (which may be totally
> unintended):


> res <- try(log("a"), silent=TRUE)
> if(inherits(res, "try-error"))
> {
>   message("log failed: ",res,". Now continuing with res=0.")
>  res <- 0
> }

but if you ever looked:  try() is just a wrapper to tryCatch()
and using try(*, silent=TRUE)  is even closer to a pretty simple tryCatch(.)

Historically,  tryCatch() did not exist, but try() did.
So much of "old code" still has try() calls in it.

I consider try() as convenience function for interactive use but
would always use tryCatch() for new code in my packages.


> See here for my version that captures errors/warnings/messages with call 
tracing:

> https://www.rdocumentation.org/packages/berryFunctions/topics/tryStack

I'd recommend you switch to tryCatch(): It is more flexible and
more directly "configurable" than try() -- which also got some historical
flexibility by the "hack" (not functional programming)
of depending on  getOption("show.error.messages")  in the
default case  silent = FALSE  {needed to suppress other
packages' using  try(.) 's printing of error messages as if
*error*s inspite of the fact that they were caught.

 and back to the OP:

I think that's your only small problem that you chose
  error = function(e) print(e)

because that prints "as if" you had an error.

Martin


> Regards,

> Berry


> 
> From: R-package-devel  on behalf 
of Glenn Schultz 
> Sent: Saturday, February 25, 2017 15:50
> To: R Package Development
> Subject: [R-pkg-devel] tryCatch defensive programming guidance

> All,

> I have the following to create a class PriceTypes.  I use try catch on 
the function and it gives me the error

> price <- tryCatch(PriceTypes(price = "100")
> ,error = function(e) print(e)
> ,warning = function(w) print(w))

> 
>> 

> I read the section on tryCatch and withCallingHandlers as well the manual 
but I am still not clear as to how to use tryCatch in the function below I tried
> PriceTypes <- TryCatch(
> function(){}
> ), function(e) print(error)

> but this is obviously wrong as it did not work.  My question can I use 
tryCatch in the function itself or only when I invoke the function.

> Best Regards,
> Glenn

> #' An S4 class representating bond price
> #'
> #' This class is used to create and pass the price types reported to
> #' investors and used in analytics. For example price is often reported as
> #' decimal or fractions 32nds to investors but price basis (price/100) is
> #' used to calculate proceeds and compute metrics like yield, duration, 
and
> #' partial durations.
> #' @slot PriceDecimal A numeric value the price using decimal notation
> #' @slot Price32nds A character the price using 32nds notation
> #' @slot PriceBasis A numeric value price decimal notation in units of 100
> #' @slot PriceDecimalString A character the price using decimal notation
> #' @exportClass PriceTypes
> setClass("PriceTypes",
> representation(
> PriceDecimal = "numeric",
> Price32nds = "character",
> PriceBasis = "numeric",
> PriceDecimalString = "character")
> )

> setGeneric("PriceTypes", function(price = numeric())
> {standardGeneric("PriceTypes")})

> #' A standard generic function get the slot PriceDecimal
> #'
> #' @param object an S4 object
> #' @export PriceDecimal
> setGeneric("PriceDecimal", function(object)
> {standardGeneric("PriceDecimal")})

> #' A standard generic function to set the slot PriceDecimal
> #'
> #' @param object an S4 object
> #' @param value the replacement value of the slot
> #' @export PriceDecimal<-
> setGeneric("PriceDecimal<-", function(object, value)
> {standardGeneric("PriceDecimal<-")})

> #' A standard generic function to get the slot Price32nds
> #'
> #' @param object an S4 object
> #' @export Price32nds
> setGeneric("Price32nds", function(object)
> {standardGeneric("Price32nds")})

> #' A standard generic function to set the slot Price32nds
> #'
> #' @param object an S4 object
> #' @param value the replacement value of the slot
> #' @export Price32nds<-
> setGeneric("Price32nds<-", function(object, value)
> {setGeneric("Price32nds")})

> #' A standard generic to get the slot PriceBasis
> #'
> #' @param object an S4 object
> #' @export PriceBasis
> setGeneric("PriceBasis", 

Re: [R-pkg-devel] no visible global function definition for ‘par’

[Martin Maechler]

>>>>> Dirk Eddelbuettel <e...@debian.org>
>>>>> on Mon, 30 Jan 2017 20:50:19 -0600 writes:

> On 30 January 2017 at 09:58, Kevin Ushey wrote:
> | The correct thing to do is indeed import any functions from any R 
packages
> | you use, base or otherwise. The simplest fix, if you don't want to
> | selectively import such a large range of functions, is to simply add 
e.g.
> | 
> | import(utils)
> | import(stats)
> | ... etc ...
> | 
> | to your NAMESPACE file.

> Or do what R CMD check suggested and import the ones used, rather than 
all.

> Which is what I had quoted earlier:

> | Consider adding
> | 
> |   importFrom("grDevices", "as.raster", "dev.cur", "dev.off", "gray",
> |  "heat.colors", "jpeg", "palette", "pdf", "png", "rainbow",
> |  "terrain.colors", "tiff")
> |   importFrom("graphics", "abline", "axis", "barplot", "box", "boxplot",
> |  "image", "layout", "legend", "lines", "mtext", "par",
> |  "plot", "plot.new", "points", "rasterImage", "strwidth",
> |  "text", "title")
> |   importFrom("stats", "TukeyHSD", "acf", "aov", "ccf", "coefficients",
> |  "drop1", "end", "fft", "median", "model.tables",
> |  "na.action", "na.omit", "pf", "ts", "var")
> |   importFrom("utils", "read.table", "str", "tail", "write.table")
> | 
> | to your NAMESPACE file.

> I find this preferable and quite appreciate that R CMD check provides it.
> Dirk

yes, and that is not only Dirk :

It *is* highly preferable and recommended, also in *the*
reference manual ("Writing R Extensions", aka WRE) for reasons
of
  - efficiency,
  - modularity and "self-documentation"
  - much better control against accidental name clashes,

There are very few exceptions where importing a whole namespace
makes sense and the above base packages are typically never part
of these exceptions.

Martin Maechler
ETH Zurich and R Core

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

Re: [R-pkg-devel] multiple bibentry()s in CITATION

[Martin Maechler]

>>>>> Fox, John <j...@mcmaster.ca>
>>>>> on Fri, 2 Sep 2016 15:42:46 + writes:

(which is more than 4 months ago)

> Dear list members,
> I've noticed that citation(package="pkg") generates both a text citation 
and a BiBTeX entry when the CITATION file contains a single call to bibentry() 
or citEntry(), but that only text citations are shown if there are multiple 
calls to bibentry() or citEntry(). 

> Is this behaviour intentional? In my opinion, it's useful always to show 
the BiBTeX (although it's available through toBibtex(citation(package="pkg")) ).

> The Writing R Extensions manual says, "A CITATION file will contain 
*calls* [my emphasis] to function bibentry."

> Thanks,
> John

and you did not get a reply
I had wanted but forgotten about it ... two parts :

1)  On November 24, 2012,  I had improved R with an option to get this
so this has been a "hidden gem" ;-) for a while in R:

> options(citation.bibtex.max = Inf)
> citation(package = "Rcmdr")

To cite the 'Rcmdr' package in publications use:

  Fox, J., and Bouchet-Valat, M. (2017). Rcmdr: R Commander. R package version 
2.3-2.

A BibTeX entry for LaTeX users is

  @Manual{,
title = {{Rcmdr: R Commander}},
author = {John Fox and Milan Bouchet-Valat},
year = {2017},
note = {R package version 2.3-2},
url = {http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/},
  }

  Fox, J. (2017). Using the R Commander: A Point-and-Click Interface or R. Boca 
Raton FL:
  Chapman and Hall/CRC Press.

A BibTeX entry for LaTeX users is

  @Book{,
title = {Using the {R Commander}: A Point-and-Click Interface for {R}},
author = {John Fox},
year = {2017},
publisher = {Chapman and Hall/CRC Press},
address = {Boca Raton {FL}},
url = {http://socserv.mcmaster.ca/jfox/Books/RCommander/},
  }

  Fox, J. (2005). The R Commander: A Basic Statistics Graphical User Interface 
to R.
  Journal of Statistical Software, 14(9): 1--42.

A BibTeX entry for LaTeX users is

  @Article{,
title = {The {R} {C}ommander: A Basic Statistics Graphical User Interface 
to {R}},
author = {John Fox},
year = {2005},
journal = {Journal of Statistical Software},
volume = {14},
number = {9},
pages = {1--42},
url = {http://www.jstatsoft.org/v14/i09},
  }

>


This all works "obviously" (;-) via utils:::format.bibentry ()
and even when I had made the number one an argument to that
function with a default you can set via options(),  I had
wondered a bit  why the cutoff should by default be at one.

E.g., it looks strange that by *adding* a 2nd reference, you get
shorter citation output and to me it would seem more coherent
to have the default rather be 'Inf' instead of '1',  i.e. always
showing both text and bibtex.

There is quite a difference though: For our copula package, e.g.,

> options(citation.bibtex.max = 1); citation(package = "copula")

To cite the R package copula in publications use:

  Marius Hofert, Ivan Kojadinovic, Martin Maechler and Jun Yan (2017). copula:
  Multivariate Dependence with Copulas. R package version 0.999-16 URL
  https://CRAN.R-project.org/package=copula

  Jun Yan (2007). Enjoy the Joy of Copulas: With a Package copula. Journal of 
Statistical
  Software, 21(4), 1-21. URLhttp://www.jstatsoft.org/v21/i04/.

  Ivan Kojadinovic, Jun Yan (2010). Modeling Multivariate Distributions with 
Continuous
  Margins Using the copula R Package. Journal of Statistical Software, 34(9), 
1-20. URL
  http://www.jstatsoft.org/v34/i09/.

  Marius Hofert, Martin Maechler (2011). Nested Archimedean Copulas Meet R: The 
nacopula
  Package. Journal of Statistical Software, 39(9), 1-20. URL
  http://www.jstatsoft.org/v39/i09/.

>

This is relatively compact (18 lines)
whereas it gives  67 lines of output when the option is set to
something >= 4.

Other opinions?
What do you think, would it be worth the compatibility break to
change the default from '1' to 'Inf' ?

Best regards,
Martin

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

Re: [R-pkg-devel] Question about configure file and system requirements

[Martin Maechler]

>>>>> Lorenzo Busetto <lbus...@gmail.com>
>>>>> on Fri, 18 Nov 2016 23:04:53 +0100 writes:

> Dear all, a quick question:

> while preparing for a CRAN submission, am I supposed to
> include a "configure" file and list for system
> requirements also if those system requirements "come from"
> the packages that I import ?

If the requirements are *only* in these packages, and not
(directly) in your package's functions,
you should *not* duplicate the checks (nor the entries in
DESCRIPTION),

by the same logic that you should not list 'Depends', 'Imports',
'Suggests', etc of those packages.

Martin Maechler
ETH Zurich

> Asking this because the "configure" and system
> requirements are already present in the imported packages,
> so my configuration check would duplicate what is already
> done while installing the dependencies.

> sorry if this is dumb...

> Lorenzo

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

Re: [R-pkg-devel] fastICA on win-builder.r-project.org not installed?

[Martin Maechler]

>>>>> Guido Kraemer <gkrae...@bgc-jena.mpg.de>
>>>>> on Wed, 12 Oct 2016 12:26:14 +0200 writes:

> Dear R package devels, I am trying to check a package
> which depends on fastICA on win-builder.r-project.org, the
> checks fail complaining that fastICA is not installed.

Well, you are *interpreting* the error message.
What is true is that fastICA is not *visible* in the
' R CMD check  '
environment.

> PS: the log can be found here:
> https://win-builder.r-project.org/265alZrIl0s6/00check.log

fastICA  is not at all mentioned in your DESCRIPTION file.
That is *always* wrong for any package you even only sometimes
use in your package.
... and that entirely explains why it is not found during checking.
Checking (almost) exactly only sees the packages that you
declare to "require".

Possibly adding the one line

Suggests: fastICA

to the DESCRIPTION file may be sufficient.
Please read more about this in *the* manual (for this topic):
"Writing R Extensions", part of every R installation and
browseable e.g., here
   https://cran.r-project.org/doc/manuals/r-release/R-exts.html

https://cran.r-project.org/manuals.html mentions different
formats, including Epub.

Martin Maechler
ETH Zurich

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

Re: [R-pkg-devel] relation between vignettes and help files

[Martin Maechler]

>>>>> Boylan, Ross <ross.boy...@ucsf.edu>
>>>>> on Fri, 15 Jul 2016 17:23:37 + writes:

> One issue with integrating vignettes into the help system is that 
vignettes are 
> more likely to have material (figures, math) that renders poorly or not 
at all as text.
> I also mostly use ESS on terminal rather than graphical interface, and so
> like the  plain text version of things.  OTOH, I used Sweave specifically 
so
> I could put math in the vignette.

Emacs has been rendering graphics and pdf  for several years
now, and there are also several web browsing modes that we (ESS
maintainers) have considered using in the past.

But really I'm not interested so much in the potential ESS
problems, which *are* solvable and as Duncan says correctly are
not R problems.

Rather I did want to get back to the original issue of
facilitating and officially supporting links in both directions 
 R (installed package) Help  <--> R (installed package) vignettes

which I think you also want to continue talking about:

> Does anyone have any thoughts about the substantive division of info 
between help files and
> vignettes?

> Ross
> 
> From: Martin Maechler [maech...@stat.math.ethz.ch]
> Sent: Friday, July 15, 2016 5:32 AM
> To: Duncan Murdoch
> Cc: Enrico Schumann; Boylan, Ross; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] relation between vignettes and help files

> ..
> It is even worse, isn't it: Nowadays html help pages are (almost)
> always created *dynamically* via R's help() or help.start();
> For my setup of 1000s of packages in my libraries in .libPaths(),
> generating all the html pages is too costly
> [I think Rstudio is now smart and does this in the background
> for its *own* package data base ?? -- I wish we would enable to
> do this easily in base R !]

> and I am using (ESS with) "text" help_type, and so these links
> to the url in doc/html  would not work for me.

> I wonder if we should not think harder about this, and provide a
> portable solution.

> I do agree that it should be very desirable to have links portably,
> in *both* directions between
> our "reference manuals"  ( = the help pages)  and
> our "user's manuals" ( = the vignettes ).

> Martin

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

Re: [R-pkg-devel] using printf() in C code (package 'powell')

[Martin Maechler]

>>>>> ProfJCNash  <profjcn...@gmail.com>
>>>>> on Tue, 3 May 2016 15:55:08 -0400 writes:

 [..]

> Also, in my review I've come across a few package glitches e.g., package
> "powell" won't install because of something untoward in printf()
> functions. I'll report this in detail when R 3.3 comes in the Linux Mint
> update if there is still a problem at that time. (CRAN checks are
> complaining about such issues, but seem to treat them as warnings rather
> than errors. The package date is 2006, so rather old.)

[Yes, indeed, impressively so, as unchanged non-archived CRAN package.]

Indeed, the C code in powell does printf()
which is not good. Rather it should use R's API for warning
messages -- as these work on all platforms, also inside GUIs --
and also as the user can then use  suppresWarnings(.)  etc.

This will definitely not go away with R 3.3.0 or any later
version of R.
But then  maintainer("powell")  is still active, and his e-mail
address at your fingertips,..., right ?

--> I've BCC'ed Sundar, so he is informed.

With best regards,
Martin

Martin Maechler @ ETH Zurich





> On 16-05-03 03:40 PM, Uwe Ligges wrote:
>> 
>> 
>> On 03.05.2016 21:31, ProfJCNash wrote:
>>> I noted that my nlmrt package on CRAN has package usl as a "reverse
>>> imports". In a modest search I have yet to find a definition of the
>>> term. Does anyone have a pointer?
>> 
>> That means usl imports from your nlmrt package.
>> 
>> Best,
>> Uwe Ligges
>> 
>> 
>>> 
>>> JN
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>> 

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

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

Re: [R-pkg-devel] Is it possible to protect a word from the spell checker?

[Martin Maechler]

> Hana Sevcikova 
> on Tue, 1 Mar 2016 11:45:34 -0800 writes:

> If it's in the DESCRIPTION file put the word into quotes.
> Hana

Indeed, thank you Hana!

To add - embarrassingly I've only learned this about a week ago -
they need to be *single* quotes (as used 'here', they are also
called 'apostroph') and *not* double quotes.

Martin

> On 01/03/2016 08:47, Michael Dewey wrote:
>> The spell checker is correct they are not correctly spelled English
>> words but names. I searched the Writing R Extensions manual but did not
>> find any solution. I know it is only a NOTE not more serious.

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

Re: [R-pkg-devel] Development Testers?

[Martin Maechler]

>>>>> Charles Determan <cdeterma...@gmail.com>
>>>>> on Sat, 6 Feb 2016 10:33:03 -0600 writes:

> Thanks Boris, My main concern I suppose is if this mailing
> list is appropriate to occasionally solicit additional
> testers.  Just curious what people (i.e.  Admins) would
> think about using the list for such a purpose.

I (as one of the moderators) don't have a strong view on this
for this special case, but would actually recommend to use
R-devel (or even R-help) for this, rather than R-package-devel,
because the latter is indeed quite focused (with a somewhat different
focus).

And yes, for the specific, I'd strongly recommend  R-SIG-HPC (in
addition, i.e., with the very rare case of sensible cross posting).

Best regards,
Martin


--
Martin Maechler
ETH Zurich and R Core Team

> Regards, Charles

> On Friday, February 5, 2016, Boris Steipe
> <boris.ste...@utoronto.ca> wrote:

>> Of course I can speak only for myself, but I'd help out
>> if asked and I think in general you'll find people here
>> to be a pretty helpful bunch.
>> 
>> Cheers, Boris
>> 
>> 
>> On Feb 5, 2016, at 8:30 AM, Charles Determan
>> <cdeterma...@gmail.com <javascript:;>> wrote:
>> 
>> > I'm not sure if this question is appropriate for the R
>> mailing lists but > I'm not sure where else to ask.
>> >
>> > I am wondering if there is any means by which package
>> authors can solicit > testers for a package.  I believe
>> this is often referred to as 'crowd > sourced testing'.
>> >
>> > I am aware of continuous integration platforms and unit
>> testing (e.g.  > testthat) but that only gets me so far.
>> In my particular instance I am > developing packages for
>> GPU computing (maybe this request would be best on > the
>> HPC mailing list?).  As such, I can't possibly have
>> access to every > type of GPU.  I would like to find a
>> means of 'recruiting' users who may > have different
>> pieces of hardware to test my package.  Of course this
>> won't > be exhaustive but any additional testing that
>> others could provide would > make the package all the
>> more stable.
>> >
>> > Regards, > Charles
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __ >
>> R-package-devel@r-project.org <javascript:;> mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> 

>   [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] S3 length method behavior

[Martin Maechler]

> Barry Rowlingson 
> on Tue, 2 Feb 2016 17:23:46 + writes:

> On Tue, Feb 2, 2016 at 3:28 PM, Hadley Wickham  
wrote:
>> I've found that it's a very bad idea to provide length or names
>> methods for just this reason.

well, not quite, see below ..

>>> After looking
>>> for memory leaks and other errors I finally noticed that the str() on 
the
>>> object of myClass looked odd. It returned something like this:
>>> 
>>> List of 82
>>> $ file  : chr "my/file/location"
>>> $ handle:
>>> $ NA:
>>> Error in object[[i]] : subscript out of bounds


>>> My questions are, then, whether this behavior makes sense and what to do
>>> about it. If I define my own str() method, will that fix it? I think I 
am
>>> just misunderstanding what is going on with the methods I have defined.
>>> Hopefully, someone can offer some clarity.

> Defining a str on your class will at least fix the out of bounds error:

> Create a trivial S3 class:

>> z=list(1,22)
>> class(z)="foo"

> length method looks at the second element:

>> length.foo=function(x){x[[2]]}
>> length(z)
> [1] 22

> and str barfs:

>> str(z)
> List of 22
> $ : num 1
> $ : num 22
> $ :Error in object[[i]] : subscript out of bounds

> Define a str method:

>> str.foo=function(object,...){for(i in
> 1:length(unclass(object))){str(unclass(object[[i]]))}}
>> str(z)
> num 1
> num 22

> BUT... the real problem is that S3 classes are seriously informal and
> there's no concept of what methods you need to define on a class
> because there's no concept of an "interface" that new classes have to
> conform to. So stuff breaks, seemingly at random, and via action at a
> distance. Somewhere something is going to expect z[[1]] to
> z[[length(z)]] to exist, which is what the default str is doing...

Indeed.
Still, it can also be advantageous to define such methods *consistently*.

With *consistence*, I mean that at least

- names(obj) either returns NULL or a character vector of
  length length(obj), and that as Barry mentions,
- obj[[ i ]]  is meaningful  for (i in  seq_along(obj))
   [yes, seq_along(.) automatically works with your length() method !]

- often you'd also want  obj[ i ]  to also work consistently
  (sometimes identically to `[[`)

I'd say that oftentimes it may be easier (and more "rewarding")
to define such `[` and `[[` methods for your class anyway.

As author of str(), I'll declare the design(*) of str() to be such
that with these methods (length, names, `[`, `[[`) defined
consistently, str.default(obj) already works sensibly.  
The alternative is indeed to define your own str() method.  

One of the two you'd want often, because e.g.,
  str( list( ,  ) )
or similar things should work too.

--
(*) to be honest, str() grew and developed very much
historically, so the above is more an "implementation principle"

> +1 on Hadley - don't override any basic R structural methods, create
> new ones with new names. You can make them more meaningful too. For
> your example, maybe "messageCount(myObject)"?

> Barry

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

Re: [R-pkg-devel] Return Value of By Function

[Martin Maechler]

>>>>> Dario Strbenac <dstr7...@uni.sydney.edu.au>
>>>>> on Tue, 15 Sep 2015 05:00:05 + writes:

> Good day, I am curious why the by function result has
> dimensions attached, even when it returns a list.

Sorry, but this is *NOT* the mailing list for such questions !

Please ask on different list (or forum), e.g., on R-help.

Martin Maechler

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

Re: [R-pkg-devel] Visible bindings and reference classes

[Martin Maechler]

 Colin Gillespie csgilles...@gmail.com
 on Mon, 10 Aug 2015 20:33:32 + writes:

 Dear All,
 
 I have a package that uses reference classes. When I build the package I
 get numerous notes of the sort
 
 Note: no visible binding for '-' assignment to 'pars'
 
 I've tried using GlobalVariables, but that didn't solve the issue.

[ You mean globalVariables(): and it's a bad idea anyway IMO, 
  even if it is recommended : If you declare a variable in
  there, it is global in all places in your package and the
  codetools won't report it anywhere anymore.
  Much better in my view is to use something like

  var7 - NULL # ~= globalVariables(var7)
 
]

To your question:

Reference classes are used in *many* places,  and the use of  ' - '
is really standard there.
e.g., package 'lme4', or 'pcalg' are two packages I'm involved with,
which use ref.classes and ' - '  but are fine with that.

So there must be something peculiar in your package leading to
the  -  warnings.

Maybe you should look into the source code of such other CRAN
packages to see how they do it differently than you.

Best regards,
Martin

Martin Maechler, ETH Zurich


 After some googling, I came across the page
 http://stackoverflow.com/q/23475309/203420 which suggests
 
 suppressBindingNotes - function(variablesMentionedInNotes) {
   for(variable in variablesMentionedInNotes) {
 assign(variable,NULL, envir = .GlobalEnv)
   }
 }
 suppressBindingNotes(c(dat, internal, xmin, pars, no_pars))
 
 But checking the package with --as-cran raises the note
 
 * checking R code for possible problems ... NOTE
 Found the following assignments to the global environment:
   File ‘poweRlaw/R/aaa_all_classes.R’:
   assign(variable, NULL, envir = .GlobalEnv)
 
 What is the correct way of removing the visible bindings notes?
 
 Thanks
 
 Colin
 
   [[alternative HTML version deleted]]
 
 __
 R-package-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] apparent S3 methods note in R CMD check

[Martin Maechler]

 Uwe Ligges lig...@statistik.tu-dortmund.de
 on Fri, 12 Jun 2015 22:58:17 +0200 writes:

 On 12.06.2015 18:22, Roebuck,Paul L wrote:
 Actually, between this and other things coming from 'R
 CMD check' these days, I disagree that this is reasonable
 at all - it's a hack

 Why a hack? I am not sure what the right mechanism is, but
 here the check is not the problem but it uncovers the
 problem that the function is actually used as an S3 ethod
 although it is not.

Indeed. It's really the contrary of hack, namely trying to solve
the underlying problem:
This has been a proposition that is much more than just a way to turn
off some warnings or notes.  It's about a possible improvement in
R in how functions are made into S3 methods, namely allowing at least
for R code in package namespaces (but maybe even outside) to say
that a given  fn.class  function should *not* be seen as an
S3 method of function fn for class class .

But please follow up on R-devel -- there's a full thread there.
This list is about helping programmeRs develop their packages ..

Martin

 at best that only fixes this particular issue. Better would be
 to introduce lint-like directives that turn off certain R CMD
 check notes/warnings at different scopes (e.g., #pylint:
 disable=some-message,another-one) rather than introduce
 individual workarounds. Would give us an extensible version of
 the --no-nanny option Kevin wants.


 On 6/12/15 5:38 AM, John Fox j...@mcmaster.ca wrote:

 Dear Martin,

 Thank you for addressing this issue. Introducing a nonS3method()
 directive in NAMESPACE
 seems a reasonable solution. It could replace export() for functions with
 .s in their names.

 Best,
 John

 On Fri, 12 Jun 2015 09:55:18 +0200
 Martin Maechler maech...@stat.math.ethz.ch wrote:
 John Fox j...@mcmaster.ca
  on Wed, 10 Jun 2015 10:12:46 -0400 writes:

   Dear list members,
   One of the packages I maintain, effects, generates the following
 note in R
   CMD check:

   * checking S3 generic/method consistency ... NOTE
   Found the following apparent S3 methods exported but not
 registered:
   all.effects

   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()?

   To be clear, all.effects() is *not* a method of all(), and is
 defined as

   effects::all.effects
   function (...)
   {
.Deprecated(allEffects)
allEffects(...)
   }

 Dear John,
 this is a good question without an obvious answer for the
 moment.

 The check producing it is relatively new *and* has helped to
 detect problems in many packages and places,  but I would agree
 is a False Positive in this case.

 One reason for such a check is the following output {in R = 3.2.0},

require(effects)
   Loading required package: effects
methods(all)
   [1] all,ddiMatrix-method all,ldiMatrix-method
 all,lsparseMatrix-method
   [4] all,Matrix-methodall,nsparseMatrix-method all.effects

   see '?methods' for accessing help and source code
   

 which wrongly does list your all.effects() among the all
 methods and indeed (even worse), it *is* taken as S3 method
 for all():

ex - structure(FALSE, class=effects)
all(ex)
   Error: $ operator is invalid for atomic vectors
   In addition: Warning message:
   'all.effects' is deprecated.
   Use 'allEffects' instead.
   See help(Deprecated)
   

 ---

 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.

 There is one current work-around -- some would say hack -- in the R
 sources for exceptions on a per package basis, and I will now activate
 that workaround for you.

 Martin

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

Re: [R-pkg-devel] use of `dev.new` across platforms in RStudio

[Martin Maechler]

 Alex Chubaty alex.chub...@gmail.com
 on Fri, 12 Jun 2015 14:41:56 -0700 writes:

 Dear list members,
 Use of platform-specific code to open new plot devices (e.g., `quartz`,
 `x11`) is discouraged in favour of using `dev.new`; however, this does not
 work in RStudio. A purported solution introduced in R 3.1.1 was to call
 `dev.new(noRStudioGD = TRUE)`, which works on Windows, but not OSX and
 Ubuntu. On these paltforms `dev.new` does not open a new plotting window,
 but instead a PDF device writing to file Rplots.pdf.

Oh dear..

Of course this is a very good question from you as a package writer

 How can I open a new plot window in my package in a CRAN-approved way 

I'm not involved in CRAN (but the R project!) but this is really
about tools in R's grDevices package to enable programmeRs to
write platform-portable code. 

Exactly for that reason did we invent and implement dev.new()
even though I was not much envolved in that, I've applauded the
solution (for R 2.7.0, April 2008) quite a bit.   
AFAIK this has become the de facto standard for opening a
graphics device -- if possible interactive -- explicitly and
portably.

I have neither been involved in the creation of the
'noRStudioGD' option, but from looking at  dev.new() it is clear
that it *should* work on all three platforms (Windows, Mac,
Linuxen).

It is really unfortunate that this still does not work reliably
(or stopped working with a new release of something ?)... 

Honestely, I believe it is primarily RStudio's responsibility to
ensure that something standard R as  dev.new()  keeps working in
their interface to R, and if it does not, at least contact the R
developers (R core) about it.
But yes, I don't have the background info about this and really
don't want to through any rocks... 
== rather a friendly CC to get Rstudio's staff attention to
this issue.

 that works reliably across platforms when using RStudio?
 Perhaps this is an issue to take up with RStudio and/or
 R-Devel directly, but I'd appreciate any insights or
 suggestions any of you may have.

See above.  I hope this will be resolvable soon.
It's too bad that R 3.2.1 RC (release candidate) is basically
deep frozen already;  OTOH, if there's very localized
Rstudio-specific patch which would solve the issue ..


 Thank you for your help,
 Alex

You're welcome,
Martin

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