Re: [Rd] [Non-DoD Source] Re: R for the US Air Force

[Ben Bolker]

  For what it's worth

https://www.r-project.org/foundation/board.html

 says

The R Foundation is seated in Vienna, Austria and currently hosted by 
the Vienna University of Economics and Business. It is a registered 
association under Austrian law and active worldwide. The R Foundation 
can be contacted by e-mail to R-foundation at r-project.org



  The statutes here <https://www.r-project.org/foundation/> probably 
won't be useful, but you might be able to get the Austrian registration 
documents from someone at the R foundation (see e-mail above); it seems 
as though that might qualify for lists A and B in your documentation 
specs, and they might be able to provide you with an Austrian tax 
receipt for list C ...


  cheers
    Ben Bolker

On 2024-05-16 4:03 p.m., ADAMS, DOUGLAS L CIV USAF AFMC OO-ALC/OBWA via 
R-devel wrote:

You described it well; I’m afraid that’s what it is.  They want documents of an 
organization that doesn’t fit the description, and only then will they test it.

  


That sounds great.  I’ll reach out to Jeremy and see if he can help me get the 
IDs the USAF wants.  It sounds like Joshua predates my time here.  That’s a 
really good idea.

  


Thanks very much!

  


Doug

  

  


From: Josiah Parry 
Sent: Thursday, May 16, 2024 1:05 PM
To: ADAMS, DOUGLAS L CIV USAF AFMC OO-ALC/OBWA 
Cc: R-devel@R-project.org
Subject: [Non-DoD Source] Re: [Rd] R for the US Air Force

  



You don't often get email from josiah.pa...@gmail.com.  
<https://aka.ms/LearnAboutSenderIdentification> Learn why this is important



Hey Doug,

  


R is not a product that is provided by a company or any vendor that can be 
procured through a vendor e.g. something on a GSA schedule.

  


Seems like you're caught in the bureaucracy hell hole. I used to help the USAF, 
and other DoD members use R when I was at RStudio (now Posit).

  


I recommend you find someone in your organization who is doing Data Science. 
They'll likely have charted a path and you can follow in their footsteps.

For example https://www.linkedin.com/in/joshua-couse/.

  


Jeremy Allen has since taken over my role at Posit since I've left. I'm sure he 
knows a plethora of people in the USAF who are using R and can help you out.

  


https://www.linkedin.com/in/jeremy-allen-data/

  

  

  

  


On Thu, May 16, 2024 at 2:57 PM ADAMS, DOUGLAS L CIV USAF AFMC OO-ALC/OBWA via R-devel 
mailto:r-devel@r-project.org> > wrote:

Hello,



The US Air Force used to have R available on our main network, but now those 
who need to accept it back are
being very particular about what they're accepting in terms of official 
documentation.



Would you be able to help me with this endeavor?  I'm attaching a pdf that 
shows what documentation they'd
require for us to re-establish R as being acceptable on the network here.  I 
understand if you're too busy or
if it's a pain.  Haha



Thank you so much for your help and consideration!



Doug Adams

United States Air Force

Hill AFB, Utah



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


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


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

Re: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement

[Ben Bolker]

   Zenodo and OSF (see e.g. 
) are both non-profit 
organizations that support archiving -- that is, they both make stronger 
guarantees of permanent availability than GitHub does. Possibly Software 
Heritage https://www.softwareheritage.org/features/ ?


  Zenodo has convenient GitHub integration.

On 2024-05-08 4:01 p.m., Josiah Parry wrote:

Thank you, Ivan, for your really thoughtful feedback! I really appreciate
it!

- I'll see if there are any base R packages that support SHA-2 or SHA-3.
- I'll see if I can get the configure.ac to make the appropriate Rscript
call for configure.win.
   - I think the idea of having a single `confgure.ac` file to generate
   both configure and configure.win is nice. Guidance with GitHub
actions and
   ChatGPT is essentially a must for me since my bash is remedial at best.

Regarding the permanent storage requirement, I find it to be very strange.
I've personally never heard of Zenodo until just now! Does the CRAN team
have recommendations for what is considered "as sufficiently reliable?" I
have repos that have persisted for almost 10 years. I think that is
sufficiently reliable!

The requirement to avoid GitHub feels surprisingly anachronistic given how
central it is to the vast majority of software development. The alternative
I can think of is to create a CDN on cloudflare or something to store the
file independently.

Are there any avenues to have CRAN clarify their positions outside of
one-off processes? It would be quite unfortunate to go through all the work
of creating a way to build, store, and retrieve the dependencies only for
CRAN to decide they don't support it.


On Wed, May 8, 2024 at 3:32 PM Ivan Krylov  wrote:


В Wed, 8 May 2024 14:08:36 -0400
Josiah Parry  пишет:


With ChatGPT's ability to write autoconf, I *think *I have something
that can work.


You don't have to write autoconf if your configure.ac is mostly a plain
shell script. You can write the configure script itself. Set the PATH
and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the
regular, non-multiarch configure for Unix-like systems) or exec
"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in
configure.win, which you'll also need). You've already wrote the rest
of the code in a language you know well: R.

Autoconf would be useful if you had system-specific dependencies with
the need to perform lots of compile tests. Those would have been a pain
to set up in R. Here you mostly need sys.which() instead of
AC_CHECK_PROGS and command -v.


The configure file runs tools/get-deps.R which will download the
dependencies from the repo if available and verify the checksums.


One of the pain points is the need for a strong, cryptographically
secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake
build, you would be able to use cmake's built in strong hashes (such as
SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only
requires a "checksum". If you figure out a way to use a strong hash
from tools/configure.R for the downloaded tarball, please let us know.


If the checksums don't match, an error is thrown, otherwise it can
continue. I believe this meets the requirements of CRAN?


The other important CRAN requirement is to store the vendor tarball
somewhere as permanent as CRAN itself (see the caveats at the bottom of
https://cran.r-project.org/web/packages/using_rust.html), that is, not
GitHub. I think that Zenodo counts as a sufficiently reliable store.

--
Best regards,
Ivan



[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Ben Bolker]

 This is true, and useful.

  Many old-school R users are nervous about coming to rely on tools 
that are controlled by a company that may rescind that availability in 
the future, or may possibly use your code in ways you don't want (I have 
not gone all the way through 
https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement 
...)


   For example, Travis was great for CI for a while then pulled the 
plug on free use for public repos, then everyone jumped to GitHub 
actions ...; Microsoft Open R and MRAN were around for a while and then 
weren't ...


  That doesn't mean one should necessarily avoid these tools; it just 
explains why some people do.


On 2024-05-04 1:43 p.m., Maciej Nasinski wrote:

Hey Vladimir,

Thank you for your answer.
GitHub codespaces are "a separate computer" and are free for students and
the educational sector.
The GitHub codespaces are a cloud service that can be created anytime, with
a specific setup behind it (Dockerfile, settings.json, renv.lock,  ...).
The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB
Memory).
You can destroy and recreate it anytime you want to.
You run GitHub codespaces from a web browser, but as Ivan stated, you may
need a decent computer to handle them, even if all calculations are done on
the cloud.
I use GitHub codespaces for all my University projects with my friends.  It
is great that I do not have to explain many things nowadays to older stuff
as many things are automatic on GitHub codespaces.

KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 18:53, Vladimir Dergachev 
wrote:




On Sat, 4 May 2024, Maciej Nasinski wrote:


Thank you all for the discussion.Then, we should promote "code

awareness" and count on the CRAN Team to continue their great work:)


What do you think about promoting containers?
Nowadays, containers are more accessible, with GitHub codespaces being

more affordable (mostly free for students and the educational sector).

I feel containers can help a little bit in making the R work more

secure, but once more when used properly.

I think it is not a good idea to focus on one use case. Some people will
find containers more convenient some don't.

If you want security, I am sure containers are not the right approach -
get a separate physical computer instead.

 From a convenience point of view containers are only ok as long as you
don't need to interface with outside software, then it gets tricky as the
security keeping things containerized starts interfering with getting work
done. (Prime example: firefox snap on ubuntu)

One situation where containers can be helpful is distribution of
commercial applications. Containers allow you to freeze library versions,
so your app can still run with old C library or a specific version of
Python. You can then _hope_ that containers will have fewer compatibility
issues, or at least you can sell containers to your management on this
idea.

But this is not really a good thing for an open source project like R.

best

Vladimir Dergachev



KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 07:17, Vladimir Dergachev 

wrote:



   On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:

   > Dear Maciej Nasinski,
   >
   > On Fri, 3 May 2024 11:37:57 +0200
   > Maciej Nasinski  wrote:
   >
   >> I believe we must conduct a comprehensive review of all

existing CRAN

   >> packages.
   >
   > Why now? R packages are already code. You don't need poisoned

RDS files

   > to wreak havoc using an R package.
   >
   > On the other hand, R data files contain R objects, which contain

code.

   > You don't need exploits to smuggle code inside an R object.
   >

   I think the confusion arises because users expect "R data files"

to only

   contain data, i.e. numbers, but they can contain any R object,

including

   functions.

   I, personally, never use them out of concern that accidentally

saved

   function can override some functionality and be difficult to

debug. And,

   of course, I never save R sessions.

   If you need to pass data it is a good idea to use some common

format like

   tab-separated CSV files with column names. One can also use MVL

files

   (RMVL package).

   best

   Vladimir Dergachev





[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [Rd] [External] View() segfaulting ...

[Ben Bolker]

  A clean build solves it for me too. Thank you!
  (I need to add this to my "have you tried turning it off and back on 
again?" list ...)


  Ben


On 2024-04-25 8:07 a.m., luke-tier...@uiowa.edu wrote:

I saw it also on some of my Ubuntu builds, but the issue went away
after a make clean/make, so maybe give that a try.

Best,

luke

On Wed, 24 Apr 2024, Ben Bolker wrote:

 I'm using bleeding-edge R-devel, so maybe my build is weird. Can 
anyone else reproduce this?


 View() seems to crash on just about anything.

View(1:3)
*** stack smashing detected ***: terminated
Aborted (core dumped)

 If I debug(View) I get to the last line of code with nothing 
obviously looking pathological:


Browse[1]>
debug: invisible(.External2(C_dataviewer, x, title))
Browse[1]> x
$x
[1] "1" "2" "3"

Browse[1]> title
[1] "Data: 1:3"
Browse[1]>
*** stack smashing detected ***: terminated
Aborted (core dumped)




R Under development (unstable) (2024-04-24 r86483)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS

Matrix products: default
BLAS/LAPACK: 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so; 
LAPACK version 3.10.0


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

time zone: America/Toronto
tzcode source: system (glibc)

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

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

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





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

Re: [Rd] View() segfaulting ...

[Ben Bolker]

As suggested by Josh Ulrich, here's what I get when running under 
valgrind.



$ R -d valgrind
==218120== Memcheck, a memory error detector
==218120== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==218120== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright 
info

==218120== Command: /usr/local/lib/R/bin/exec/R
==218120==

R Under development (unstable) (2024-04-24 r86483) -- "Unsuffered 
Consequences"

Copyright (C) 2024 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

gcoto> gctorture(TRUE)
> View(1:3)
*** stack smashing detected ***: terminated
==218120==
==218120== Process terminating with default action of signal 6 (SIGABRT)
==218120==at 0x4D619FC: __pthread_kill_implementation 
(pthread_kill.c:44)

==218120==by 0x4D619FC: __pthread_kill_internal (pthread_kill.c:78)
==218120==by 0x4D619FC: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
==218120==by 0x4D0D475: raise (raise.c:26)
==218120==by 0x4CF37F2: abort (abort.c:79)
==218120==by 0x4D54675: __libc_message (libc_fatal.c:155)
==218120==by 0x4E01599: __fortify_fail (fortify_fail.c:26)
==218120==by 0x4E01565: __stack_chk_fail (stack_chk_fail.c:24)
==218120==by 0x27B686AD: in_R_X11_dataviewer (dataentry.c:540)
==218120==by 0x495C7C7: do_External (dotcode.c:573)
==218120==by 0x499A07F: bcEval_loop (eval.c:8141)
==218120==by 0x49B501C: bcEval (eval.c:7524)
==218120==by 0x49B501C: bcEval (eval.c:7509)
==218120==by 0x49B538A: Rf_eval (eval.c:1167)
==218120==by 0x49B755E: R_execClosure (eval.c:2398)
==218120==
==218120== HEAP SUMMARY:
==218120== in use at exit: 42,061,827 bytes in 9,305 blocks
==218120==   total heap usage: 23,905 allocs, 14,600 frees, 66,039,858 
bytes allocated

==218120==
==218120== LEAK SUMMARY:
==218120==definitely lost: 0 bytes in 0 blocks
==218120==indirectly lost: 0 bytes in 0 blocks
==218120==  possibly lost: 5,868 bytes in 14 blocks
==218120==still reachable: 42,055,959 bytes in 9,291 blocks
==218120==   of which reachable via heuristic:
==218120== newarray   : 4,264 bytes in 1 
blocks

==218120== suppressed: 0 bytes in 0 blocks
==218120== Rerun with --leak-check=full to see details of leaked memory
==218120==
==218120== For lists of detected and suppressed errors, rerun with: -s
==218120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted (core dumped)
bolker:~/R$

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

[Rd] View() segfaulting ...

[Ben Bolker]

  I'm using bleeding-edge R-devel, so maybe my build is weird. Can 
anyone else reproduce this?


  View() seems to crash on just about anything.

View(1:3)
*** stack smashing detected ***: terminated
Aborted (core dumped)

  If I debug(View) I get to the last line of code with nothing 
obviously looking pathological:


Browse[1]>
debug: invisible(.External2(C_dataviewer, x, title))
Browse[1]> x
$x
[1] "1" "2" "3"

Browse[1]> title
[1] "Data: 1:3"
Browse[1]>
*** stack smashing detected ***: terminated
Aborted (core dumped)




R Under development (unstable) (2024-04-24 r86483)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS

Matrix products: default
BLAS/LAPACK: 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so; 
LAPACK version 3.10.0


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

time zone: America/Toronto
tzcode source: system (glibc)

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

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

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

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

On 2024-04-18 9:41 a.m., Uwe Ligges wrote:



On 18.04.2024 15:35, Ben Bolker wrote:
    Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN 
has apparently just caught up to checking.  What's a little 
frustrating (to me) is that the dependence of prediction on ffbase is 
*very* soft ("enhances") ...


No, but CRAN  has still not received an update and asked for this each 
month this year, so in Jan, Feb, and March without a response, so we 
assume prediction is unmaintained. Also, this was escalated to reverse 
depends.


Best,
Uwe Ligges


  Fair enough.  I'm not sure what the last sentence ("this was 
escalated to reverse depends") means though ...


  FWIW I did get an e-mail response from the maintainer two days ago 
suggesting that they were preparing a resubmission ...







On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase 
was no longer available. 
https://cran.r-project.org/web/packages/ffbase/ 
<https://cran.r-project.org/web/packages/ffbase/>


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 <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en 
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid 
haar dossiers volledig digitaal behandelen. Poststukken met de 
vermelding ‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan 
de geadresseerde bezorgd./

www.inbo.be <http://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

///

<https://www.inbo.be>


Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:


    Thank you! (I know about package_dependencies() but ran into
    precisely the same problem and didn't want to re-implement it ...)

    On 2024-04-18 9:11 a.m., Josiah Parry wrote:
 > Well, after trying to install the package, I believe the issue is
 > because margins has been archived.
 >
 > https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>
 > <https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>>
 >
 > You can check recursive dependencies using
 > `tools::package_dependencies("pkg", recursive = TRUE)` which
    would help
 > you in this case. I couldn't run it since the package is not
    available
 > on CRAN, however.
 >
 >
 > On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
 > <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
 >
 >         The 'dotwhisker' package was archived on CRAN: from
 > https://cran.r-project.org/web/packages/dotwhisker/index.html
    <https://cran.r-project.org/web/packages/dotwhisker/index.html>
 >  <https://cran.r-project.org/web/packages/dotwhisker/index.html
    <https://cran.r-project.org/web/packages/dotwhisker/index.html>>
 >
 >           Package ‘dotwhisker’ was removed from the CRAN 
repository

 >           ...
 >
 >           Archived on 2024-04-12 as requires archived package
    'prediction'.
 >
 >          However, I can't for the life of me see where this
    dependence
 >     could
 >     come from. Neither the DESCRIPTION file of the last-archived
    version on
 >     CRAN
 > 
 <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,

 >     nor the version on github
    <https://github.com/fsolt/dotwhisker
    <https://github.com/fsolt/dotwhisker>
 >     &

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

 To clarify, from an off-list conversation:

  AFAICT the chain is

  dotwhisker Imports
 margins, which Imports
   prediction, which Enhances
 ffbase  (archived in 2022 for 'coercion to logical' problems)

 (that conversation also pointed out that Enhances is a dependency *in 
the opposite direction* -- i.e. if A Enhances B, it's not entirely clear 
why the disappearance of B should matter at all ...)




On 2024-04-18 9:35 a.m., Ben Bolker wrote:
    Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN 
has apparently just caught up to checking.  What's a little frustrating 
(to me) is that the dependence of prediction on ffbase is *very* soft 
("enhances") ...


On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase was 
no longer available. https://cran.r-project.org/web/packages/ffbase/ 
<https://cran.r-project.org/web/packages/ffbase/>


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 <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en 
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar 
dossiers volledig digitaal behandelen. Poststukken met de vermelding 
‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan de 
geadresseerde bezorgd./

www.inbo.be <http://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

///

<https://www.inbo.be>


Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:


    Thank you! (I know about package_dependencies() but ran into
    precisely the same problem and didn't want to re-implement it ...)

    On 2024-04-18 9:11 a.m., Josiah Parry wrote:
 > Well, after trying to install the package, I believe the issue is
 > because margins has been archived.
 >
 > https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>
 > <https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>>
 >
 > You can check recursive dependencies using
 > `tools::package_dependencies("pkg", recursive = TRUE)` which
    would help
 > you in this case. I couldn't run it since the package is not
    available
 > on CRAN, however.
 >
 >
 > On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
 > <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
 >
 >         The 'dotwhisker' package was archived on CRAN: from
 > https://cran.r-project.org/web/packages/dotwhisker/index.html
    <https://cran.r-project.org/web/packages/dotwhisker/index.html>
 >  
 <https://cran.r-project.org/web/packages/dotwhisker/index.html

    <https://cran.r-project.org/web/packages/dotwhisker/index.html>>
 >
 >           Package ‘dotwhisker’ was removed from the CRAN 
repository

 >           ...
 >
 >           Archived on 2024-04-12 as requires archived package
    'prediction'.
 >
 >          However, I can't for the life of me see where this
    dependence
 >     could
 >     come from. Neither the DESCRIPTION file of the last-archived
    version on
 >     CRAN
 >  
 <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,

 >     nor the version on github
    <https://github.com/fsolt/dotwhisker
    <https://github.com/fsolt/dotwhisker>
 >     <https://github.com/fsolt/dotwhisker
    <https://github.com/fsolt/dotwhisker>>>, seem to
 >     show any

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

   Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN 
has apparently just caught up to checking.  What's a little frustrating 
(to me) is that the dependence of prediction on ffbase is *very* soft 
("enhances") ...


On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase was 
no longer available. https://cran.r-project.org/web/packages/ffbase/ 
<https://cran.r-project.org/web/packages/ffbase/>


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 <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en 
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar 
dossiers volledig digitaal behandelen. Poststukken met de vermelding 
‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan de 
geadresseerde bezorgd./

www.inbo.be <http://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

///

<https://www.inbo.be>


Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:


    Thank you! (I know about package_dependencies() but ran into
precisely the same problem and didn't want to re-implement it ...)

On 2024-04-18 9:11 a.m., Josiah Parry wrote:
 > Well, after trying to install the package, I believe the issue is
 > because margins has been archived.
 >
 > https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>
 > <https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>>
 >
 > You can check recursive dependencies using
 > `tools::package_dependencies("pkg", recursive = TRUE)` which
would help
 > you in this case. I couldn't run it since the package is not
available
 > on CRAN, however.
 >
 >
 > On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
 > <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
 >
 >         The 'dotwhisker' package was archived on CRAN: from
 > https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>
 >   
  <https://cran.r-project.org/web/packages/dotwhisker/index.html

<https://cran.r-project.org/web/packages/dotwhisker/index.html>>
 >
 >           Package ‘dotwhisker’ was removed from the CRAN repository
 >           ...
 >
 >           Archived on 2024-04-12 as requires archived package
'prediction'.
 >
 >          However, I can't for the life of me see where this
dependence
 >     could
 >     come from. Neither the DESCRIPTION file of the last-archived
version on
 >     CRAN
 >   
  <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,

 >     nor the version on github
<https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>
 >     <https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>>>, seem to
 >     show any signs of importing prediction ... ?? I suppose there's a
 >     possibility of a recursive dependence, but in that case why
wouldn't
 >     the
 >     direct dependence be reported?
 >
 >     Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1),
 >     Imports: grid, gtable, gridExtra, stats, parameters, performance,
 >               patchwork, margins, dplyr, stringr, ggstance,
rlang, purrr
 >     Su

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

  Thank you! (I know about package_dependencies() but ran into 
precisely the same problem and didn't want to re-implement it ...)


On 2024-04-18 9:11 a.m., Josiah Parry wrote:
Well, after trying to install the package, I believe the issue is 
because margins has been archived.


https://cran.r-project.org/web/packages/margins/index.html 
<https://cran.r-project.org/web/packages/margins/index.html>


You can check recursive dependencies using 
`tools::package_dependencies("pkg", recursive = TRUE)` which would help 
you in this case. I couldn't run it since the package is not available 
on CRAN, however.



On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker <mailto:bbol...@gmail.com>> wrote:


    The 'dotwhisker' package was archived on CRAN: from
https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>

      Package ‘dotwhisker’ was removed from the CRAN repository
      ...

      Archived on 2024-04-12 as requires archived package 'prediction'.

     However, I can't for the life of me see where this dependence
could
come from. Neither the DESCRIPTION file of the last-archived version on
CRAN
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz 
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>,
nor the version on github <https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>>, seem to
show any signs of importing prediction ... ?? I suppose there's a
possibility of a recursive dependence, but in that case why wouldn't
the
direct dependence be reported?

Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1),
Imports: grid, gtable, gridExtra, stats, parameters, performance,
          patchwork, margins, dplyr, stringr, ggstance, rlang, purrr
Suggests: ordinal, tibble, knitr, rmarkdown, broom

    What am I missing?

    (I'm concerned because I have packages that Suggest: dotwhisker,
and
the absence of the package from repos is breaking GitHub Actions
checks ...)


    (This is cross-posted from an issue on the dotwhisker GH
repository:
https://github.com/fsolt/dotwhisker/issues/115
<https://github.com/fsolt/dotwhisker/issues/115>)

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

[R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

  The 'dotwhisker' package was archived on CRAN: from 
https://cran.r-project.org/web/packages/dotwhisker/index.html


Package ‘dotwhisker’ was removed from the CRAN repository
...

Archived on 2024-04-12 as requires archived package 'prediction'.

   However, I can't for the life of me see where this dependence could 
come from. Neither the DESCRIPTION file of the last-archived version on 
CRAN 
, 
nor the version on github , seem to 
show any signs of importing prediction ... ?? I suppose there's a 
possibility of a recursive dependence, but in that case why wouldn't the 
direct dependence be reported?


Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1),
Imports: grid, gtable, gridExtra, stats, parameters, performance,
patchwork, margins, dplyr, stringr, ggstance, rlang, purrr
Suggests: ordinal, tibble, knitr, rmarkdown, broom

  What am I missing?

  (I'm concerned because I have packages that Suggest: dotwhisker, and 
the absence of the package from repos is breaking GitHub Actions checks ...)



  (This is cross-posted from an issue on the dotwhisker GH repository: 
https://github.com/fsolt/dotwhisker/issues/115)


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

Re: [Rd] read.csv

[Ben Bolker]

  Tangentially, your code will be more efficient if you add the data 
files to a *list* one by one and then apply bind_rows or 
do.call(rbind,...) after you have accumulated all of the information 
(see chapter 2 of the _R Inferno_). This may or may not be practically 
important in your particular case.


Burns, Patrick. 2012. The R Inferno. Lulu.com. 
http://www.burns-stat.com/pages/Tutor/R_inferno.pdf.



On 2024-04-16 6:46 a.m., jing hua zhao wrote:

Dear R-developers,

I came to a somewhat unexpected behaviour of read.csv() which is trivial but worthwhile 
to note -- my data involves a protein named "1433E" but to save space I drop 
the quote so it becomes,

Gene,SNP,prot,log10p
YWHAE,13:62129097_C_T,1433E,7.35
YWHAE,4:72617557_T_TA,1433E,7.73

Both read.cv() and readr::read_csv() consider prot(ein) name as (possibly 
confused by scientific notation) numeric 1433 which only alerts me when I tried 
to combine data,

all_data <- data.frame()
for (protein in proteins[1:7])
{
cat(protein,":\n")
f <- paste0(protein,".csv")
if(file.exists(f))
{
  p <- read.csv(f)
  print(p)
  if(nrow(p)>0) all_data  <- bind_rows(all_data,p)
}
}

proteins[1:7]
[1] "1433B" "1433E" "1433F" "1433G" "1433S" "1433T" "1433Z"

dplyr::bind_rows() failed to work due to incompatible types nevertheless 
rbind() went ahead without warnings.

Best wishes,


Jing Hua

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


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

Re: [R-pkg-devel] Avoid Possibly misspelled words in DESCRIPTION

[Ben Bolker]

  Based on the information in this thread,

https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010558.html

  I don't think there is any way to suppress these notes. (I have been 
meaning to submit a documentation for _Writing R Extensions_ that talks 
about spell-checking options, which AFAICT isn't actually mentioned 
anywhere in the docs ...)


  What do you mean by "already inserted these words in the WORDLIST"?

  cheers
   Ben Bolker


On 2024-04-12 9:18 a.m., Gabriel Constantino Blain wrote:

Hello,
When I apply the devtools::check_win_devel() to my package it shows the 
following message:

Possibly misspelled words in DESCRIPTION:
   Samani (40:21)
   al (38:45)
   et (38:42)
-
I already inserted these words in the WORDLIST.
Should I use 'Samani' and 'et al.' to prevent this message in the text below?

Description: Calculates daily climate water balance for irrigation purposes.  
The package also calculates the reference 'evapotranspiration' using three 
methods, ('Penman and Monteith') Allen et al. (1998,ISBN:92-5-104219-5),
  Priestley and Taylor (1972) ,
   or Hargreaves and Samani (1985) .
   Users may specify a management allowed depletion ('MAD'), which is
   used by the package to suggest when irrigate. It also allows the use of crop 
and water stress coefficients.

Thanks in advance.

[[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] Package vulnerabilities

[Ben Bolker]

  FWIW there is a repo for R advisories.

https://github.com/RConsortium/r-advisory-database

 with a front-end here

https://osv.dev/list?ecosystem=CRAN=

  At present all of the *reported* vulnerabilities seem to be caused by 
problems with underlying/bundled libraries ...


On 2024-04-03 4:37 p.m., Greg Hunt wrote:

Uwe,
Whether it takes a lot of effort to get malicious code into a company
depends on the pay-off, which can be large relative to the effort.  The
example of the hack before was largely interesting because the priorities
of the package users were fundamentally insecure (higher version number
wins, defaulting to public repositories) and the specific package names
meant that the hack was narrowly targeted, making it less likely to be
discovered than exfiltration code inserted into a widely used package.
Having an identifiable set of package dependencies at any point in time is
a beginning.  Its difficult to effectively control developer behaviour, so
there is a risk there, but what makes it into production can in principle
be identified and controlled.

I had a look at the CVE database, its difficult to identify R package
vulnerabilities there.  Some other searching turned up a couple of
vulnerabilities and some rather promotional blog posts, one of which
asserted that R code is almost always run in controlled environments, which
was sadly hilarious.

Is there a source of vulnerability information for R packages?  Are there
or have there been examples of actually malicious R packages in the wild?


Greg

[[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] help diagnosing win-builder failures

[Ben Bolker]

  I think I may actually have figured this out.

  The Matrix package is being updated to version 1.7.0 soon, with 
expected ABI breakage.  This version is **already installed on 
win-builder/r-devel**, so the Matrix/TMB/glmmTMB binary stack fails 
(digging into the logs a bit deeper showed that the *first* instance of 
a call to glmmTMB in any example/test/prior was failing ...)


  I think the only way to solve this is to bump/re-install the version 
of TMB that lives on win-builder.


  For the record, this will probably bite any package that depends on 
Matrix ABI ...


On 2024-03-17 4:42 p.m., Ivan Krylov wrote:

Hi,

This may need the help of Uwe Ligges to diagnose. I suspect this may be
related to the Windows machine having too much memory committed (as Uwe
has been able to pinpoint recently [*] about a package that failed to
compile some heavily templated C++), but there is not enough information
to give a conclusive diagnosis.

On Sun, 17 Mar 2024 14:01:33 -0400
Ben Bolker  wrote:


2. an ERROR running tests, where the output ends with a cryptic

Anova: ..

(please try to refrain from snarky comments about not using testthat
...)


Pardon my ignorance, but is it an option to upload a version of the
package that uses test_check(pkg, reporter=LocationReporter()) instead
of the summary reporter?


  I don't know, could be worth a try.







  cheers
   Ben Bolker

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

[R-pkg-devel] help diagnosing win-builder failures

[Ben Bolker]

  Hi folks,

  We're in the final stages of preparing a revised version of the 
glmmTMB package for CRAN and are stuck troubleshooting checks on 
win-builder/r-devel.


  Testing is working everywhere *except* win-builder/r-devel. 
Win-builder is OK with r-oldrel and r-devel; the same package is OK on 
GitHub actions with macOS/release, ubuntu/{release, devel} and 
windows/{oldrel, release, devel}: 
https://github.com/glmmTMB/glmmTMB/actions/runs/8316540364


  win-builder/r-devel output is cryptic. It reports:

1. an ERROR in running examples:

Running examples in 'glmmTMB-Ex.R' failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: VarCorr.glmmTMB
> ### Title: Extract variance and correlation components
> ### Aliases: VarCorr.glmmTMB VarCorr
> ### Keywords: internal
>
> ### ** Examples
>
> ## Comparing variance-covariance matrix with manual computation
> data("sleepstudy",package="lme4")
> fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)

(this is the end of this output section.)

2. an ERROR running tests, where the output ends with a cryptic

  Anova: ..

(please try to refrain from snarky comments about not using testthat ...)

3. an ERROR building the vignettes:

--- re-building 'priors.rmd' using rmarkdown
(this is a new vignette, but it builds without a problem everywhere 
else, takes 10 seconds to build locally ...)


Full log is here, at least for a little while: 
https://win-builder.r-project.org/9I5WG5R8WJg3/00check.log


  We could admit defeat and throw ourselves on the CRAN-maintainers' 
mercy, but we would like to resolve these if we can.


  cheers
   Ben Bolker

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

[R-pkg-devel] confusion over spellchecking

[Ben Bolker]

  I am working on a package and can't seem to get rid of a NOTE about

Possibly misspelled words in DESCRIPTION:
  glmmTMB (10:88)
  lme (10:82)

on win-builder.

I have set export _R_CHECK_CRAN_INCOMING_USE_ASPELL_=TRUE locally, and 
have tried to set up the .aspell defaults as specified by Dirk 
Eddelbuettel in  his 2017 blog post 



  I get no spelling NOTEs locally or on GH actions.

 The aspell machinery is here:

https://github.com/bbolker/reformulas/tree/main/.aspell

Following Dirk's blog post, here's what's in those files:

$ cat defaults.R
Rd_files <- vignettes <- R_files <- description <-
list(encoding = "UTF-8",
 language = "en",
 dictionaries = c("en_stats", "reformulas"))

$ r -p -e 'readRDS("reformulas.rds")'
[1] "glmmTMB" "lme"


  In the end I think I'm going to suck it up and put those words in 
quotation marks in the definition, but it feels like I *should* be able 
to have them ignored?


  I have three questions:

 (1) am I missing something in how this should be set up?
 (2) is any of this machinery documented anywhere official? (I couldn't 
find the string "spell" anywhere in _Writing R Extensions_ or the CRAN 
repository policy

 (3) If the answer to #2 is 'no', could/should it be?

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

Re: [Rd] VPAT OR Accessibility Conformance Report Request

[Ben Bolker]

  There was a recent thread here started by someone asking a similar 
question.


https://stat.ethz.ch/pipermail/r-devel/2024-January/083120.html

  You should probably start by going through all of that thread, but 
the bottom line is that:


 * R is in fact very accessible to people with a wide range of challenges
 * unfortunately you are very unlikely to be able to get such a report, 
unless someone volunteers to do one, as R is a volunteer-run project 
(and the developers are generally more interested in maintaining and 
improving the software than satisfying bureaucrats)


  A google search

https://www.google.com/search?q=R+CRAN+VPAT

  suggests that VPATs are available for various third-party 
extensions/packaging of R (Oracle R, RStudio desktop).


  This article is old, but if someone in your IT department read it, 
hopefully they would agree to download the software: 
https://journal.r-project.org/archive/2013-1/godfrey.pdf


On 2024-02-15 12:23 p.m., Zachary Benner wrote:

To Whom It May Concern,
My name is Zach Benner and I am the Accessibility (A.D.A.-Americans with
Disabilities Act) Coordinator here at University of Maine at Machias.  I am
reaching out on the behalf of our science professors here at UMM. The
professor is looking to utilize your software to implement within his
courses however, due to possible accessibility concerns our IT department
will not download the software onto school computers unless we have a copy
of a VPAT or Accessibility Conformance Information Report. I was wondering
if I could obtain this information to provide to the IT department?
Thank you for your time on this matter and I look forward to hearing from
you soon. Please let me know if you have any questions or concerns.
Sincerely,
Zach Benner
Accessibility Coordinator & Student Success Liaison
University of Maine Machias
Office: 229A  Torrey Hall
116 O'Brien Ave
Machias, ME, 04654
Office Number: 207-255-1228

Confidentiality Notice:  This e-mail and any attachments...{{dropped:12}}

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


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

Re: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Ben Bolker]

https://github.com/r-lib/revdepcheck does the 'step 3 twice' part.


  I have had a few issues with it 
 but overall it's been 
very helpful.


https://github.com/HenrikBengtsson/revdepcheck.extras may also be useful.

On 2024-01-30 10:56 a.m., Ivan Krylov via R-package-devel wrote:

Hello R-package-devel,

What would you recommend in order to run reverse dependency checks for
a package with 182 direct strong dependencies from CRAN and 66 from
Bioconductor (plus 3 more from annotations and experiments)?

Without extra environment variables, R CMD check requires the Suggested
packages to be available, which means installing...

revdepdep <- package_dependencies(revdep, which = 'most')
revdeprest <- package_dependencies(
  unique(unlist(revdepdep)),
  which = 'strong', recursive = TRUE
)
length(setdiff(
  unlist(c(revdepdep, revdeprest)),
  unlist(standard_package_names())
))

...up to 1316 packages. 7 of these suggested packages aren't on CRAN or
Bioconductor (because they've been archived or have always lived on
GitHub), but even if I filter those out, it's not easy. Some of the
Bioconductor dependencies are large; I now have multiple gigabytes of
genome fragments and mass spectra, but also a 500-megabyte arrow.so in
my library. As long as a data package declares a dependency on your
package, it still has to be installed and checked, right?

Manually installing the SystemRequirements is no fun at all, so I've
tried the rocker/r2u container. It got me most of the way there, but
there were a few remaining packages with newer versions on CRAN. For
these, I had to install the system packages manually in order to build
them from source.

Someone told me to try the rocker/r-base container together with pak.
It was more proactive at telling me about dependency conflicts and
would have got me most of the way there too, except it somehow got me a
'stringi' binary without the corresponding libicu*.so*, which stopped
the installation process. Again, nothing that a bit of manual work
wouldn't fix, but I don't feel comfortable setting this up on a CI
system. (Not on every commit, of course - that would be extremely
wasteful - but it would be nice if it was possible to run these checks
before release on a different computer and spot more problems this way.)

I can't help but notice that neither install.packages() nor pak() is
the recommended way to install Bioconductor packages. Could that
introduce additional problems with checking the reverse dependencies?

Then there's the check_packages_in_dir() function itself. Its behaviour
about the reverse dependencies is not very helpful: they are removed
altogether or at least moved away. Something may be wrong with my CRAN
mirror, because some of the downloaded reverse dependencies come out
with a size of zero and subsequently fail the check very quickly.

I am thinking of keeping a separate persistent library with all the
1316 dependencies required to check the reverse dependencies and a
persistent directory with the reverse dependencies themselves. Instead
of using the reverse=... argument, I'm thinking of using the following
scheme:

1. Use package_dependencies() to determine the list of packages to test.
2. Use download.packages() to download the latest version of everything
if it doesn't already exist. Retry if got zero-sized or otherwise
damaged tarballs. Remove old versions of packages if a newer version
exists.
3. Run check_packages_in_dir() on the whole directory with the
downloaded reverse dependencies.

For this to work, I need a way to run step (3) twice, ensuring that one
of the runs is performed with the CRAN version of the package in the
library and the other one is performed with the to-be-released version
of the package in the library. Has anyone already come up with an
automated way to do that?

No wonder nobody wants to maintain the XML package.



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

Re: [R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols

[Ben Bolker]

  Are you sure the issue that CRAN has is the library sizes, and not 
the issues flagged by the "LTO" platform 
 ?


https://www.stats.ox.ac.uk/pub/bdr/LTO/rar.out

  I would check with CRAN for clarification before you spend a lot of 
time trying to reduce package sizes. As you point out, lots of packages 
on CRAN have package sizes large enough to trigger this note -- it is my 
impression that CRAN only object if the large package size is considered 
unnecessary; some of the *inappropriate* reasons for large package size 
are listed in the repository policy 



===
Packages should be of the minimum necessary size. Reasonable compression 
should be used for data (not just .rda files) and PDF documentation: 
CRAN will if necessary pass the latter through qpdf.


As a general rule, neither data nor documentation should exceed 5MB 
(which covers several books). A CRAN package is not an appropriate way 
to distribute course notes, and authors will be asked to trim their 
documentation to a maximum of 5MB.


Where a large amount of data is required (even after compression), 
consideration should be given to a separate data-only package which can 
be updated only rarely (since older versions of packages are archived in 
perpetuity).


Similar considerations apply to other forms of “data”, e.g., .jar files.

Source package tarballs should if possible not exceed 10MB. It is much 
preferred that third-party source software should be included within the 
package (as e.g. a vendor.tar.xz file) than be downloaded at 
installation: if this requires a larger tarball a modestly increased 
limit can be requested at submission.



On 2024-01-20 2:38 p.m., Johann Gaebler wrote:

Hi everyone,

I received the following message regarding  `rar` 
, a package that I put up on CRAN two 
days ago:


Dear maintainer,

Please see the problems shown on
.

Please correct before 2024-02-02 to safely retain your package on CRAN.


The issue is that the compiled libraries are too large. The Mac CRAN checks 
turned up the following note:


installed size is  8.9Mb
sub-directories of 1Mb or more:
  libs   8.7Mb


I have not been able to reproduce the issue either locally or on any machine I 
have ready access to. I have built it on some of the Rhub and R-Project build 
systems, and the same issue (with very different `libs` sizes) came up on some 
of them:

• (RHub) Ubuntu Linux 20.04.1 LTS, R-release, GCC: 18.2Mb,
• (RHub) Fedora Linux, R-devel, clang, gfortran: 6.8Mb,
• (R-Project) r-release-macosx-arm64: 8.5Mb.

Based on trying to read up about this, it seems that this is a pretty common problem 
 
for compiled packages because of debugging symbols getting inserted into the shared 
library file. Using the fix from that blog post where you modify the Makevars to 
strip debugging symbols from the shared library seems to solve the issue on those 
build systems, so I feel reasonably confident that this is what’s going on.

Apparently many, many existing packages on CRAN have the same issue. However, 
I’m very new to R package development, so I’m not exactly sure what to do. I 
have two questions:

1. Is there anything I need to “fix” here, or should I just make contact with 
the CRAN folks and bring the fact that this is being caused by debugging 
symbols to their attention?
2. Regardless of whether or not I have to fix this issue for CRAN, is there a 
way to strip out the debugging symbols that comports with CRAN policies? The 
method suggested in the blog post above (adding a phony target in `Makevars` 
that strips the shared library) seems not to be CRAN-compliant, but I could be 
mistaken about that. (In particular, I had to modify it locally to get it to 
run, so I’m not sure what the platform-independent version of it looks like.)

Thanks in advance for the help!

Sincerely,
Johann D. Gaebler
[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [Rd] ADA Compliance

[Ben Bolker]

 I would be very surprised if anyone had written up a VPAT 
<https://www.section508.gov/sell/vpat/> for R.


  It won't help you with the bureaucratic requirements, but R is in 
fact very accessible to visually impaired users: e.g. see



https://community.rstudio.com/t/accessibility-of-r-rstudio-compared-to-excel-for-student-that-is-legally-blind/103849/3

From https://github.com/ajrgodfrey/BrailleR

> R is perhaps the most blind-friendly statistical software option 
because all scripts can be written in plain text, using the text editor 
a user prefers, and all output can be saved in a wide range of file 
formats. The advent of R markdown and other reproducible research 
techniques can offer the blind user a degree of efficiency that is not 
offered in many other statistical software options. In addition, the 
processed Rmd files are usually HTML which are the best supported files 
in terms of screen reader development.


  (And there is continued attention to making sure R stays accessible 
in this way: 
https://stat.ethz.ch/pipermail/r-devel/2022-December/082180.html; 
https://stat.ethz.ch/pipermail/r-devel/2023-February/082313.html)


  R is also easy to use without a mouse, which should improve 
accessibility for users with neuromuscular conditions.


   cheers
Ben Bolker




On 2024-01-12 2:50 p.m., Hunter, Zayne via R-devel wrote:

Hello,


I am working with Ball State University to obtain a license of R. As part of 
our requirements for obtaining new software, we must review the VPAT for ADA 
compliance. Can you provide this information for me?

Thanks,


Zayne Hunter
Technology Advisor & Vendor Relations Manager
Ball State University
zayne.hun...@bsu.edu
(765)285-7853






[[alternative HTML version deleted]]

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


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

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

[Ben Bolker]

  Thanks. Pursuing this a bit further, from ?tar "Known problems":

 The handling of file paths of more than 100 bytes.  These
were unsupported in early versions of ‘tar’, and supported in
one way by POSIX ‘tar’ and in another by GNU ‘tar’ and yet
another by the POSIX ‘pax’ command which recent ‘tar’
programs often support.  The internal implementation warns on
paths of more than 100 bytes, uses the ‘ustar’ way from the
1998 POSIX standard which supports up to 256 bytes (depending
on the path: in particular the final component is limited to
100 bytes) if possible, otherwise the GNU way (which is
widely supported, including by ‘untar’).

  This issue is reminiscent of the "invalid uid value replaced ..." 
warning, which has happened to me a lot but which CRAN has never 
actually flagged when I've submitted a package:


https://stackoverflow.com/questions/30599326/warning-message-during-building-an-r-package-invalid-uid-value-replaced-by-that

 (By the way, this thread now seems firmly on-topic for r-pkg-devel, 
even if the ultimate answers must come from the CRAN maintainers ...)


  cheers
   Ben



On 2023-12-12 3:41 p.m., Duncan Murdoch wrote:
I don't know what the warning looks like, but the ?tar help page 
discusses the issues.


Duncan Murdoch

On 12/12/2023 3:10 p.m., Ben Bolker wrote:

   FWIW the R-windows FAQ says:

Yet another complication is a 260 character limit on the length of the
entire path name imposed by Windows. The limit applies only to some
system functions, and hence it is possible to create a long path using
one application yet inaccessible to another. It is sometimes possible to
reduce the path length by creating a drive mapping using subst and
accessing files via that drive. As of Windows 10 version 1607 and R 4.3,
one can remove this limit via Windows registry by setting
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
to 1. Long paths still may not always work reliably: some applications
or packages may not be able to work with them and Windows cannot execute
an application with long path as the current directory.

    I'm having trouble finding the specific check for path lengths > 100
in the R source tree.  It would be helpful to have the exact wording of
the NOTE/WARNING (?) that is thrown ...  (I know I could make my own
mini-package with a long path length in it somewhere but ...)

    cheers
 Ben Bolker

On 2023-12-12 2:57 p.m., Simon Urbanek wrote:

Justin,

now that you clarified what you are actually talking about, this is a 
question about the CRAN policies, so you should really direct it to 
the CRAN team as it is their decision (R-devel would be appropriate 
if this was a limitation in R itself, and R-package-devel would be 
appropriate if you wanted help with refactoring to adhere to the 
policy). There are still path limits on various platforms (even if 
they are becoming more rare), so I'd personally question the source 
rather than the policy, but then your email was remarkably devoid of 
any details.


Cheers,
Simon


On Dec 13, 2023, at 6:03 AM, McGrath, Justin M 
 wrote:


When submitting a package to CRAN, it is required that path names be 
shorter than 100 bytes, with the reason that paths longer than that 
cannot be made into portable tar files. This error is reported by `R 
CMD check --as-cran`. Since this pertains only to developing 
packages, this seemed like the appropriate list, but if you don't 
think so, I can instead ask on R-devel.


Best wishes,
Justin


From: Martin Maechler 
Sent: Tuesday, December 12, 2023 10:13 AM
To: McGrath, Justin M
Cc: r-package-devel@r-project.org
Subject: Wrong mailing list: [R-pkg-devel] Could the 100 byte path 
length limit be lifted?



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] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Ben Bolker]

 FWIW the R-windows FAQ says:

Yet another complication is a 260 character limit on the length of the 
entire path name imposed by Windows. The limit applies only to some 
system functions, and hence it is possible to create a long path using 
one application yet inaccessible to another. It is sometimes possible to 
reduce the path length by creating a drive mapping using subst and 
accessing files via that drive. As of Windows 10 version 1607 and R 4.3, 
one can remove this limit via Windows registry by setting 
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled 
to 1. Long paths still may not always work reliably: some applications 
or packages may not be able to work with them and Windows cannot execute 
an application with long path as the current directory.


  I'm having trouble finding the specific check for path lengths > 100 
in the R source tree.  It would be helpful to have the exact wording of 
the NOTE/WARNING (?) that is thrown ...  (I know I could make my own 
mini-package with a long path length in it somewhere but ...)


  cheers
   Ben Bolker

On 2023-12-12 2:57 p.m., Simon Urbanek wrote:

Justin,

now that you clarified what you are actually talking about, this is a question 
about the CRAN policies, so you should really direct it to the CRAN team as it 
is their decision (R-devel would be appropriate if this was a limitation in R 
itself, and R-package-devel would be appropriate if you wanted help with 
refactoring to adhere to the policy). There are still path limits on various 
platforms (even if they are becoming more rare), so I'd personally question the 
source rather than the policy, but then your email was remarkably devoid of any 
details.

Cheers,
Simon



On Dec 13, 2023, at 6:03 AM, McGrath, Justin M  wrote:

When submitting a package to CRAN, it is required that path names be shorter 
than 100 bytes, with the reason that paths longer than that cannot be made into 
portable tar files. This error is reported by `R CMD check --as-cran`. Since 
this pertains only to developing packages, this seemed like the appropriate 
list, but if you don't think so, I can instead ask on R-devel.

Best wishes,
Justin


From: Martin Maechler 
Sent: Tuesday, December 12, 2023 10:13 AM
To: McGrath, Justin M
Cc: r-package-devel@r-project.org
Subject: Wrong mailing list: [R-pkg-devel] Could the 100 byte path length limit 
be lifted?


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



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


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

Re: [Rd] Base R wilcox.test gives incorrect answers, has been fixed in DescTools, solution can likely be ported to Base R

[Ben Bolker]

  You could request a bugzilla account and post it to 
https://bugs.r-project.org/ yourself: from 
https://www.r-project.org/bugs.html,


> In order to get a bugzilla account (i.e., become “member”), please 
send an e-mail (from the address you want to use as your login) to 
bug-report-requ...@r-project.org briefly explaining why, and a volunteer 
will add you to R’s Bugzilla members.


  (On the other hand, I think that posting to this list was a good idea 
in any case, as it is more visible than the bugs list and may spark some 
useful discussion.)


   cheers
   Ben Bolker


On 2023-12-11 9:44 a.m., tkp...@gmail.com wrote:

While using the Hodges Lehmann Mean in DescTools (DescTools::HodgesLehmann),
I found that it generated incorrect answers (see
<https://github.com/AndriSignorell/DescTools/issues/97>
https://github.com/AndriSignorell/DescTools/issues/97). The error is driven
by the existence of tied values forcing wilcox.test in Base R to switch to
an approximate algorithm that returns incorrect results - see
<https://aakinshin.net/posts/r-hodges-lehmann-problems/>
https://aakinshin.net/posts/r-hodges-lehmann-problems/ for a detailed
exposition of the issue.

  


Andri Signorell and Cyril Moser have a new C++ implementation of
DescTools::HodgesLehmann using a O(N log(N)) algorithm due to Monahan, but
wilcox.test in Base R appears to be still broken. Will someone kindly bring
this observation, as well as the existence of a solution, to the attention
of the relevant person(s) in the Base R development team?

  


The paper by Mohanan, as well as the original Fortran implementation of the
algorithm are linked to from
<https://github.com/AndriSignorell/DescTools/issues/97>
https://github.com/AndriSignorell/DescTools/issues/97). Inefficient O(N^2)
algorithms for the Hodges-Lehmann mean are known and are implemented in a
variety of packages. For example, the authors of rt.test
(https://cran.r-project.org/web/packages/rt.test) use the O(N^2) approach. I
suspect that Andri and Cyril will be more than happy to assist with fixing
wilcox.test in Base R with their implementation of Monahan's fast algorithm.

  


Sincerely

  


Thomas Philips

  



[[alternative HTML version deleted]]

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


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

[Rd] option to silence/quieten stats::confint.glm ?

[Ben Bolker]

   confint.glm prints a message "Waiting for profiling to be done..."

   I could have sworn that there used to be an option (quiet = TRUE?) 
to turn this message off without resorting to suppressMessages() 
(finer/more specific control is always preferable ...) -- but on the 
basis of looking back at archived versions of MASS, and at this Stack 
Overflow post:


https://stackoverflow.com/questions/43847705/how-do-i-silence-confint-in-r

 I think I was hallucinating.

 Do people think this would be a reasonable minor feature request/would 
a patch suggestion be considered? What would the  best name for the 
argument be? (scan() has "quiet")


pos <- tail(search(), 1)  ## base package
tt <- lapply(c(lsf.str(pos = pos)), \(x) names(formals(x))) |> unlist() 
|> table()

> tt[["quiet"]]
[1] 4
> tt[["silent"]]
[1] 1
> tt[["verbose"]]
[1] 9


   cheers
 Ben Bolker

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

Re: [R-pkg-devel] NOTE: Examples with CPU time > 2.5 times elapsed time

[Ben Bolker]

Wow.

On Mon, Dec 4, 2023, 5:43 PM Ivan Krylov  wrote:

> Dear Artur,
>
> You've got a well-written package. There are some parts I wasn't able
> to understand (e.g. changing the class of a variable by reference using
> SET_CLASS and later changing it back), but there are no obvious places
> where a mistake could be hiding.
>
> On Fri, 1 Dec 2023 23:43:32 +
> Artur Araujo  wrote:
>
> > Examples with CPU time > 2.5 times elapsed time
> > user system elapsed  ratio
> > contour.TPCmsm 2.605  0.132   0.108 25.343
>
> I managed to reproduce this, but not before compiling R-devel r85646
> on a Debian Testing virtual machine using clang-17 and flang-17 with
> libomp-17-dev installed. In particular, this doesn't seem to happen
> with latest R-devel built using (much older versions of) the GNU
> toolchain.
>
> There was a false start where I saw pthread_create breakpoints hit
> inside libpango while contour() was running, but that couldn't be your
> problem because examples run with the pdf() device active. Instead,
> when source()ing the TPmsm-Ex.R file, the breakpoint fired elsewhere:
>
> ### Name: as.data.frame.survTP
> ### Title: as.data.frame method for a survTP object
> ### Aliases: as.data.frame.survTP
> ### Keywords: manip metho  [TRUNCATED]
>
> Breakpoint 7, __pthread_create_2_1 (newthread=0x7fff5a70,
> attr=0x7fff5a78, start_routine=0x775882a0 <__kmp_launch_worker()>,
> arg=0x572d9e80)
> at ./nptl/pthread_create.c:623
> (gdb) bt
> #0  __pthread_create_2_1 (newthread=0x7fff5a70, attr=0x7fff5a78,
> start_routine=0x775882a0 <__kmp_launch_worker()>, arg=0x572d9e80)
> at ./nptl/pthread_create.c:623
> #1  0x775879b4 in __kmp_create_worker () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/z_Linux_util.cpp:795
> #2  0x77518899 in __kmp_allocate_thread () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_runtime.cpp:4677
> #3  0x7751078a in __kmp_allocate_team () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_runtime.cpp:5384
> #4  0x77511813 in __kmp_fork_call () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_runtime.cpp:2122
> #5  0x774ffc81 in __kmpc_fork_call () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_csupport.cpp:300
> #6  0x7465100e in cens2 (pT1=, pE1=,
> pS=, pE=, pn=,
> tfunc=,
> pcorr=, pdistpar=, cfunc= out>, pcenspar=, pstate2prob=) at dgpTP.c:83
> #7  dgpTP (n=, corr=, dist=,
> distpar=, modelcens=, censpar= out>,
> state2prob=) at dgpTP.c:178
> #8  0x55645cba in R_doDotCall (fun=0x0, nargs=nargs@entry=7,
> cargs=cargs@entry=0x7fff63b0, call=call@entry=0x573b62b8)
> at ../../../R-svn/src/main/dotcode.c:1498
> (gdb) frame 6
> #6  0x7465100e in cens2 (pT1=, pE1=,
> pS=, pE=, pn=,
> tfunc=,
> pcorr=, pdistpar=, cfunc= out>, pcenspar=, pstate2prob=) at dgpTP.c:83
> 83  #pragma omp parallel num_threads(global_num_threads)
> (gdb) p global_num_threads
> $4 = 8
>
> Not sure why the CPU time gets counted for the contour() example
> instead of as.data.frame.survTP - do libomp threads not get counted
> until they terminate or something? - but since the contour.TPCmsm
> example directly follows as.data.frame.survTP, the call to dgpTP here
> must be the culprit.
>
> I would like to suggest a new diagnostic for the CPU time / elapsed
> time tests. If any examples have been found to exceed the time ratio
> limit and R is running on Linux with a special environment variable
> set, the examples should be re-run under a debugger. The debugger
> should set a breakpoint on the clone _system call_ (ideally, all system
> calls that can create threads or child processes) and print a C-level
> backtrace when it fires. Ideally, it should call something like
> R_ConciseTraceback to obtain an R-level traceback too, but it's not an
> API (at least yet) and I'm not sure it's generally safe to do this in
> the middle of an R call. If there is interest, I can try to see if gdb
> can be scripted to make this happen. I think it must be a ptrace
> debugger and not an LD_PRELOAD wrapper because there are too many ways
> to start threads and processes. For example, with libomp,
> pthread_create() breakpoints fire while clone() breakpoints do not,
> despite something later does make the clone() system call.
>
> This won't help if the threads get started separately and only later
> get utilised in a different example, but I wasn't able to put the
> output of `perf report` for good use when debugging similar problems in
> a different package. Other ideas for tracing the CPU usage culprits are
> also welcome.
>
> --
> Best regards,
> Ivan
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__

Re: [R-pkg-devel] Question regarding finding the source file location without R-packages outside of R-Studio

[Ben Bolker]

Not sure, but I think the 'here' package might do what you want. It's
tidyverse-affiliated but pretty stable

On Thu, Nov 23, 2023, 2:39 PM Tony Wilkes  wrote:

> Hi everyone,
>
> I have a question. I hope it's not a stupid question.
>
> Suppose you'd want to perform version control and project isolation. You'd
> create a project folder (let's call it "MyProject"), and place all the R
> packages you need for that project inside a subfolder (let's say
> "MyProject/MyLibrary"). Now you create and run an R-script in "MyProject".
> install.packages(), library(), etc. all have a lib.loc argument to specify
> the library path. So one can manually specify the path of your project, and
> then you'd have your project isolation and version control fully set-up.
>
> But if I want to set-up the library path automatically, to make it
> portable, I would need to determine the script location. In RStudio I can
> use the 'rstudioapi' package, which is very stable, and so does not really
> require version control. But for outside R-Studio, I have not found a very
> stable package that also works.
> I prefer not using external R packages that requires version control (i.e.
> a package that changes often-ish): you'd need the package to access the
> project library, but the project library to access the package.
>
> This brings me to my actual question: is it possible to determine the
> source file location of an R script outside of R-Studio, without resorting
> to R packages ? Or else use an R package that is VERY stable (i.e. doesn't
> change every (half) a year, like tidyverse packages tend to do)?
> commandArgs() used to contain the script path (apparently), but it doesn't
> work for me.
>
> By the way: I wish to get the script path in an interactive session.
>
> Thank you in advance.
>
> Kind regards,
>
> Tony
>
>
> [[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

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

[Ben Bolker]

  You may also be able to use Rprintf ? 
https://teuder.github.io/rcpp4everyone_en/060_printing_massages.html


On 2023-11-18 8:07 p.m., Iris Simmons wrote:

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);
Rf_error(msg);

or however large you made the error string.


On Sat, Nov 18, 2023, 20:01 Iago Giné-Vázquez 
wrote:


Dear all,

I am updating a CRAN-archived R package, so it can get back to CRAN. But
there is a warning produced in Linux OS that I am not sure to understand
and I do not know how to solve, even after looking at ‘Writing portable
packages’ in the ‘Writing R Extensions’ manual and after searching in the
web. The warning is


* checking compiled code ... WARNING
File ‘ccckc/libs/ccckc.so’:
Found ‘sprintf’, possibly from ‘sprintf’ (C)
Object: ‘criteria.o’

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor use Fortran I/O
nor system RNGs nor [v]sprintf.
See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.


The package contains both C and Fortran code and in the criteria.c there
is only a sprintf use, as follows:

sprintf(msg,"criteria: error (%d) -> %s\n", inErr, errStr);
Rf_error(msg);
May be the reason of the warning the next line the ‘Writing R Extensions’
manual?


Use ofsprintfandvsprintfis regarded as a potential security risk and

warned about on some platforms.[82](
https://cran.r-project.org/doc/manuals/R-exts.html#FOOT82)R CMD
checkreports if any calls are found.

If that is the reason, is there any alternative to the use of sprintf?
Anyway, what can I do?

Thanks you in advance for your time.

Kind regards,
Iago

Sent with [Proton Mail](https://proton.me/) secure email.
 [[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] What happened to mlr3proba on CRAN?

[Ben Bolker]

Based on 
https://cran-archive.r-project.org/web/checks/2022/2022-05-16_check_results_mlr3proba.html


  it looks like there were problems with the code (possibly harmless, 
but very unlikely to be exactly as intended) when R started throwing an 
error when vectors of length >1 were used with the && operator; this 
happened with R 4.3.0


https://cran-archive.r-project.org/web/checks/2022/2022-05-16_check_results_mlr3proba.html

\subsection{SIGNIFICANT USER-VISIBLE CHANGES}{
\itemize{
  \item Calling \code{&&} or \code{||} with LHS or (if evaluated) 
RHS of

  length greater than one is now always an error, with a report of
  the form
\preformatted{'length = 4' in coercion to 'logical(1)'}

  Since the errors weren't corrected, the package was archived.

  You can find the maintainer's email in the DESCRIPTION file here: 
https://cran.r-project.org/src/contrib/Archive/mlr3proba/mlr3proba_0.4.9.tar.gz 
  if you want to follow up with them ...


  cheers
   Ben Bolker


On 2023-10-08 5:28 p.m., Dr. Franz Király wrote:

Dear all,

can someone explain to me what exactly happened to mlr3proba on CRAN?
https://cran.r-project.org/web/packages/mlr3proba/index.html

Thanks
Franz


[[alternative HTML version deleted]]

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


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

Re: [Rd] Minor bug with stats::isoreg

[Ben Bolker]

  Thanks! Submitted as https://bugs.r-project.org/show_bug.cgi?id=18603


On 2023-09-27 4:49 p.m., Travers Ching wrote:

Hello, I'd like to file a small bug report. I searched and didn't find a
duplicate report.

Calling isoreg with an Inf value causes a segmentation fault, tested on R
4.3.1 and R 4.2. A reproducible example is: `isoreg(c(0,Inf))`

[[alternative HTML version deleted]]

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


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

Re: [Rd] NROW and NCOL on NULL

[Ben Bolker]

   This is certainly worth discussing, but there's always a heavy 
burden of back-compatibility; how much better would it be for NCOL and 
NROW to both return zero, vs. the amount of old code that would be broken?


  Furthermore, the reason for this behaviour is justified as 
consistency with the behaviour of as.matrix() and cbind() for 
zero-length vectors, from ?NCOL:


 ## as.matrix() produces 1-column matrices from 0-length vectors,
 ## and so does cbind() :

 (of course you could argue that this behaviour should be changed as 
well ...)



On 2023-09-23 3:41 p.m., Simone Giannerini wrote:

I know it's documented and I know there are other ways to guard
against this behaviour, once you know about this.
The point is whether it might be worth it to make NCOL and NROW return
the same value on NULL and make R more consistent/intuitive and
possibly less error prone.

Regards,

Simone

On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch  wrote:


It's been documented for a long time that NCOL(NULL) is 1.  What
particular problems did you have in mind?  There might be other ways to
guard against them.

Duncan Murdoch

On 23/09/2023 1:43 p.m., Simone Giannerini wrote:

Dear list,

I do not know what would be the 'correct' answer to the following but
I think that they should return the same value to avoid potential
problems and hard to debug errors.

Regards,

Simone
---


NCOL(NULL)

[1] 1


NROW(NULL)

[1] 0


sessionInfo()

R version 4.3.1 RC (2023-06-08 r84523 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 11 x64 (build 22621)

Matrix products: default


locale:
[1] LC_COLLATE=Italian_Italy.utf8  LC_CTYPE=Italian_Italy.utf8
[3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C
[5] LC_TIME=Italian_Italy.utf8

time zone: Europe/Rome
tzcode source: internal

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

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








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

Re: [R-pkg-devel] Suppressing compiler warnings?

[Ben Bolker]

  This also doesn't answer your question, but:

A trick that the TMB package uses to help users is to suggest that they 
add "CXXFLAGS += -Wno-ignored-attributes" to their `.R/Makevars` file. 
This means that *they* don't have to see useless warnings when compiling 
code.


  In your case I don't know if there is a compiler flag that is 
equivalent to your pragma, or you could add your own macro/#ifdef 
(CXXFLAGS += -DSUPPRESS_WARNINGS) so that *you* don't have to see the 
warning messages. (If CRAN doesn't want to see all the warnings that's 
their problem ...)



On 2023-08-14 8:59 a.m., Mark Padgham wrote:


On 14/08/2023 14:43, Dirk Eddelbuettel wrote:

On 14 August 2023 at 11:51, Mark Padgham wrote:
| An update of a package of mine got immediately kicked off CRAN because
| an externally-bundled file which had not been changed for years, and
| which included "pragma clang system_header" to suppress warnings. The
| concern is fair enough. Removing that nevertheless now generates a heap
| of warnings which CRAN will have to wade through / grep to assess
| whether any are of concern. These can be easily suppressed by replacing
| cheap "system_header" with targeted suppression of just two classes of
| warnings for that bundled header file only. But I guess this is also
| forbidden? Should I now just leave those warnings, and rely on CRAN's
| grep policies to assess them? Is there any public list of what such 
grep

| policies might be? (And no, I can't adapt the code to remove the
| warnings, because most are "zero-as-null-pointer-constant", but the "0"
| is actually better than nullptr the way the code is constructed. The
| rest are - currently - unimportant deprecation warnings, all of one
| specific class.)

It is in the CRAN Repostory Policy:

    - Packages should not attempt to disable compiler diagnostics, nor to
  remove other diagnostic information such as symbols in shared 
objects.


Per 'svn blame' it goes back to commit 4049 from Apr 2019, but a 
commit from

Nov 2017 has 'memtion (sic!) not disabling compiler diagnostics'.

FWIW I have had to do it for BH and RcppEigen for some time leading to 
both
of them 'spamming' package users with a lot of noise. I don't 
particularly

like that, but I also do not have too many choices here.

Dirk


Thanks Dirk! I've seen also that a couple of tidyverse and r-lib pkgs
bundle the same header, and they also do nothing to suppress this
compiler spam. But gee it would be good to have some "official"
reference for what compiler warnings CRAN are likely to complain about,
and which ones they'll ignore!

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

[R-pkg-devel] status of "possibly invalid URL/403 error" NOTEs?

[Ben Bolker]

  I have a package whose documentation includes the reference 
\doi{10.1137/18M1186411} which redirects here:

https://epubs.siam.org/doi/10.1137/18M1186411

Running R CMD check --as-cran on the package gives

Found the following (possibly) invalid URLs:
  URL: https://epubs.siam.org/doi/10.1137/18M1186411
From: man/llig.Rd
Status: 403
Message: Forbidden

  I can access this perfectly well in the browser.

  Is there any way to avoid this (other than, say, including the URL in 
a form that does *not* provide a link so that R CMD check won't try to 
access it? (As Uwe Ligges says 
[here](https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005195.html) 
(for a more obviously problematic case), "mention the URL in plain text 
but not link"


  Here Hadley Wickham says that these NOTEs can be ignored

https://twitter.com/hadleywickham/status/1358170607314235392

but "Hadley said it on twitter" is not an ideal source. The CRAN 
repository policy says that packages must pass checks without 
"significant" notes, but it's always hard to know what's significant and 
what's not ...


  There's a thread here: 
https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005171.html


   Tangentially: is there a more convenient way to search the 
r-package-devel archives than googling (e.g.) 
"site:https://stat.ethz.ch/pipermail/r-package-devel  403" ?


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

Re: [R-pkg-devel] LICENSE file in an R package for CRAN submission

[Ben Bolker]

In case you're thinking of putting the package on CRAN, note also from 
the CRAN policy https://cran.r-project.org/web/packages/policies.html:


> Packages with licenses not listed at 
https://svn.r-project.org/R/trunk/share/licenses/license.db will 
generally not be accepted.


On 2023-08-09 11:15 a.m., Ben Bolker wrote:

    You have two choices:

* put LICENSE in your .Rbuildignore file so that it shows up on Github 
but is excluded from the package


* follow the instructions in 
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing to refer to 
LICENSE in your DESCRIPTION file. However, CRAN generally prefers that 
you use a standard license ("GPL-2", "GPL-3"), to make it easier for 
them to know that you've really complied with their openness 
requirements, and that you *not* include a license file that is 
redundant with that spec:


 > Whereas you should feel free to include a license file in your source 
distribution, please do not arrange to install yet another copy of the 
GNU COPYING or COPYING.LIB files but refer to the copies on 
https://www.R-project.org/Licenses/ and included in the R distribution 
(in directory share/licenses). Since files named LICENSE or LICENCE will 
be installed, do not use these names for standard license files. To 
include comments about the licensing rather than the body of a license, 
use a file named something like LICENSE.note.


On 2023-08-09 11:06 a.m., Emanuele Cordano wrote:

Dear list,

is there a way to put the LICENSE file within an R package like in 
Github,
I have an R package on Github with a a LICENSE file compliant to 
Github and
containing the text of the licence citing in the DESCRIPION file. But 
when

I check the package , I obatained the following output:

* checking top-level files ... NOTE
File
   LICENSE

is not mentioned in the DESCRIPTION file.

How can I solve this?
Thank you
best
Emanuele Cordano




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] LICENSE file in an R package for CRAN submission

[Ben Bolker]

   You have two choices:

* put LICENSE in your .Rbuildignore file so that it shows up on Github 
but is excluded from the package


* follow the instructions in 
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing to refer to 
LICENSE in your DESCRIPTION file. However, CRAN generally prefers that 
you use a standard license ("GPL-2", "GPL-3"), to make it easier for 
them to know that you've really complied with their openness 
requirements, and that you *not* include a license file that is 
redundant with that spec:


> Whereas you should feel free to include a license file in your source 
distribution, please do not arrange to install yet another copy of the 
GNU COPYING or COPYING.LIB files but refer to the copies on 
https://www.R-project.org/Licenses/ and included in the R distribution 
(in directory share/licenses). Since files named LICENSE or LICENCE will 
be installed, do not use these names for standard license files. To 
include comments about the licensing rather than the body of a license, 
use a file named something like LICENSE.note.


On 2023-08-09 11:06 a.m., Emanuele Cordano wrote:

Dear list,

is there a way to put the LICENSE file within an R package like in Github,
I have an R package on Github with a a LICENSE file compliant to Github and
containing the text of the licence citing in the DESCRIPION file. But when
I check the package , I obatained the following output:

* checking top-level files ... NOTE
File
   LICENSE

is not mentioned in the DESCRIPTION file.

How can I solve this?
Thank you
best
Emanuele Cordano


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [Rd] A demonstrated shortcoming of the R package management system

[Ben Bolker]

  I would support this suggestion.  There is a similar binary 
dependency chain from Matrix → TMB → glmmTMB; we have implemented 
various checks to make users aware that they need to reinstall from 
source, and to some extent we've tried to push out synchronous updates 
(i.e., push an update of TMB to CRAN every time Matrix changes, and an 
update of glmmTMB after that), but centralized machinery for this would 
certainly be nice.


  FWIW some of the machinery is here: 
https://github.com/glmmTMB/glmmTMB/blob/d9ee7b043281341429381faa19b5e53cb5a378c3/glmmTMB/R/utils.R#L209-L295 
-- it relies on a Makefile rule that caches the current installed 
version of TMB: 
https://github.com/glmmTMB/glmmTMB/blob/d9ee7b043281341429381faa19b5e53cb5a378c3/glmmTMB/R/utils.R#L209-L295



  cheers
   Ben Bolker


On 2023-08-06 5:05 p.m., Dirk Eddelbuettel wrote:


CRAN, by relying on the powerful package management system that is part of R,
provides an unparalleled framework for extending R with nearly 20k packages.

We recently encountered an issue that highlights a missing element in the
otherwise outstanding package management system. So we would like to start a
discussion about enhancing its feature set. As shown below, a mechanism to
force reinstallation of packages may be needed.

A demo is included below, it is reproducible in a container. We find the
easiest/fastest reproduction is by saving the code snippet below in the
current directory as eg 'matrixIssue.R' and have it run in a container as

docker run --rm -ti -v `pwd`:/mnt rocker/r2u Rscript /mnt/matrixIssue.R
   
This runs in under two minutes, first installing the older Matrix, next

installs SeuratObject, and then by removing the older Matrix making the
(already installed) current Matrix version the default. This simulates a
package update for Matrix. Which, as the final snippet demonstrates, silently
breaks SeuratObject as the cached S4 method Csparse_validate is now missing.
So when SeuratObject was installed under Matrix 1.5.1, it becomes unuseable
under Matrix 1.6.0.

What this shows is that a call to update.packages() will silently corrupt an
existing installation.  We understand that this was known and addressed at
CRAN by rebuilding all binary packages (for macOS and Windows).

But it leaves both users relying on source installation as well as
distributors of source packages in a dire situation. It hurt me three times:
my default R installation was affected with unit tests (involving
SeuratObject) silently failing. It similarly broke our CI setup at work.  And
it created a fairly bad headache for the Debian packaging I am involved with
(and I surmise it affects other distro similarly).

It would be good to have a mechanism where a package, when being upgraded,
could flag that 'more actions are required' by the system (administrator).
We think this example demonstrates that we need such a mechanism to avoid
(silently !!) breaking existing installations, possibly by forcing
reinstallation of other packages.  R knows the package dependency graph and
could trigger this, possibly after an 'opt-in' variable the user / admin
sets.

One possibility may be to add a new (versioned) field 'Breaks:'. Matrix could
then have added 'Breaks: SeuratObject (<= 4.1.3)' preventing an installation
of Matrix 1.6.0 when SeuratObject 4.1.3 (or earlier) is present, but
permitting an update to Matrix 1.6.0 alongside a new version, say, 4.1.4 of
SeuratObject which could itself have a versioned Depends: Matrix (>= 1.6.0).

Regards,  Dirk


## Code example follows. Recommended to run the rocker/r2u container.
## Could also run 'apt update -qq; apt upgrade -y' but not required
## Thanks to my colleague Paul Hoffman for the core of this example

## now have Matrix 1.6.0 because r2u and CRAN remain current but we can install 
an older Matrix
remotes::install_version('Matrix', '1.5.1')

## we can confirm that we have Matrix 1.5.1
packageVersion("Matrix")

## we now install SeuratObject from source and to speed things up we first 
install the binary
install.packages("SeuratObject")   # in this container via bspm/r2u as binary
## and then force a source installation (turning bspm off) _while Matrix is at 
1.5.1_
if (requireNamespace("bspm", quietly=TRUE) bspm::disable()
Sys.setenv(PKG_CXXFLAGS='-Wno-ignored-attributes')  # Eigen compilation 
noise silencer
install.packages('SeuratObject')

## we now remove the Matrix package version 1.5.1 we installed into /usr/local 
leaving 1.6.0
remove.packages("Matrix")
packageVersion("Matrix")

## and we now run a bit of SeuratObject code that is now broken as 
Csparse_validate is gone
suppressMessages(library(SeuratObject))
data('pbmc_small')
graph <- pbmc_small[['RNA_snn']]
class(graph)
getClass('Graph')
show(graph) # this fails




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

[R-pkg-devel] "Version contains leading zeroes" note: clarity

[Ben Bolker]

  Hi folks,

  I got the dreaded

Version contains leading zeroes

NOTE from a package check - the version was 0.0.1.000.

until I dug into the code and found the regex "(^|[.-])0[0-9]+" I didn't 
realize the restriction was on leading zeroes *within a version 
component* - I was interpreting it as leftmost in the whole version 
(i.e., the initial 0).


  I eventually found the documentation in ?package_version (feels like 
it should also be pointed to somewhere in Writing R Extensions?


Numeric versions are sequences of one or more non-negative
 integers, usually (e.g., in package ‘DESCRIPTION’ files)
 represented as character strings with the elements of the sequence
 concatenated and separated by single ‘.’ or ‘-’ characters.  R
 package versions consist of at least two such integers, an R
 system version of exactly three (major, minor and patchlevel).

Doesn't say anything about leading zero(e)s here ...

  "Zeroes" looks weird to me, but I see that "zeroes" is used on 26 
lines in .Rd files in the R code base, while "zeros" is used on 36 lines 
... so close to a tie. (Maybe someone wants to clean this up ... ? 
Maybe a mini-project for the R bug sprint at the end of the summer?


  Also, I'm sure this has been asked a few 100 times but: a new-to-CRAN 
maintainer triggers a NOTE.  Is there any way that a new user would know 
that this was informational only?  (There is also a 
Note_to_CRAN_maintainers 
<https://github.com/r-devel/r-svn/blob/0252cdbf14c73acd26ae2090df3c04aa6118b523/src/library/tools/R/check.R#L6009>: 
wouldn't that be more appropriate here?)


  cheers
   Ben Bolker

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

Re: [R-pkg-devel] Package PowerSDI NOTES

[Ben Bolker]

  See also

https://ropensci.org/blog/2022/01/21/ropensci-news-digest-january-2022/#to-quote-or-not-to-quote-non-existing-words-in-description

https://stat.ethz.ch/R-manual/R-patched/library/utils/html/aspell-utils.html

On 2023-07-18 3:11 p.m., Duncan Murdoch wrote:

On 18/07/2023 12:37 p.m., Gabriel Constantino Blain wrote:

Dears,
I submitted my R package to CRAN.
However, it didn't pass the CRAN checks because of 2 notes:
Note 1:
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: NOTE
   Maintainer: 'Gabriel Constantino Blain '
   New submission
 Possibly misspelled words in DESCRIPTION:
 EP (14:45)
 NASAPOWER (11:18)
 OperatSDI (12:9)
 PowerSDI (7:18, 13:9)
 SPEI (3:31, 7:50, 10:20)
 SPI (3:23, 7:42, 10:12)
 ScientSDI (9:19)
 evapotranspitation (13:44)
 subperiods (15:76)
Note 2:
Flavor: r-devel-windows-x86_64
Check: examples, Result: NOTE
   Examples with CPU (user + system) or elapsed time > 10s
  user system elapsed
   ScientSDI 82.71   0.75   88.00
   Reference 29.75   0.05   29.80
   Accuracy  10.02   1.11   11.12
Flavor: r-devel-linux-x86_64-debian-gcc
Check: examples, Result: NOTE
   Examples with CPU (user + system) or elapsed time > 5s
   user system elapsed
   ScientSDI 52.674  0.176  57.765
   Reference 20.749  0.148  20.898
   Accuracy   6.001  0.024   6.024

Regarding note 1, not all the words are misspelled,
EP, SPI and SPEI are acronyms
OperatSDI and ScientSDI are functions of my package
PowerSDI is the name of my package's name
  NASAPOWER is the project's name.


Writing R Extensions section 1.1.1 describes some rules for quoting 
non-English words.  I think they imply OperatSDI, ScientSDI and PowerSDI 
should be in single quotes.  I am not sure whether that also applies to 
your other non-English words.


Duncan Murdoch



Regarding note 2, I don't know what's wrong. Is it related to the time 
to run the examples (>5s)? If is it so, it is not an error. There are 
so many calculations that it does take some time to do it.


The package is available at https://github.com/gabrielblain/PowerSDI
I really appreciate any help you can provide.
Best regards
Gabriel

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


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

[Rd] question about an R idiom: eval()ing a quoted block

[Ben Bolker]

  In a few places in the R source code, such as the $initialize element 
of `family` objects, and in the body of power.t.test() (possibly other 
power.* functions), sets of instructions that will need to be run later 
are encapsulated by saving them as an expression and later applying 
eval(), rather than as a function. This seems weird to me; the only 
reason I can think of for doing it this way is to avoid having to pass 
back multiple objects and assign them in the calling environment (since 
R doesn't have a particularly nice form of Python's tuple-unpacking idiom).


  Am I missing something?

 cheers
   Ben


https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52

https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171

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

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[Ben Bolker]

  Nice! (I like "A longer description will go here eventually.")

 It would be cute/handy to have navigation links available for "go to 
this help page in the next (previous) version of R" (if it's not a huge 
pain)


On 2023-06-30 11:10 a.m., David Hugh-Jones wrote:

OK, so I took Jeff's hint and did this myself!

https://github.com/hughjonesd/r-help

Sample page for ?plot from the first version of R (at least, the first
version that is on svn):

https://hughjonesd.github.io/r-help/0.60/base/plot.html

Not everything is guaranteed to work, so please report bugs if you find any.

Cheers,
David


On Fri, 30 Jun 2023 at 13:23, David Hugh-Jones 
wrote:



There are plenty of places to find current docs. I think it’s fine to have
versioned ones also. I agree it would be a good idea to clearly signal
“hey, this is an old version” - indeed I’ve been bitten by that in python
before. I’m working on this now… will see what I can do.

Does anyone happen to know if it’s possible to create 00index files
without installing the relevant package? (Loading R 0.60 is challenging…)

D



On Fri, 30 Jun 2023 at 13:02, Duncan Murdoch 
wrote:


On 30/06/2023 7:57 a.m., David Hugh-Jones wrote:

Static web pages get indexed by google.


Isn't that an argument against having static pages?  If I do a Google
search for "R lm" I think it's better to find the current docs rather
than dozens of obsolete versions.  It's rare that someone wants to see
changes across versions, so doing that should take extra work.

Duncan Murdoch



David


On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch mailto:murdoch.dun...@gmail.com>> wrote:

 Why store them?  Download the source on demand, and convert it.

Seems

 pretty simple.

 Duncan Murdoch

 On 30/06/2023 1:19 a.m., David Hugh-Jones wrote:
  > This is for the rcheology package. I run a Shiny web app which
 lets you
  > examine changes to functions across R versions:
  >
  > https://hughjonesd.shinyapps.io/rcheology/
 
  >
  > Manually storing and converting the Rd might be possible, but it
 would be
  > burdensome in terms of data (and my time). And if the Rd spec has
 changed
  > across versions, that’s another problem.
  >
  > More generally, shouldn’t there be publicly available versioned
  > documentation? Python has had this for a long time.
  >
  > David
  >
  >
  > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller
 mailto:jdnew...@dcn.davis.ca.us>>
  > wrote:
  >
  >> Sure. On your computer. Install the old version of R and let it
 serve the
  >> relevant docs.
  >>
  >> Dunno of anyone doing this historical dive online for you
 though. Why
  >> would you want preformatted docs if you didn't have those old
 versions
  >> installed?
  >>
  >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones <
  >> davidhughjo...@gmail.com >

wrote:

  >>> That’s useful to know. But is there anywhere with preformatted
 HTML pages?
  >>>
  >>> Cheers, D
  >>>
  >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov
 mailto:krylov.r...@gmail.com>> wrote:
  >>>
   On Thu, 29 Jun 2023 20:22:47 +0100
   David Hugh-Jones mailto:davidhughjo...@gmail.com>> wrote:
  
  > I'm looking for a source of online help for R base
  > packages, which covers all versions (for some reasonable

value of

  > "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
  
   These live in the R source tree, under src/library:
   https://svn.r-project.org/R/trunk/src/library/
 
  
   For the actual releases of R, you may have to go looking at

the

   branches inside that repository, e.g., the following command:
  
   svn log \
  
  
  >>


https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
<
https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd


  
   ...should tell you the history of ?lm until the latest
 R-4.1-patched.
  
   Do the Git mirrors track these release branches? The branching
 model of
   Subversion [*] is different from the Git model, so perhaps

not.

  
   --
   Best regards,
   Ivan
  
   [*]
 https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
 >
  >> --
  >> Sent from my phone. Please excuse my brevity.
  >>
  >> __
  >> R-package-devel@r-project.org
  mailing list
  >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
 

Re: [Rd] restoring LANGUAGE env variable within an R session

[Ben Bolker]

  Thanks, this is exactly PR#18055. Should have looked (but assumed I 
was probably just overlooking something ...)


On 2023-06-26 10:02 a.m., Sebastian Meyer wrote:

Translated strings are cached.
I'd recommend to use the

     • New partly experimental Sys.setLanguage() utility, solving the
   main problem of PR#18055.

introduced in R 4.2.0.

Best,

 Sebastian Meyer


Am 26.06.23 um 15:15 schrieb Ben Bolker:

    I was playing around with the setting of the LANGUAGE variable and am
wondering whether I'm missing something obvious about resetting the
value to its original state once it's been set.  I seem to be able to
reset the language for warnings/errors once, but not to change it a
second time (or reset it) once it's been set ... ??

## default (no LANGUAGE set, English locale)
  > sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced
## no complaints, doesn't change (as expected)
  > Sys.setenv(LANGUAGE = "en")
  > sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced

## change to German
  > Sys.setenv(LANGUAGE = "de")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## try to change to Spanish - no luck
## (this does work in a clean session)

  > Sys.setenv(LANGUAGE = "es")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## try resetting to blank
  > Sys.setenv(LANGUAGE = "")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## or back to English explicitly?
  > Sys.setenv(LANGUAGE = "en")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt
  >

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [Rd] restoring LANGUAGE env variable within an R session

[Ben Bolker]

  That's reasonable, but I'm wondering why it works the *first* time 
it's called in a session. Is this just undefined behaviour (so I 
shouldn't be surprised whatever happens)?  Again,


$ Rscript -e 'sqrt(-1); Sys.setenv(LANGUAGE="es"); sqrt(-1)'
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced
[1] NaN
Warning message:
In sqrt(-1) : Se han producido NaNs

  I should clarify that this really isn't that important for my 
workflow, it just seemed like an odd loose end.


Weirdly, I just discovered that Sys.setLanguage().  Don't know how it 
differs, but there's a bindtextdomain(NULL) call  there which may be the 
magic sauce ... ???


 sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced
> Sys.setLanguage("de")
> sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt
> Sys.setLanguage("en")
> sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced



On 2023-06-26 9:38 a.m., Dirk Eddelbuettel wrote:


Ben,

POSIX level / glibc level variables are set at process start and AGAIK cannot
really be altered after start.  They clearly work when set _before_ calling 
sqrt(-1):

 $ LANGUAGE=es Rscript -e 'sqrt(-1)'
 [1] NaN
 Warning message:
 In sqrt(-1) : Se han producido NaNs
 $ LANGUAGE=de Rscript -e 'sqrt(-1)'
 [1] NaN
 Warnmeldung:
 In sqrt(-1) : NaNs wurden erzeugt
 $

I think the `callr` package can help you with this use from with R by
effectively spawning a new process for you. Or, lower-level, you can call
`system()` or `system2()` yourself and take care of the setup.

Cheers, Dirk



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

[Rd] restoring LANGUAGE env variable within an R session

[Ben Bolker]

  I was playing around with the setting of the LANGUAGE variable and am 
wondering whether I'm missing something obvious about resetting the 
value to its original state once it's been set.  I seem to be able to 
reset the language for warnings/errors once, but not to change it a 
second time (or reset it) once it's been set ... ??


## default (no LANGUAGE set, English locale)
> sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced
## no complaints, doesn't change (as expected)
> Sys.setenv(LANGUAGE = "en")
> sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced

## change to German
> Sys.setenv(LANGUAGE = "de")
> sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## try to change to Spanish - no luck
## (this does work in a clean session)

> Sys.setenv(LANGUAGE = "es")
> sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## try resetting to blank
> Sys.setenv(LANGUAGE = "")
> sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## or back to English explicitly?
> Sys.setenv(LANGUAGE = "en")
> sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt
>

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

Re: [Rd] why does [A-Z] include 'T' in an Estonian locale?

[Ben Bolker]

  Yes.
  FWIW I submitted a request for a documentation fix to TRE (to 
document that it actually uses Unicode order, not collation order, to 
define ranges, just like most (but not all) other regex engines ...)


https://github.com/laurikari/tre/issues/88

On 2023-06-16 5:16 a.m., peter dalgaard wrote:

Just for amusement: Similar messups occur with Danish and its three extra 
letters:


Sys.setlocale("LC_ALL", "da_DK")

[1] "da_DK/da_DK/da_DK/C/da_DK/en_US.UTF-8"

sort(c(LETTERS,"Æ","Ø","Å"))

  [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" 
"S"
[20] "T" "U" "V" "W" "X" "Y" "Z" "Æ" "Ø" "Å"


grepl("[A-Å]", "Ø")

[1] FALSE

grepl("[A-Å]", "Æ")

[1] FALSE

grepl("[A-Æ]", "Å")

[1] TRUE

grepl("[A-Æ]", "Ø")

[1] FALSE

grepl("[A-Ø]", "Å")

[1] TRUE

grepl("[A-Ø]", "Æ")

[1] TRUE

So for character ranges, the order is Å,Æ,Ø (which is how they'd collate in 
Swedish, except that Swedish uses diacriticals rather than Æ and Ø).


Sys.setlocale("LC_ALL", "sv_SE")

[1] "sv_SE/sv_SE/sv_SE/C/sv_SE/en_US.UTF-8"

sort(c(LETTERS,"Æ","Ø","Å"))

  [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" 
"S"
[20] "T" "U" "V" "W" "X" "Y" "Z" "Å" "Æ" "Ø"

sort(c(LETTERS,"Ä","Ö","Å"))

  [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" 
"S"
[20] "T" "U" "V" "W" "X" "Y" "Z" "Å" "Ä" "Ö"




On 30 May 2023, at 17:45 , Ben Bolker  wrote:

  Inspired by this old Stack Overflow question

https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions

I was wondering why this is TRUE:

Sys.setlocale("LC_ALL", "et_EE")
grepl("[A-Z]", "T")

TRE's documentation at <https://laurikari.net/tre/documentation/regex-syntax/> says that 
a range "is shorthand for the full range of characters between those two [endpoints] 
(inclusive) in the collating sequence".

Yet, T is *not* between A and Z in the Estonian collating sequence:

sort(LETTERS)
[1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S"
[20] "Z" "T" "U" "V" "W" "X" "Y"

  I realize that this may be a question about TRE rather than about R *per se* (FWIW the 
grepl() result is also TRUE with `perl = TRUE`, so the question also applies to PCRE), 
but I'm wondering if anyone has any insights ...  (and yes, I know that the correct 
answer is "use [:alpha:] and don't worry about it")

(In contrast, the ICU engine underlying stringi/stringr says "[t]he characters to 
include are determined by Unicode code point ordering" - see

https://stackoverflow.com/questions/76365426/does-stringrs-regex-engine-translate-a-z-into-abcdefghijklmnopqrstuvwyz/76366163#76366163

for links)

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




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [Rd] infelicity in `na.print = ""` for numeric columns of data frames/formatting numeric values

[Ben Bolker]

On 2023-06-05 9:27 a.m., Martin Maechler wrote:

Ben Bolker
 on Sat, 3 Jun 2023 13:06:41 -0400 writes:


 > format(c(1:2, NA)) gives the last value as "NA" rather than
 > preserving it as NA, even if na.encode = FALSE (which does the
 > 'expected' thing for character vectors, but not numeric vectors).

 > This was already brought up in 2008 in
 > https://bugs.r-project.org/show_bug.cgi?id=12318 where Gregor Gorjanc
 > pointed out the issue. Documentation was added and the bug closed as
 > invalid. GG ended with:

 >> IMHO it would be better that na.encode argument would also have an
 > effect for numeric like vectors. Nearly any function in R returns NA
 > values and I expected the same for format, at least when na.encode=FALSE.

 > I agree!

I do too, at least "in principle", keeping in mind that
backward compatibility is also an important principle ...

Not sure if the 'na.encode' argument should matter or possibly a
new optional argument, but "in principle" I think that

   format(c(1:2, NA, 4))

should preserve is.na(.) even by default.


   I would say it should preserve `is.na` *only* if na.encode = FALSE - 
that seems like the minimal appropriate change away from the current 
behaviour.




 > I encountered this in the context of printing a data frame with
 > na.print = "", which works as expected when printing the individual
 > columns but not when printing the whole data frame (because
 > print.data.frame calls format.data.frame, which calls format.default
 > ...).  Example below.

 > It's also different from what you would get if you converted to
 > character before formatting and printing:

 > print(format(as.character(c(1:2, NA)), na.encode=FALSE), na.print ="")

 > Everything about this is documented (if you look carefully enough),
 > but IMO it violates the principle of least surprise
 > https://en.wikipedia.org/wiki/Principle_of_least_astonishment , so I
 > would call it at least an 'infelicity' (sensu Bill Venables)

 > Is there any chance that this design decision could be revisited?

We'd have to hear other opinions / gut feelings.

Also, someone (not me) would ideally volunteer to run
'R CMD check ' for a few 1000 (not necessarily all) CRAN &
BioC packages with an accordingly patched version of R-devel
(I might volunteer to create such a branch, e.g., a bit before the R
  Sprint 2023 end of August).


  I might be willing to do that, although it would be nice if there 
were a pre-existing framework (analogous to r-lib/revdepcheck) for 
automating it and collecting the results ...






 > cheers
 > Ben Bolker


 > ---

The following issue you are raising
may really be a *different* one, as it involves format() and
print() methods for "data.frame", i.e.,

format.data.frame() vs
 print.data.frame()

which is quite a bit related, of course, to how 'numeric'
columns are formatted -- as you note yourself below;
I vaguely recall that the data.frame method could be an even
"harder problem" .. but I don't remember the details.

It may also be that there are no changes necessary to the
*.data.frame() methods, and only the documentation (you mention)
should be updated ...



  I *think* that if format.default() were changed so that 
na.encode=FALSE also applied to numeric types, then data frame printing 
would naturally work 'right' (since print.data.frame calls 
format.data.frame which calls format() for the individual columns 
specifying encode=FALSE ...)


Martin

 > Consider

 > dd <- data.frame(f = factor(1:2), c = as.character(1:2), n =
 > as.numeric(1:2), i = 1:2)
 > dd[3,] <- rep(NA, 4)
 > print(dd, na.print = "")


 > print(dd, na.print = "")
 >   f c  n  i
 > 1 1 1  1  1
 > 2 2 2  2  2
 > 3 NA NA

 > This is in fact as documented (see below), but seems suboptimal given
 > that printing the columns separately with na.print = "" would
 > successfully print the NA entries as blank even in the numeric columns:

 > invisible(lapply(dd, print, na.print = ""))
 > [1] 1 2
 > Levels: 1 2
 > [1] "1" "2"
 > [1] 1 2
 > [1] 1 2

 > * ?print.data.frame documents that it calls format() for each column
 > before printing
 > * the code of print.data.frame() shows that it calls format.data.frame()
 > with na.encode = FALSE
 > * ?format.data.frame specifically notes that na.encode "only applies to
 > elements of character vectors, not to numerical, complex nor logical
 > ‘NA’s, which are always encoded as ‘"NA"’.

 > So th

[Rd] infelicity in `na.print = ""` for numeric columns of data frames/formatting numeric values

[Ben Bolker]

  format(c(1:2, NA)) gives the last value as "NA" rather than 
preserving it as NA, even if na.encode = FALSE (which does the 
'expected' thing for character vectors, but not numeric vectors).


  This was already brought up in 2008 in 
https://bugs.r-project.org/show_bug.cgi?id=12318 where Gregor Gorjanc 
pointed out the issue. Documentation was added and the bug closed as 
invalid. GG ended with:


> IMHO it would be better that na.encode argument would also have an
effect for numeric like vectors. Nearly any function in R returns NA 
values and I expected the same for format, at least when na.encode=FALSE.


  I agree!

  I encountered this in the context of printing a data frame with 
na.print = "", which works as expected when printing the individual 
columns but not when printing the whole data frame (because 
print.data.frame calls format.data.frame, which calls format.default 
...).  Example below.


  It's also different from what you would get if you converted to 
character before formatting and printing:


print(format(as.character(c(1:2, NA)), na.encode=FALSE), na.print ="")

  Everything about this is documented (if you look carefully enough), 
but IMO it violates the principle of least surprise 
https://en.wikipedia.org/wiki/Principle_of_least_astonishment , so I 
would call it at least an 'infelicity' (sensu Bill Venables)


  Is there any chance that this design decision could be revisited?

  cheers
   Ben Bolker


---

  Consider

dd <- data.frame(f = factor(1:2), c = as.character(1:2), n = 
as.numeric(1:2), i = 1:2)

dd[3,] <- rep(NA, 4)
print(dd, na.print = "")


print(dd, na.print = "")
  f c  n  i
1 1 1  1  1
2 2 2  2  2
3 NA NA

This is in fact as documented (see below), but seems suboptimal given 
that printing the columns separately with na.print = "" would 
successfully print the NA entries as blank even in the numeric columns:


invisible(lapply(dd, print, na.print = ""))
[1] 1 2
Levels: 1 2
[1] "1" "2"
[1] 1 2
[1] 1 2

* ?print.data.frame documents that it calls format() for each column 
before printing
* the code of print.data.frame() shows that it calls format.data.frame() 
with na.encode = FALSE
* ?format.data.frame specifically notes that na.encode "only applies to 
elements of character vectors, not to numerical, complex nor logical 
‘NA’s, which are always encoded as ‘"NA"’.


   So the NA values in the numeric columns become "NA" rather than 
remaining as NA values, and are thus printed rather than being affected 
by the na.print argument.


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

Re: [Rd] why does [A-Z] include 'T' in an Estonian locale?

[Ben Bolker]

  Thanks, I do know about the docs you quoted.  Thanks for pointing me 
to the comment in the code.


 I've posted an issue (a request to make the documentation match the 
code) at the TRE repository:


https://github.com/laurikari/tre/issues/88


On 2023-06-01 5:53 a.m., Tomas Kalibera wrote:


On 5/30/23 17:45, Ben Bolker wrote:

Inspired by this old Stack Overflow question

https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions

I was wondering why this is TRUE:

Sys.setlocale("LC_ALL", "et_EE")
grepl("[A-Z]", "T")

TRE's documentation at 
<https://laurikari.net/tre/documentation/regex-syntax/> says that a 
range "is shorthand for the full range of characters between those two 
[endpoints] (inclusive) in the collating sequence".


Yet, T is *not* between A and Z in the Estonian collating sequence:

 sort(LETTERS)
 [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" 
"Q" "R" "S"

[20] "Z" "T" "U" "V" "W" "X" "Y"

  I realize that this may be a question about TRE rather than about R 
*per se* (FWIW the grepl() result is also TRUE with `perl = TRUE`, so 
the question also applies to PCRE), but I'm wondering if anyone has 
any insights ...  (and yes, I know that the correct answer is "use 
[:alpha:] and don't worry about it")


The correct answer depends on what you want to do, but please see 
?regexp in R:


"Because their interpretation is locale- and implementation-dependent, 
character ranges are best avoided."


and

"The only portable way to specify all ASCII letters is to list them all 
as the character class

‘[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz]’."

This is from POSIX specification:

"In the POSIX locale, a range expression represents the set of collating 
elements that fall between two elements in the collation sequence, 
inclusive. In other locales, a range expression has unspecified 
behavior: strictly conforming applications shall not rely on whether the 
range expression is valid, or on the set of collating elements matched. 
A range expression shall be expressed as the starting point and the 
ending point separated by a  ( '-' )."


If you really want to know why the current implementation of R, TRE and 
PCRE2 works in a certain way, you can check the code, but I don't think 
it would be a good use of the time given what is written above.


It may be that TRE has a bug, maybe it doesn't do what was intended (see 
comment "XXX - Should use collation order instead of encoding values in 
character ranges." in the code), but I didn't check the code thoroughly.


Best
Tomas



(In contrast, the ICU engine underlying stringi/stringr says "[t]he 
characters to include are determined by Unicode code point ordering" - 
see


https://stackoverflow.com/questions/76365426/does-stringrs-regex-engine-translate-a-z-into-abcdefghijklmnopqrstuvwyz/76366163#76366163

for links)

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


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

[Rd] why does [A-Z] include 'T' in an Estonian locale?

[Ben Bolker]

  Inspired by this old Stack Overflow question

https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions

I was wondering why this is TRUE:

Sys.setlocale("LC_ALL", "et_EE")
grepl("[A-Z]", "T")

TRE's documentation at 
 says that a 
range "is shorthand for the full range of characters between those two 
[endpoints] (inclusive) in the collating sequence".


Yet, T is *not* between A and Z in the Estonian collating sequence:

 sort(LETTERS)
 [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" 
"Q" "R" "S"

[20] "Z" "T" "U" "V" "W" "X" "Y"

  I realize that this may be a question about TRE rather than about R 
*per se* (FWIW the grepl() result is also TRUE with `perl = TRUE`, so 
the question also applies to PCRE), but I'm wondering if anyone has any 
insights ...  (and yes, I know that the correct answer is "use [:alpha:] 
and don't worry about it")


(In contrast, the ICU engine underlying stringi/stringr says "[t]he 
characters to include are determined by Unicode code point ordering" - see


https://stackoverflow.com/questions/76365426/does-stringrs-regex-engine-translate-a-z-into-abcdefghijklmnopqrstuvwyz/76366163#76366163

for links)

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

Re: [R-pkg-devel] masked from 'package:utils':,, ?

[Ben Bolker]

   This is harmless and should be accepted by CRAN (if masking existing 
functions were illegal half of the tidyverse would be banned ...).  It's 
there because it needs to be defined in order to enable the ??? alias 
for findFn().  sos:::"?" (and experimentation) show that use of a single 
? is passed through to the original 'utils' version.



On 2023-05-23 4:59 p.m., Spencer Graves wrote:




Hello, All:


  CRAN checks for sos on 8 of the 13 platforms complain about the 
following:



The following object is masked from 'package:utils':

    ?


  This is code that Duncan Murdoch contributed to this package 
around 2009.  I have no idea how to fix this.  It's only a NOTE, so 
CRAN would probably accept it.  However, I felt a need to ask about 
this before I submitted the package to CRAN without asking this group 
for suggestions.



  What do you think?
  Thanks,
  Spencer Graves

__
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] Acknowledging small functions from another package

[Ben Bolker]

  In fact Martin Maechler added this in 2021:

https://github.com/wch/r-source/blob/trunk/src/library/utils/R/str.R#L19-L21

## A pearl from ggplot2 et al.  NB: often needs '(.)' :%||% ( 
 )

## *not exported* [should rather be in 'base' than exported here]
`%||%` <- function(L,R) if(is.null(L)) R else L


On 2023-05-04 5:59 a.m., David Hugh-Jones wrote:

Thank you both. This sounds sensible. Yeah, add my vote for `base::%||%`!!


David


On Thu, 4 May 2023 at 10:00, Duncan Murdoch 
wrote:


On 04/05/2023 4:53 a.m., Ivan Krylov wrote:

On Thu, 4 May 2023 09:21:17 +0100
David Hugh-Jones  wrote:


One of my packages copy-pasted some small functions (stuff like
`%||%` for is.null) from ggplot2. (Both packages are MIT-licensed.)

What is an appropriate way to acknowledge this in the DESCRIPTION
Author: or Authors@R section?


One way would be to mention Hadley Wickham:


https://github.com/tidyverse/ggplot2/commit/ef2f944863a0db8841bf628e9eb4a9faef5049e6#diff-8f53135445ab98749043fa52e438346bb9acae8e0185aa95f186d0aa021bb7e0

(`git blame` will also tell you that he later moved this function to a
different file).

I think that person('ggplot2 authors', role = 'cph', comment = 'The
%||% operator') is also fine, just like e.g. unitizer package mentions
the code taken from R itself.

You can also find this operator in multiple base R packages, currently
unexported (maybe some day...). They mention in the comments that the
operator is adapted from ggplot2.


I'd probably use role = "ctb" instead for "ggplot2 authors", and include
Posit PBC as a copyright holder (as ggplot2 does).  Presumably you or
others are also copyright holders for your package and should also have
role = "cph" added so it doesn't give the impression that Posit owns
everything.

Duncan Murdoch




[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

[R-pkg-devel] new/slightly mysterious CRAN warnings

[Ben Bolker]

  Submission of most recent version of lme4 threw a NOTE on CRAN's 
Debian platform that we had not seen when running "R CMD check 
--as-cran" with the most recent SVN checkout, nor when submitted to 
win-builder/R-devel.  These are legitimate issues (all now fixed), but 
we were taken by surprise because they weren't detected on any platforms 
we tested on.


  So far, archaeology in the R code base/Github mirror about recent 
changes to tools::checkS3methods, or about environment variables, hasn't 
been entirely successful, although based on


grep Sys.getenv src/library/tools/R/QC.R  | sed -e 's/.*Sys.getenv("//' 
| sed -e 's/"[,)].*//' | sort | uniq


it looks like we *might* want to set

_R_CHECK_S3_METHODS_SHOW_POSSIBLE_ISSUES_

when testing ...

  This is mostly a heads-up/documentation for anyone who might be 
interested.



Debian: 



 R Under development (unstable) (2023-04-20 r84291)

 NOTE
Mismatches for apparent methods not registered:
print:
  function(x, ...)
print.bootWarnings:
  function(x, verbose)

format:
  function(x, ...)
format.perc:
  function(probs, digits)

Apparent methods for exported generics not registered:
  ngrps.default
See section ‘Registering S3 methods’ in the ‘Writing R Extensions’
manual.

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

Re: [R-pkg-devel] Replacing dplyr by stats functions

[Ben Bolker]

    If you use Depends: in your package I think this is unavoidable 
(but, I don't think these should be counted against you as warnings by 
CRAN - they're "Warnings" not "WARNINGs" :-) )


   The only way I know of to avoid this would be to Import: rather than 
Depend:, and import only the functions you need.



On 2023-04-19 4:36 a.m., A. Kucharski wrote:

Hi,

I am developing my own package. I have a problem with its new version. Checking 
on the CRAN server gives 2 warnings like this (critpath is my package):
Warning: replacing previous import 'dplyr::lag' by 'stats::lag' when loading 
'critpath'
Warning: replacing previous import 'dplyr::filter' by 'stats::filter' when 
loading 'critpath'

On my machine these warnings show up during Check but before Build starts so at 
the end I get a message that the number of warnings is 0. I don't use lag or 
filter at all in my package although I use both of these packages. Reordering 
the dplyr and stats package names in the Depends of the Description file didn't 
help. Is it a problem with my code or a conflict between those two packages? 
Please help me remove these warnings.

Best regards

Adam

Wysłane z aplikacji Poczta dla systemu Windows


[[alternative HTML version deleted]]

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


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

Re: [Rd] Query: Could documentation include modernized references?

[Ben Bolker]

  For one point of evidence about how much people pay attention to the 
documentation about what's outdated: Brian Ripley added a comment to 
nlminb.Rd in 2013 saying that the function was "for historical 
compatibility" 
 
but it's still widely used in new code ...


 But I agree that adding appropriate warnings/links to the 
documentation couldn't hurt.


  cheers
   Ben

On 2023-03-26 12:41 p.m., Duncan Murdoch wrote:

On 26/03/2023 11:54 a.m., J C Nash wrote:
A tangential email discussion with Simon U. has highlighted a 
long-standing

matter that some tools in the base R distribution are outdated, but that
so many examples and other tools may use them that they cannot be 
deprecated.


The examples that I am most familiar with concern optimization and 
nonlinear
least squares, but other workers will surely be able to suggest cases 
elsewhere.
I was the source (in Pascal) of Nelder-Mead, BFGS and CG algorithms in 
optim().
BFGS is still mostly competitive, and Nelder-Mead is useful for 
initial exploration
of an optimization problem, but CG was never very good, right from the 
mid-1970s

well before it was interfaced to R. By contrast Rcgmin works rather well
considering how similar it is in nature to CG. Yet I continue to see 
use and

even recommendations of these tools in inappropriate circumstances.

Given that it would break too many other packages and examples to drop 
the
existing tools, should we at least add short notes in the man (.Rd) 
pages?

I'm thinking of something like

 optim() has methods that are dated. Users are urged to consider 
suggestions

 from ...

and point to references and/or an appropriate Task View, which could, 
of course,

be in the references.

I have no idea what steps are needed to make such edits to the man 
pages. Would
R-core need to be directly involved, or could one or two trusted R 
developers
be given privileges to seek advice on and implement such modest 
documentation
additions?  FWIW, I'm willing to participate in such an effort, which 
I believe

would help users to use appropriate and up-to-date tools.


I can answer your final paragraph:

Currently R-core would need to be directly involved, in that they are 
the only ones with write permission on the R sources.


However, they don't need to do the work, they just need to approve of it 
and commit it.  So I would suggest one way forward is the following:


- You fork one of the mirrors of the R sources from Github, and (perhaps 
with help from others) edit one or two of the pages in the way you're 
describing.  Once you think they are ready, make them available online 
for others to review (Github or Gitlab would help doing this), and then 
submit the changes as a patch against the svn sources on the R Bugzilla 
site.


- Another way could be that you copy the help page sources to a dummy 
package, instead of checking out the whole of the R sources.  You'll 
need to be careful not to miss other changes to the originals between 
the time you make your copy and the time you submit the patches.


Don't do too many pages, because you're probably going to have to work 
out the details of the workflow as you go, and earn R Core's trust by 
submitting good changes and responding to their requests.  And maybe 
don't do any until you hear from a member of R Core that they're willing 
to participate in this, because they certainly don't accept all 
suggestions.


Duncan Murdoch

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [Rd] use Ctrl-W to close View() window?

[Ben Bolker]

  It does work, although it's very awkward with my current keyboard 
setup (I need to use Alt-Fn-F4).  However, knowing that there was *a* 
keyboard shortcut for it led me to figuring out how to add Ctrl-W as a 
synonym.  Thanks!  ("Super"-Q is also a synonym, where "Super" is the 
same as the Windows/MacOS command/system key ...)


On 2023-03-17 6:25 p.m., Johannes Ranke wrote:


Hi,

am I missing something or could you just use Alt-F4? This is pretty standard
for closing focussed windows on Windows and Linux at least. It just closed a
Window opened with View() on Debian Linux FWIW.

Cheers, Johannes

Am Freitag, 17. März 2023, 23:16:49 CET schrieb Ben Bolker:

I might be the last person in the world who's using View() outside of
RStudio, but does anyone have a sense of how hard it would be to enable
closing such a window (when in focus) with a standard keyboard shortcut
(e.g. Ctrl-W on Linux) ... ?  Where would I start looking in the code base?

Or maybe this can already be enabled somehow?

    cheers

 Ben Bolker

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




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

[Rd] use Ctrl-W to close View() window?

[Ben Bolker]

  I might be the last person in the world who's using View() outside of 
RStudio, but does anyone have a sense of how hard it would be to enable 
closing such a window (when in focus) with a standard keyboard shortcut 
(e.g. Ctrl-W on Linux) ... ?  Where would I start looking in the code base?


  Or maybe this can already be enabled somehow?

  cheers

   Ben Bolker

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

Re: [R-pkg-devel] Checking timings of packages

[Ben Bolker]

  I would try running them on https://win-builder.r-project.org/ . If 
the Windows timings are OK on that platform I think you can make a good 
case to CRAN that you've done your best ...


On 2023-03-14 9:52 a.m., Chris Brien wrote:

Dear list members.

I have run into a problem with examples from my package growthPheno 
(https://github.com/briencj/growthPheno) that take more than 10 s to execute on 
two flavours under r-devel. The following is the details.log:

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
   Maintainer: 'Chris Brien mailto:chris.br...@adelaide.edu.au'

Flavor: r-devel-windows-x86_64
Check: examples, Result: NOTE
   Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
   probeSmooths 13.56 0.15 13.73
   traitSmooth 13.03 0.10 13.13

When I run the examples on laptop and a desktop running Windows 10 under 
r-devel with all packages updated, the elapsed times were 4.26 and 4.45, 
respectively i.e. much less than on the CRAN platforms. These timings were 
achieved using the following function call from RStudio (2022.12.0 Build 353):


devtools::check("growthPheno", manual=FALSE, check_dir="D:/Analyses/R",

+ args="--as-cran", env_vars = c(NOT_CRAN = "false"))

I have also submitted the package to rhub using the following command:

  rhub::check_for_cran(path = "growthPheno_2.1.18.tar.gz",
env_vars = c(`_R_CHECK_FORCE_SUGGESTS_` = "false",
`_R_CHECK_CRAN_INCOMING_USE_ASPELL_` = "false"),
email = "chris.br...@adelaide.edu.au") with the following 
results for timing:

The timing results were:

Examples with CPU (user + system) or elapsed time > 5s
   user system elapsed
 probeSmooths   6.50 0.09   6.64
traitSmooth 6.02 0.03  6.04

While these are higher than the timings on my machines, they are half those 
reported on in the details.log resulting from my CRAN submission.

In order to be able to pass the CRAN tests, I have reduced the examples so that 
the timings on my laptop are (sessionInfo is below):

   user system elapsed
probeSmooths2.320.062.45
traitSmooth 3.470.093.73

and, using rhub::check_for_CRAN, the timings > 5 s are:

 user system elapsed
probeSmooths 5.16  0.07 6.42

The difficulty I am having is that I cannot be sure that the timings for 
r-devel-linux-x86_64-debian-gcc and r-devel-windows-x86_64 will be under 10 s, 
as seems to be required, if I were to resubmit the package to CRAN with the 
reduced examples.

I would be grateful to anyone who can suggest how I might go about determining 
the CRAN timings without submitting the package to CRAN.

Cheers,

  Chris

Chris Brien
Adjunct Associate Professor in Statistics, UniSA STEM| web page
Senior Biostatistician, Australian Plant Phenomics Facility | researcher profile

---

sessionInfo()

R Under development (unstable) (2023-03-13 r83977 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default


locale:
[1] LC_COLLATE=English_Australia.utf8  LC_CTYPE=English_Australia.utf8
[3] LC_MONETARY=English_Australia.utf8 LC_NUMERIC=C
[5] LC_TIME=English_Australia.utf8

time zone: Australia/Adelaide
tzcode source: internal

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

loaded via a namespace (and not attached):
  [1] tidyselect_1.2.0   viridisLite_0.4.1  dplyr_1.1.0viridis_0.6.2
  fields_14.1
  [6] fastmap_1.1.1  xopen_1.0.0promises_1.2.0.1   digest_0.6.31
  rpart_4.1.19
[11] dotCall64_1.0-2mime_0.12  lifecycle_1.0.3cluster_2.1.4 
 ellipsis_0.3.2
[16] processx_3.8.0 magrittr_2.0.3 compiler_4.3.0 rlang_1.0.6   
 Hmisc_5.0-1
[21] tools_4.3.0utf8_1.2.3 yaml_2.3.7 data.table_1.14.8 
 knitr_1.42
[26] prettyunits_1.1.1  htmlwidgets_1.6.1  curl_5.0.0 pkgbuild_1.4.0
 dae_3.2.15
[31] plyr_1.8.8 RColorBrewer_1.1-3 JOPS_0.1.15pkgload_1.3.2 
 miniUI_0.1.1.1
[36] foreign_0.8-84 withr_2.5.0purrr_1.0.1desc_1.4.2
 nnet_7.3-18
[41] grid_4.3.0 fansi_1.0.4urlchecker_1.0.1   profvis_0.3.7 
 xtable_1.8-4
[46] colorspace_2.1-0   ggplot2_3.4.1  scales_1.2.1   MASS_7.3-58.3 
 cli_3.6.0
[51] rmarkdown_2.20 crayon_1.5.2   generics_0.1.3 remotes_2.4.2 
 rstudioapi_0.14
[56] sessioninfo_1.2.2  cachem_1.0.7   SemiPar_1.0-4.2stringr_1.5.0 
 maps_3.4.1
[61] base64enc_0.1-3vctrs_0.5.2devtools_2.4.5 callr_3.7.3   
 rcmdcheck_1.4.0
[66] Formula_1.2-5  htmlTable_2.4.1testthat_3.1.7 SpATS_1.0-18  
 glue_1.6.2
[71] spam_2.9-1 ps_1.7.2 

[R-pkg-devel] URL timeout in win-builder check: suggestions?

[Ben Bolker]

  I have a URL in my documentation that got a timeout error from 
win-builder, possibly because of some kind of service provider filtering 
of bots (I think there was a previous issue with Cloudflare links?)


  I can get to it fine interactively/in a browser.

  This link is a harmless bit of fluff (click through if you want to 
see), but I don't want it causing hiccups in my CRAN submission (i.e., I 
could take it out if necessary but would prefer not to ...)


Suggestions?

===
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Ben Bolker '

Found the following (possibly) invalid URLs:
  URL: https://phdcomics.com/comics/archive.php?comicid=905
From: man/pvalues.Rd
Status: Error
Message: Operation timed out after 60010 milliseconds with 0 bytes 
received


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

[R-pkg-devel] FAIL output in CRAN checks?

[Ben Bolker]

  I don't know that I've ever seen this one before: a result of FAIL 
for a CRAN check.


  There's a WARNING which I already know about, but this build seems to 
get hung up on "checking re-building of vignette outputs ..." (which 
takes about 70/95 seconds on most other platforms)


https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/lme4-00check.html 



  Does anyone have ideas about this? Is this something I should worry 
about/try to diagnose and fix?  (r-hub does appear to have a 
fedora/clang platform)


  For what it's worth:

> rhub::platforms()
Error in curl::curl_fetch_memory(url, handle = handle) :
  Peer certificate cannot be authenticated with given CA certificates: 
[builder.r-hub.io] SSL certificate problem: certificate has expired


  I guess I could report that ...


  cheers

   Ben Bolker

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

Re: [Rd] transform.data.frame() ignores unnamed arguments when no named argument is provided

[Ben Bolker]

   For what it's worth I think the increased emphasis on classed
errors should help with this (i.e., it will be easier to filter out
errors you know are false positives/irrelevant for your use case).

On Fri, Mar 3, 2023 at 12:17 PM Antoine Fabri  wrote:
>
> Let me expand a bit, I might have expressed myself poorly.
>
>  If there is a good reason for a warning I want a warning, and because I
> take them seriously I don't want my console cluttered with those that can
> be avoided. I strongly believe we should strive to make our code silent,
> and I like my console to tell me only what I need to know. In my opinion
> many warnings would be better designed as errors, sometimes with an
> argument to opt in the behaviour, or a documented way to work around. Some
> other warnings should just be documented behavior, because the behavior is
> not all that surprising.
>
> Some reasons why I find warnings hard to debug:
> - options(warn = 1) is not always enough to spot the source of the warning
> - options(warn = 2) fails at every warning, including the ones that are not
> interesting to the user and that they may not do anything about, in these
> cases you'll have to find a way to shut off the first to get to the second,
> and if it's packaged code that's not fun.
> - Unlike with errors, traceback() won't help.
> - tryCatch() will help you only if you call it at the right place, assuming
> you've found it.
> - We might also have many harmless warnings triggered through loops and
> hiding important ones.
> - When you are sure that you are OK with your code despite the warning, say
> `as.numeric(c("1", "2", "foo"))`, a workaround might be expensive (here we
> could use regex first to ditch the non numeric strings but who does that)
> so you're tempted to use `suppressWarnings()`, but then you might be
> suppressing other important warnings so you just made your code less safe
> because the developper wanted to make it safer (you might say it's on the
> user but still, we get suboptimal code that was avoidable).
>
> Of course I might miss some approaches that would make my experience of
> debugging warnings more pleasant.
>
> In our precise case I don't find the behavior surprising enough to warrant
> more precious red ink since it's close to what we get with data.frame(),
> and close to what we get with dplyr::mutate() FWIW, so I'd be personally
> happier to have this documented and work silently.
>
> Either way I appreciate you considering the problem.
>
> Thanks,
>
> Antoine
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

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

[Ben Bolker]

  Not important (of course) but where does the 5000 kWh per tree number 
come from?  Is that (dry weight) x (50% carbon per dry weight) / (carbon 
content of CO2 emissions per kWh) ?


https://www.epa.gov/energy/greenhouse-gas-equivalencies-calculator#results

  If we say 200 watts x 15 minutes (allowing us to take up the whole 
server for checking on 5 different platforms) we have .05 kWh. Let's say 
we do this 300 times/year for a package, so 15 kWh. Hard to get 'tree 
equivalents' from the EPA web site, but this is equivalent to 1.2 
gallons of petrol/gasoline consumption (0.011 metric tonnes)



On 2023-02-23 12:59 p.m., Duncan Murdoch wrote:

Hi Martin.

I think your calculations are way off.  A one-tonne tree contains about 
5000 kWh of energy.  A typical computer server uses about 200 watts, and 
can process many jobs simultaneously on different cores, but let's say 
the whole server is dedicated to the Github action.  Then it would 
consume 1 kWh in 5 hours, and would take about 10 days to consume 1% of 
a tree.


Duncan Murdoch

On 23/02/2023 11:29 a.m., Martin Maechler wrote:

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 

[Rd] uniroot violates bounds?

[Ben Bolker]

c1 <- 4469.822
c2 <- 572.3413
f <- function(x) { c1/x - c2/(1-x) }; uniroot(f, c(1e-6, 1))
uniroot(f, c(1e-6, 1))


   provides a root at -6.00e-05, which is outside of the specified 
bounds.  The default value of the "extendInt" argument to uniroot() is 
"no", as far as I can see ...


$root
[1] -6.003516e-05

$f.root
[1] -74453981

$iter
[1] 1

$init.it
[1] NA

$estim.prec
[1] 6.103516e-05


  I suspect this fails because f(1) (value at the upper bound) is 
infinite, although setting interval to c(0.01, 1) does work/give a 
sensible answer ...  (works for a lower bound of 1e-4, fails for 1e-5 ...)


  Setting the upper bound < 1 appears to avoid the problem.

 For what it's worth, the result has an "init.it" component, but the 
only thing the documentation says about it is " component ‘init.it’ was 
added in R 3.1.0".


  And, I think (?) that the 'trace' argument only produces any output 
if the 'extendInt' option is enabled?


  Inspired by 
https://stackoverflow.com/questions/75494696/solving-a-system-of-non-linear-equations-with-only-one-unknown/75494955#75494955


  cheers
   Ben Bolker

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

Re: [R-pkg-devel] CRAN Packages over 5 MB & Time Length for Manual Inspection

[Ben Bolker]

  Out of curiosity, what was the recently added package?

  It looks like the previous version of your package from about a year 
ago is only a 1.2MB tarball.  Also out of curiosity, what caused the 
increase?


  cheers
   Ben Bolker

On 2023-01-29 1:53 p.m., EcoC2S - Irucka Embry wrote:

Greetings!

I submitted my USA.state.boundaries package on 6 January 2023 and Uwe 
responded back letting me know that it was over the 5 MB CRAN threshold. 
I responded back to Uwe letting him know that as of that date there were 
52 CRAN packages over 5 MB. As of today (29 January 2023), there are 
actually 53 CRAN packages over 5 MB.


As I heard no response back from Uwe, I re-submitted my 
USA.state.boundaries package on 12 January and 21 January. As of today, 
I have not heard any response back from Uwe or any other CRAN team 
volunteer.


There are 2 questions:

1) How long should it take to receive a response back from a CRAN team 
volunteer after a manual inspection of a CRAN package?


2) Why has my package been denied acceptance to CRAN while a new package 
over 5 MB has been allowed to be hosted on CRAN recently?


Thank you in advance.

Irucka Embry




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Pretest failed and I fail to find out what's the problem

[Ben Bolker]

  Seems pretty mysterious to me! (No cryptic NOTEs anywhere in the 
logs, other than the inevitable "Note_to_CRAN_maintainers")


  I will be curious to see if anyone else finds something, but my guess 
is a hiccup on the CRAN end (i.e., you'll end up sending e-mail to the 
CRAN maintainers to clarify what's going on)



On 2023-01-22 1:51 p.m., Klaus Schliep wrote:

  Dear all,

I try to submit a new version of the package phangorn and got the mail back:

"Dear maintainer,

package phangorn_2.11.0.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/phangorn_2.11.0_20230122_175755/Windows/00check.log



Status: OK
Debian: <
https://win-builder.r-project.org/incoming_pretest/phangorn_2.11.0_20230122_175755/Debian/00check.log



Status: OK"

I am kind of puzzled as to what the problem is, but it might well be that I
missed something? I appreciate any suggestions.

Kind regards,
Klaus Schliep




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Ben Bolker]

On 2023-01-08 1:38 p.m., Spencer Graves wrote:



On 1/8/23 11:36 AM, Kevin Coombes wrote:
I have been using R-Forge for many years for package development. And 
I have been using GitLab for other projects almost as long.


However, over the past few months, the R-Forge support seems to be 
decaying, and I now have several projects that won't currently build 
there because of various items that appear to need fixing at their 
end. So, I am actively exploring what it will take to move packages 
and projects to git.



   R-Forge was wonderful for me when I started using it.  Then 
several years ago, I started having problems like you described.  A few 
years ago I migrated from R-Forge to GitHub.



   One problem I encountered in the transition:  On R-Forge, I had 
multiple packages in the same R-Forge project.  I had to split them 
apart for GitHub.




I already know how to use a git client to clone a Subversion 
repository from R-Forge (using "git svn"). And how to change the 
remote origin to push it to a new git location. (And I  may also be 
willing to lose the revision history if it is going to make the 
transition easier.)


I am now at the step of understanding the recent changes at GitLab 
with respect to support for "Educational" or "Open Source" status, 
especially in terms of how many monthly minutes of CI/CD time I can 
use for free. When working on a new package, I tend to make lots of 
small commit-pushes, and it sounds like each one of those will eat up 
minutes. So, any advice on how to manage that issue would be greatly 
appreciated.



   When I first got into Subversion, I remember Doug Bates saying, 
"Commit early and often."  The word "Commit" doesn't mean the same in 
Git as in Subversion, so I would encourage you to "Git push early and 
often."



   There may be limits on free use of GitHub, but I'm not aware of 
them:  If you want a private account, you need to pay for that, but the 
charges for that are not much.


  The free tier of Github allows 2000 minutes/month of continuous 
integration testing for private repos, and unlimited (???) for public 
repos.  (2000 minutes/month is more than I've ever needed.)


  Furthermore, it's pretty easy to set up github actions so that it 
only runs tests if you ask it to (by appending e.g. "[run ci]" to your 
commit message), or in opt-out mode (i.e., skip tests if "[skip ci]" is 
in your commit message).





   If anyone knows anything different from what I've just said, I 
hope they will disabuse my of this part of my ignorance.



   Spencer



Best,
   Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves 
> wrote:


           If you use GitHub, I highly recommend using "GitHub
    Action" as
    described by Wickham and Bryan, R Packages:


    https://r-pkgs.org/code.html#code-style
    


           I'm not sure the best way to get it set up, but I have
    all my
    packages on GitHub configured so each "push" that changes anything 
has

    "R CMD Check" run on 5 different platforms:  The release version of
    R on
    the latest Windows, macOS, and Ubuntu plus the development version 
and
    the most recent old release on Ubuntu.  I rarely run R CMD check 
on my

    local machine anymore:  I just "git commit" and "git push".  Then
    GitHub
    Action manages testing on those 5 platforms.


           To be precise, I do "git status" before "git push" to
    make sure I
    have "committed" everything I want to commit before I "git push". 
    And I
    do "git pull" to make sure a collaborator hasn't "pushed" 
something new

    I should look at before I "git push".


           Finally, I want to thank again Gábor Csárdi who helped me
    greatly get
    past problems I hand with "GitHub Action" for my "sos" package.  He
    provided example workflows in:



https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml 



           I also needed LaTeX support, for which Gábor suggested
    the following:


    https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages





           Spencer Graves


    On 1/8/23 9:11 AM, Kevin R. Coombes wrote:
 > A very helpful answer. For some reason (probably because I have an
 > ancient perl script that automates the steps i take when building
    and
 > checking packages), I keep forgetting that the "tools" package
    let's me
 > do these things from within R.
 >
 > I had already isolated the offending line ("plot(obj)") inside
    the chunk
 > where the error occurred, and removed any additional arguments. I
 > wrapped that line in a "try" command followed by a conditional
 > "traceback()" to find the problem.  This allowed the 

Re: [R-pkg-devel] How to reduce examples in a package that takes more than 5 seconds to run?

[Ben Bolker]

On 2022-12-15 9:57 a.m., Brian G. Peterson wrote:

On 12/15/22 08:34, Ismail Otoakhia wrote:
The R package 'ardl.nardl' has some examples that take more than 5 
seconds
to run. I was advised by the CRAN team to reduce the run time to less 
than

5 seconds.

How can this be achieved?


- you can lower the amount of data in the example

- you can use a faster method than your default method

- you can wrap the example in a dontrun tag so it will not run during 
checking




  If your example involves something like a fitted model object that 
takes a long time to compute, you can pre-compute the model fit and 
store the object in an inst/testdata directory, then use something like


fitted_model <- readRDS(system.file("testdata", "my_example.rds", 
package = "mypackage"))


to retrieve it


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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


__
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

[Ben Bolker]

  Right now as.POSIXlt.Date() is just

function (x, ...)
.Internal(Date2POSIXlt(x))

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",

#> "POSIXt"), tzone = "UTC")
```


We noticed that this occurs because the tz argument is not passed to

`.Internal(Date2POSIXlt())` inside `as.POSIXlt.Date()`.


Reading through the documentation for `as.POSIX*` we can see that this

behaviour is described:


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

In this case, if we want to convert a Date object to POSIX* and specify

a (non-UTC) timezone would the best strategy be to first coerce our Date
object to character? Alternatively, `lubridate::as_datetime()` does seem to
recognise the tz argument and convert a Date object to POSIX* with non-UTC
time zone (see second example below). But it would be nice to know if there
are subtle differences between these two approaches that we should be aware
of.


``` r
foo <- as.Date(33874, origin = "1899-12-30")
dput(foo)
#> structure(8305, class = "Date")

#Convert to POSIXct specifying UTC timezone
bar <- lubridate::as_datetime(foo, tz = "UTC")
dput(as.POSIXlt(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 POSIXct specifying Europe/Berlin
bar <- lubridate::as_datetime(foo, tz = "Europe/Berlin")
dput(as.POSIXlt(bar))
#> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
#> year = 92L, wday = 0L, yday = 270L, isdst = 1L, zone = "CEST",

Re: [Rd] Linking to Intel's MKL on Windows

[Ben Bolker]

   Maybe you can find out more about Microsoft's development/release 
process for MRO and why they're still on 4.0.2 (from June 2020)?  I 
followed the "user forum" link on their web page, but it appears to be a 
generic Windows forum ...


https://social.msdn.microsoft.com/Forums/en-US/home?forum%20=ropen

   I might tweet at @revodavid (David Smith) to see if there's any more 
information available about the MRO release schedule ...


  good luck,
   Ben Bolker




On 2022-10-01 12:00 p.m., Viechtbauer, Wolfgang (NP) wrote:

Hi Christine,

MKL is a closed-source commercial product (yes, one can get it for free, but it 
is not libre/open-source software).

Best,
Wolfgang


-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Christine
Stawitz - NOAA Federal via R-devel
Sent: Friday, 30 September, 2022 18:46
To: r-devel@r-project.org
Subject: [Rd] Linking to Intel's MKL on Windows

Hi,

Recently I became aware that Microsoft R Open provides accelerated matrix
algebra computations through Intel's Math Kernel Libraries. However, the
version of R shipped with the Microsoft R Open is too out of date to be
able to use concurrently with other dependencies while developing our
package. This thread suggests a way to get the updated matrix libraries
with a more recent version of R, however it is unlikely to be approved by
our IT admin since those of us in government agencies aren't typically
given admin privileges: Linking Intel's Math Kernel Library (MKL) to R on
Windows - Stack Overflow
<https://stackoverflow.com/questions/38090206/linking-intels-math-kernel-library-
mkl-to-r-on-windows>

Is there a reason why CRAN doesn't provide a version of R with the updated
libraries such that developers don't have to recompile R or copy .dlls
around as described above? It would help those of us running software with
slow-running matrix calculations in R.

Thanks,
Christine

--
Christine C. Stawitz, PhD. (pronouns: she/her)

National Stock Assessment Program Modeling Team

NOAA Fisheries Office of Science and Technology |  U.S. Department of
Commerce

Mobile: 206-617-2060

www.fisheries.noaa.gov


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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Found the following (possibly) invalid URLs:

[Ben Bolker]

  I get a 404.

On 2022-09-29 4:50 p.m., Roy Mendelssohn - NOAA Federal via 
R-package-devel wrote:

In testing a new version of one of my package on win builder,   I get the 
following:

Found the following (possibly) invalid URLs:
.
.
.
   URL: 
https://www.integratedecosystemassessment.noaa.gov/regions/california-current-region/index.html
 From: inst/doc/Using_rerddap.html
 Status: 404
 Message: Not Found

It is only in the vignette as a place to look up more about a project,  it is 
never actually accessed,  moreover at least from my home computer it is valid 
URL that I reach. I know I can include something about this in cran-comments,  
but I would prefer not generating any notes so human intervention isn't needed. 
 Any suggestions?  Can others test the URL to see if they have problems 
reaching it.

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Package ‘wflo’ was removed from the CRAN repository.

[Ben Bolker]

  * Automatic unarchiving *might* happen because someone on the CRAN 
team happens to read this thread, but you will improve your odds greatly 
by e-mailing c...@r-project.org with as polite a request as you can 
manage ...


 * My guess is that nothing will happen until you resubmit (FWIW the 
NOTE definitely seems like something CRAN would object to, so you should 
fix it before resubmitting ...)


  good luck,
   Ben Bolker

On 9/22/22 4:15 PM, Carsten Croonenbroeck wrote:

Hi Lluís,

thanks for the clarification. And kudos to your detective flair. I’m serious 
about that, as I would never have found out about this chain of events.

Well, there are no error or warnings to fix, so I think it would be best if 
someone from the CRAN team could “unarchive” wflo since there is no problem 
there and none of the events that were set in motion were due to any of my 
doings. Actually, I don’t really agree to have to resubmit, and my time for 
doing so is very limited. Maybe in the next few weeks or so.

Best

Carsten


Von: Lluís Revilla [mailto:lluis.revi...@gmail.com]
Gesendet: Donnerstag, 22. September 2022 15:33
An: Carsten Croonenbroeck
Cc: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] Package ‘wflo’ was removed from the CRAN repository.

Hi Carsten,

This seems to be an unfortunate chain of events between different packages: 
RcppMLPACK -> emstreeR -> wflo

Package RcppMLPACK was archived on 2021-12-20 as issues were not corrected 
despite reminders.
This resulted in the package emstreeR being archived on 2021-12-20 as requires 
archived package 'RcppMLPACK'.
Which also resulted in your package, wflo, being archived.
Later, emstreeR was unarchived on 2022-03-21 after a successful submission 
improving the dependencies (probably removing the dependency to RcppMLPACK).
You can see the source of this info on 
https://cran.r-project.org/src/contrib/PACKAGES.in

About the emails, usually maintainers whose package depends on a package that 
is about to be removed receive an email with a date by which they should fix 
the problems.
But, as I am not part of the CRAN team I cannot check it.

I would recommend preparing a new submission with all the errors and warnings 
fixed.
Note that I think the package will be checked as a new package.

Best,

Lluís





On Thu, 22 Sept 2022 at 13:17, Carsten Croonenbroeck 
mailto:carsten.croonenbro...@uni-rostock.de>>
 wrote:
Hi,

I was really, really, really surprised to learn today that my package “wflo” 
was removed from CRAN almost a year ago!

Telling from the output at https://CRAN.R-project.org/package=wflo, this is due 
to my package being “Archived on 2021-12-20 as requires archived package 
'emstreeR'.” However, emstreeR is in no way archived (see 
https://CRAN.R-project.org/package=emstreeR). Clicking “check results archive”, 
it says that there is only a note

Result: NOTE
 Namespace in Imports field not imported from: ‘rgdal’
  All declared Imports should be used.

which is indeed correct, I don’t use rgdal anymore. What now, remove the rgdal 
import and resubmit? How come I wasn’t informed, my E-Mail is running 
perfectly. Very puzzling…

Best

Carsten

 [[alternative HTML version deleted]]

__
R-package-devel@r-project.org<mailto: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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Ben Bolker]

  There was a long apparently related thread back in May:

https://stat.ethz.ch/pipermail/r-devel/2022-May/081708.html

but that problem was supposedly patched in 4.2.1 ...


On 2022-09-22 9:48 a.m., Andrew Hart via R-devel wrote:
Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this 
is the right place to ask about it. If it's not, I'm hoping someone can 
point me in the right direction.


I'm blind and have been using R for about 11 years now. The base build 
available on CRAN is quite accessible and works pretty well with 
screen-reading software such as JAWS for Windows and NVDA. R-studio is 
not accessible which appears to have something to do with the version of 
QT it uses, but that's not relevant as I don't use it.


Recently I installed R 4.2.1 (I tend to upgrade two or three times a 
year and this time I was jumping from R 4.1.2 to 4.2.1).
However, I've encountered a serious problem which makes the latest 
version more or less unusable for doing any kind of serious work.
The issue is that the screen-reading software is unable to locate the R 
cursor and behaves as though the cursor is near the top left of the R 
application window. Practically, this means I can't tell what characters 
I'm passing over when cursoring left and right, nor can I hear what 
character is being deleted when the backspace is pressed. Most 
importantly, I can't tell where the insertion point is. This is a major 
regression in the ability to work with and edit the command line in the 
R console. There are ways of actually viewing the command line but the 
way I work is frequently calling up a previous command and making a 
change so as to not have to type the whole command again.


I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out 
exactly when things went awry and the issue first appeared in R 4.2.0.
Looking through the release notes, the only things mentioned that seem 
likely to be relevant are the following:


• R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle 
had a different layout and can no longer be used.


and

• R uses UTF-8 as the native encoding on recent Windows systems (at 
least Windows 10 version 1903, Windows Server 2022 or Windows Server 
1903). As a part
of this change, R uses UCRT as the C runtime. UCRT should be installed 
manually on systems older than Windows 10 or Windows Server 2016 before 
installing

R.

I can't really see how changing to utf-8 as the native encoding would 
produce the behaviour I'm seeing, so I am guessing that the change in 
TCL/TK might be the culprit.


I'm hoping that someone will be able to help shed some light on what's 
going on here.


Thanks a lot,
Andrew.

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Warning... unable to translate 'Ekstrm' to a wide string; Error... input string 1 is invalid

[Ben Bolker]

 The help pages are at

https://github.com/wch/r-source/blob/trunk/src/library/base/man/iconv.Rd

or the equivalent at https://github.com/r-devel/r-svn

or https://svn.r-project.org/R/trunk/src/library/base/man/iconv.Rd

  they still have \x examples in them, but maybe the use of \x is not 
flagged in the particular context of those examples?



On 2022-07-19 1:32 PM, Spencer Graves wrote:

Hi, Bill, Tomas, et al.:


On 7/19/22 12:10 PM, Bill Dunlap wrote:

Have you tried changing the \x's in that file with \u's?

 > qx <- c("\xf6", "\xf8", "\xdf", "\xfc")
 > Encoding(qx) <- "latin1"
 > qu <- c("\uf6", "\uf8", "\udf", "\ufc")
 > Encoding(qu)
[1] "UTF-8" "UTF-8" "UTF-8" "UTF-8"
 > qx == qu
[1] TRUE TRUE TRUE TRUE



I have not tried anything yet for three reasons:


  1.  I don't know that I have access to anything that can do the 
proper test that's required, so I can know if I've fixed it or not.



  I'm not sure what you need.  AFAIK r-hub's test platforms are still 
down, but win-builder and





  2.  Tomas' blog included examples that seemed to say to replace 
"\xa0" with "\u00a0", NOT "\ua0", and I don't know if this difference 
matters or not.



  3.  Can someone provide me with a link to the correct 
development version of help('iconv')?  The current version includes 
the exact offending "\x" strings that I have.  If I know the fix in 
the correct development version of help('iconv'), I can copy that.  
Without that, I'm being asked to correct something that may not have 
been corrected in the development version of the base package.



  There are \x's in the examples there




  Thanks,
  Spencer



(charToRaw shows that qu and qx are not byte-for-byte identical: '==' 
coerces the latin1 strings to utf-8.)


-Bill

On Tue, Jul 19, 2022 at 9:38 AM Spencer Graves 
> wrote:


    Hi, Tomas:


    On 7/19/22 2:20 AM, Tomas Kalibera wrote:
 >
 > On 7/19/22 08:37, Spencer Graves wrote:
 >> Hello:
 >>
 >>
 >>   What's the recommended fix for "Warning in
    gsub(gsLi$pattern,
 >> gsLi$replacement, xo) : unable to translate 'Ekstrm' to a 
wide
 >> string; Error in gsub(gsLi$pattern, gsLi$replacement, xo) : 
input

 >> string 1 is invalid"?
 >>
 >>
 >>   This is in:
 >>
 >>
 >>
https://github.com/sbgraves237/Ecfun/blob/master/man/subNonStandardCharacters.Rd


 >>
 >>
 >>
 >>   R-devel is now rejecting some non-ASCII characters that it
 >> previously accepted;  see below.
 >
 > Please see
 >
https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions


 >
 >
 > Looking at the code I guess you should change the strings in icx
    to use
 > \u escapes instead of \x. The use of \x as it is there was 
probably
 > correct when the code was ran in Latin-1 encoding, but not in 
other

 > encodings. Using \u would make it portable. Feel free to ask more
    if my
 > guess is wrong and reading the blog post doesn't help.


           "subNonStandardCharacters.Rd" copies examples from:


https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/iconv



           This file still contains "\x" in 5 places. What's the
    recommended
    fix?  Replace "\x" with "\u00" everyplace?


           I could try that, but I don't know if I have access to
    platforms that
    would tell me if I fixed it or not ;-)


           Thanks very much.
           Spencer Graves

 >
 > Best
 > Tomas
 >
 >
 >
 >>
 >>
 >>   Thanks,
 >>   Spencer Graves
 >>
 >>
 >>  Forwarded Message 
 >> Subject: CRAN package Ecfun and its reverse dependencies
 >> Date: Wed, 13 Jul 2022 06:34:24 +0100
 >> From: Prof Brian Ripley mailto:rip...@stats.ox.ac.uk>>
 >> Reply-To: c...@r-project.org
 >> To: veronica.vincio...@brunel.ac.uk
    ,
 >> spencer.gra...@effectivedefense.org
    , hamedhas...@gmail.com
    ,
 >> dennis.pran...@gmail.com 
 >> CC: c...@r-project.org
 >>
 >> Dear maintainers,
 >>
 >> This concerns the CRAN packages
 >>
 >>   BDWreg DWreg Ecdat Ecfun gk
 >>
 >> maintained by one of you:
 >>
 >>   Dennis Prangle mailto:dennis.pran...@gmail.com>>: gk
 >>   Hamed Haselimashhadi mailto:hamedhas...@gmail.com>>: BDWreg
 >>   Spencer Graves mailto:spencer.gra...@effectivedefense.org>>: Ecfun Ecdat
 >>   Veronica Vinciottimailto:veronica.vincio...@brunel.ac.uk>>: 

Re: [R-pkg-devel] DOI / URL issues in package vignettes

[Ben Bolker]

On 2022-05-18 6:56 a.m., Ivan Krylov wrote:

В Wed, 18 May 2022 12:06:03 +1000
Joshua Wiley  пишет:


curl -I -L https://doi.org/10.1037/met434

gives the below on my system, which (I think?) means you get the
expected redirect for a DOI and then a 403 forbidden error.  On the
win-builder.r-project.org service (which is fantastic) I get a status
400 bad request.

For other DOIs, I am regularly getting a 503 service unavailable
status from both curl on my machine and winbuilder, but working fine
in browser (e.g., for:   https://doi.org/10.1002/sim.7171).


Many journals employ overzealous anti-robot protection systems that
discriminate against URL checks performed by R, but as long as the DOI
itself is correct, the package is likely to be accepted by CRAN despite
the NOTE resulting from the failing check. You can mention it in the
submission comment to be sure.


  And there was a previous discussion on the list here:

https://hypatia.math.ethz.ch/pipermail/r-package-devel/2022q2/008042.html

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

Re: [Rd] Writing in R // R 4.2.0 on Windows doesn't work with Dasher

[Ben Bolker]

 VScode is sorta-kinda open source 
https://opensource.com/article/20/6/open-source-alternatives-vs-code 
(that is, the default downloadable binaries are non-freely licensed). 
Presumably the open builds also work.


  On the other hand, it's also developed by Microsoft, so it's not much 
of a surprise that it works better on Windows than some of the alternatives.


On 2022-05-15 5:48 p.m., Duncan Murdoch wrote:

On 15/05/2022 5:01 p.m., Kasper Daniel Hansen wrote:
It is interesting that Paulo reports Rgui to behave differently from 
many (all?) other applications. However, I have no insight into Windows.


It's not a big surprise.  Rgui uses a UI library (Graphapp) that was 
written a very long time ago, and it hasn't adopted their updates in at 
least 15 years.  Additionally, Rgui hasn't really had any Windows users 
giving it the attention it needs.


And not nearly "all".  RStudio has different problems, which means 
everyone using the same UI library they use probably has them too.  I 
didn't see any open source projects in the list of things that work.


Duncan Murdoch



Best,
Kasper

On Sun, May 15, 2022 at 3:32 PM Duncan Murdoch 
mailto:murdoch.dun...@gmail.com>> wrote:


    On 15/05/2022 2:44 p.m., Ben Bolker wrote:
 >     I don't know if there's a good up-to-date list anywhere of
 > editors/IDEs that handle R nicely, but it would include at least:
 >
 >     Atom
 >     Sublime Text
 >     VS Code
 >     RStudio
 >     Jupyter notebooks
 >     vim
 >     emacs
 >     Tinn-R
 >
 >     It's worth being able to choose from such a list both for 
general
 > aesthetic preferences, and for those with accessibility 
challenges.


    One more that I should have mentioned:  StatET, a plug-in for the
    Eclipse IDE.

 >
 >    I do agree that it would be nice if there were a way to make 
the R

 > console work well with Dasher under Windows, but the technical
    details
 > are completely beyond me.

    A long time ago I used to know some of this stuff, but now I find
    working in Windows quite difficult.  I never knew it well enough to
    know
    the advantages and disadvantages of the approach RGui uses versus the
    one that dasher seems to be expecting.

    On the hopeful side, accessibility has always had a relatively high
    priority in the R Project, and there seems to be a recent push in 
that

    direction.  Perhaps there will be an opportunity for someone to
    bring up
    this issue at useR! 2022 (https://user2022.r-project.org
    <https://user2022.r-project.org>).

    Duncan Murdoch

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



--
Best,
Kasper




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics

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

[R-pkg-devel] nit-picking about CRAN repository policy

[Ben Bolker]

  Folks,

  CRAN has recently set up an auxiliary 'noSuggests' test platform that 
tests that packages are using suggested packages conditionally, as 
recommended in Writing R Extensions, and as (sort of) specified in the 
CRAN repository policy.


  Specifically, the CRP (revision 5236) says:

> A package listed in ‘Suggests’ or ‘Enhances’ should be used 
conditionally in examples or tests if it cannot straightforwardly be 
installed on the major R platforms. (‘Writing R Extensions’ recommends 
that they are always used conditionally.)


  One of my packages failed on the 'noSuggest' test platform 
<https://www.stats.ox.ac.uk/pub/bdr/noSuggests/bbmle.out> because two 
suggested packages were used unconditionally in the vignette. There are 
two reasons (IMO) that this should *not* have triggered a threat of 
archiving:


  (1) the unconditional package use was in a vignette, not in examples 
or tests
  (2) the relevant packages (AICcmodavg and MuMIn) are available on 
CRAN and install easily on Linux/Windows/MacOS (they are R-only, no 
compiled code or extra requirements, binaries are available on CRAN).


   Is it worth suggesting to CRAN maintainers that either they refine 
their 'noSuggests' test so that it conforms to the wording in the CRP, 
or that they change the CRP wording to something stricter like


> Any package listed in ‘Suggests’ or ‘Enhances’ should be used 
conditionally in examples, tests, and vignettes.


 ?

  cheers
    Ben Bolker

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

[Rd] model.weights and model.offset: request for adjustment

[Ben Bolker]

  The model.weights() and model.offset() functions from the 'stats' 
package index possibly-missing elements of a data frame via $, e.g.


x$"(offset)"
x$"(weights)"

This returns NULL without comment when x is a data frame:

x <- data.frame(a=1)
x$"(offset)"  ## NULL
x$"(weights)"  ## NULL

However, when x is a tibble we get a warning as well:

x <- tibble::as_tibble(x)
x$"(offset)"
## NULL
## Warning message:
## Unknown or uninitialised column: `(offset)`.

   I know it's not R-core's responsibility to manage forward 
compatibility with tibbles, but in this case [[-indexing would seem to 
be better practice in any case.


  Might a patch be accepted ... ?

  cheers
   Ben Bolker

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

Re: [Rd] partial matching of row names in [-indexing

[Ben Bolker]

  Makes sense if you realize that ?"[" only applies to *vector*, 
*list*, and *matrix* indexing and that data frames follow their own 
rules that are documented elsewhere ...


  So yes, not a bug but I claim it's an infelicity. I might submit a 
doc patch.


 FWIW

b["A1",]
as.matrix(b)["A1",]

 illustrates the difference.

 thanks
   Ben


On 1/14/22 9:19 PM, Steve Martin wrote:

I don't think this is a bug in the documentation. The help page for
`?[.data.frame` has the following in the last paragraph of the
details:

Both [ and [[ extraction methods partially match row names. By default
neither partially match column names, but [[ will if exact = FALSE
(and with a warning if exact = NA). If you want to exact matching on
row names use match, as in the examples.

The example it refers to is

sw <- swiss[1:5, 1:4]  # select a manageable subset
sw["C", ] # partially matches
sw[match("C", row.names(sw)), ] # no exact match

Whether this is good behaviour or not is a different question, but the
documentation seems clear enough (to me, at least).

Best,
Steve

On Fri, 14 Jan 2022 at 20:40, Ben Bolker  wrote:



People are often surprised that row-indexing a data frame by [ +
character does partial matching (and annoyed that there is no way to
turn it off:

https://stackoverflow.com/questions/18033501/warning-when-partial-matching-rownames

https://stackoverflow.com/questions/34233235/r-returning-partial-matching-of-row-names

https://stackoverflow.com/questions/70716905/why-does-r-have-inconsistent-behaviors-when-a-non-existent-rowname-is-retrieved


?"[" says:

Character indices can in some circumstances be partially matched
   (see ‘pmatch’) to the names or dimnames of the object being
   subsetted (but never for subassignment).  UNLIKE S (Becker et al_
   p. 358), R NEVER USES PARTIAL MATCHING WHEN EXTRACTING BY ‘[’, and
   partial matching is not by default used by ‘[[’ (see argument
   ‘exact’).

(EMPHASIS ADDED).

Looking through the rest of that page, I don't see any other text that
modifies or supersedes that statement.

Is this a documentation bug?

The example given in one of the links above:

b <- as.data.frame(matrix(4:5, ncol = 1, nrow = 2, dimnames =
list(c("A10", "B"), "V1")))

b["A1",]  ## 4 (partial matching)
b[rownames(b) == "A1",]  ## logical(0)
b["A1", , exact=TRUE]## unused argument error
b$V1[["A1"]] ## subscript out of bounds error
b$V1["A1"]   ## NA

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics

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

[Rd] partial matching of row names in [-indexing

[Ben Bolker]

  People are often surprised that row-indexing a data frame by [ + 
character does partial matching (and annoyed that there is no way to 
turn it off:


https://stackoverflow.com/questions/18033501/warning-when-partial-matching-rownames

https://stackoverflow.com/questions/34233235/r-returning-partial-matching-of-row-names

https://stackoverflow.com/questions/70716905/why-does-r-have-inconsistent-behaviors-when-a-non-existent-rowname-is-retrieved


?"[" says:

Character indices can in some circumstances be partially matched
 (see ‘pmatch’) to the names or dimnames of the object being
 subsetted (but never for subassignment).  UNLIKE S (Becker et al_
 p. 358), R NEVER USES PARTIAL MATCHING WHEN EXTRACTING BY ‘[’, and
 partial matching is not by default used by ‘[[’ (see argument
 ‘exact’).

(EMPHASIS ADDED).

Looking through the rest of that page, I don't see any other text that 
modifies or supersedes that statement.


  Is this a documentation bug?

The example given in one of the links above:

b <- as.data.frame(matrix(4:5, ncol = 1, nrow = 2, dimnames = 
list(c("A10", "B"), "V1")))


b["A1",]  ## 4 (partial matching)
b[rownames(b) == "A1",]  ## logical(0)
b["A1", , exact=TRUE]## unused argument error
b$V1[["A1"]] ## subscript out of bounds error
b$V1["A1"]   ## NA

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

[Rd] documentation patch for as.formula → reformulate

[Ben Bolker]

  There was some discussion on twitter about the fact that the manual 
page for as.formula() doesn't mention reformulate(), and indeed the last 
example is


## Create a formula for a model with a large number of variables:
 xnam <- paste0("x", 1:25)
 (fmla <- as.formula(paste("y ~ ", paste(xnam, collapse= "+"


which could arguably be better done as

  reformulate(xname, response = "y")

  I've attached a documentation patch that adds the alternative version 
and a \seealso{} link.


  Happy to submit to r-bugzilla if requested.

  cheers
   Ben Bolker
Index: formula.Rd
===
--- formula.Rd  (revision 81462)
+++ formula.Rd  (working copy)
@@ -158,9 +158,10 @@
 \seealso{
   \code{\link{~}}, \code{\link{I}}, \code{\link{offset}}.
 
-  For formula manipulation: \code{\link{terms}}, and \code{\link{all.vars}};
-  for typical use: \code{\link{lm}}, \code{\link{glm}}, and
+  For formula manipulation: \code{\link{terms}}, and \code{\link{all.vars}}.
+  For typical use: \code{\link{lm}}, \code{\link{glm}}, and
   \code{\link{coplot}}.
+  For formula construction: \code{\link{reformulate}}.
 }
 \examples{
 class(fo <- y ~ x1*x2) # "formula"
@@ -176,5 +177,8 @@
 ## Create a formula for a model with a large number of variables:
 xnam <- paste0("x", 1:25)
 (fmla <- as.formula(paste("y ~ ", paste(xnam, collapse= "+"
+## Equivalent with reformulate():
+fmla2 <- reformulate(xnam, response = "y")
+identical(fmla, fmla2)
 }
 \keyword{models}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] trivial typo in NEWS file

[Ben Bolker]

  Index: doc/NEWS.Rd
===
--- doc/NEWS.Rd (revision 81435)
+++ doc/NEWS.Rd (working copy)
@@ -425,7 +425,7 @@
   data frames with default row names (Thanks to Charlie Gao's
   \PR{18179}).

-  \item \code{txtProgresBar()} now enforces a non-zero width for
+  \item \code{txtProgressBar()} now enforces a non-zero width for
   \code{char}, without which no progress can be visible.

   \item \code{dimnames(table(d))} is more consistent in the case where

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

Re: [Rd] Why does lm() with the subset argument give a different answer than subsetting in advance?

[Ben Bolker]

  I agree that it seems non-intuitive (I can't think of a design reason 
for it to look this way), but I'd like to stress that it's *not* an 
information leak; the predictions of the model are independent of the 
parameterization, which is all this issue affects. In a worst case there 
might be some unfortunate effects on numerical stability if the 
data-dependent bases are computed on a very different set of data than 
the model fitting actually uses.


  I've attached a suggested documentation patch (I hope it makes it 
through to the list, if not I can add it to the body of a message.)




On 12/26/21 8:35 PM, Balise, Raymond R wrote:

Hello R folks,
Today I noticed that using the subset argument in lm() with a polynomial gives 
a different result than using the polynomial when the data has already been 
subsetted. This was not at all intuitive for me.You can see an example 
here: 
https://stackoverflow.com/questions/70490599/why-does-lm-with-the-subset-argument-give-a-different-answer-than-subsetting-i

 If this is a design feature that you don’t think should be 
fixed, can you please include it in the documentation and explain why it makes 
sense to figure out the orthogonal polynomials on the entire dataset?  This 
feels like a serous leak of information when evaluating train and test datasets 
in a statistical learning framework.

Ray

Raymond R. Balise, PhD
Assistant  Professor
Department of Public Health Sciences, Biostatistics

University of Miami, Miller School of Medicine
1120 N.W. 14th Street
Don Soffer Clinical Research Center - Room 1061
Miami, Florida 33136



[[alternative HTML version deleted]]

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics
Index: lm.Rd
===
--- lm.Rd   (revision 81416)
+++ lm.Rd   (working copy)
@@ -33,7 +33,9 @@
 typically the environment from which \code{lm} is called.}
 
   \item{subset}{an optional vector specifying a subset of observations
-to be used in the fitting process.}
+to be used in the fitting process. (See additional details about how
+this argument interacts with data-dependent bases in the
+\sQuote{Details} section of the \code{\link{model.frame}} documentation.)
 
   \item{weights}{an optional vector of weights to be used in the fitting
 process.  Should be \code{NULL} or a numeric vector.
Index: model.frame.Rd
===
--- model.frame.Rd  (revision 81416)
+++ model.frame.Rd  (working copy)
@@ -38,7 +38,9 @@
   \item{subset}{a specification of the rows to be used: defaults to all
 rows. This can be any valid indexing vector (see
 \code{\link{[.data.frame}}) for the rows of \code{data} or if that is not
-supplied, a data frame made up of the variables used in \code{formula}.}
+supplied, a data frame made up of the variables used in
+\code{formula}. (See additional details about how this argument
+interacts with data-dependent bases under \sQuote{Details} below.)
 
   \item{na.action}{how \code{NA}s are treated.  The default is first,
 any \code{na.action} attribute of \code{data}, second
@@ -103,6 +105,12 @@
   character variable is found, it is converted to a factor (as from \R
   2.10.0).
 
+  Because variables in the formula are evaluated before rows are dropped
+  based on \code{subset}, the characteristics of data-dependent bases
+  such as orthogonal polynomials (i.e. from terms using
+  \code{\link{poly}}) or splines will be computed based on the full data
+  set rather than the subsetted data set.
+
   Unless \code{na.action = NULL}, time-series attributes will be removed
   from the variables found (since they will be wrong if \code{NA}s are
   removed).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] plogis (and other p* functions), vectorized lower.tail

[Ben Bolker]

On 12/9/21 10:03 AM, Martin Maechler wrote:

Matthias Gondan
 on Wed, 8 Dec 2021 19:37:09 +0100 writes:


 > Dear R developers,
 > I have seen that plogis silently ignores vector elements of lower.tail,

and also of 'log'.
This is indeed the case for all d*, p*, q* functions.

Yes, this has been on purpose and therefore documented, in the
case of plogis, e.g. in the 'Value' section of ?plogis :

  The length of the result is determined by ‘n’ for ‘rlogis’, and is
  the maximum of the lengths of the numerical arguments for the
  other functions.

  (note: *numerical* arguments: the logical ones are not recycled)

  The numerical arguments other than ‘n’ are recycled to the length
  of the result.  Only the first elements of the logical arguments
  are used.

  (above, we even explicitly mention the logical arguments ..)


Recycling happens for the first argument (x,p,q) of these
functions and for "parameters" of the distribution, but not for
lower.tail, log.p (or 'log').


 >> plogis(q=0.5, location=1, lower.tail=TRUE)
 > [1] 0.3775407
 >> plogis(q=0.5, location=1, lower.tail=FALSE)
 > [1] 0.6224593
 >> plogis(q=c(0.5, 0.5), location=1, lower.tail=c(TRUE, FALSE))
 > [1] 0.3775407 0.3775407

 > For those familiar with psychological measurement: A use case of the 
above function is the so-called Rasch model, where the probability that a person 
with some specific ability (q) makes a correct (lower.tail=TRUE) or wrong response 
(lower.tail=FALSE) to an item with a specific difficulty (location). A vectorized 
version of plogis would enable to determine the likelihood of an entire response 
vector in a single call. My current workaround is an intermediate call to 
„Vectorize“.

 > I am wondering if the logical argument of lower.tail can be vectorized 
(?). I see that this may be a substantial change in many places (basically, all p 
and q functions of probability distributions), but in my understanding, it would 
not break existing code which assumes lower.tail to be a single element. If that’s 
not
 > possible/feasible, I suggest to issue a warning if a vector of length > 
1 is given in lower.tail. I am aware that the documentation clearly states that 
lower.tail is a single boolean.

aah ok, here you say you know that the current behavior is documented.

 > Thank you for your consideration.


As you mention, changing this would be quite a large endeavor.
I had thought about doing that many years ago, not remembering
details, but seeing that in almost all situations you really
only need one of the two tails  (for Gaussian- or t- based confidence
intervals you also only need one, for symmetry reason).

Allowing the recycling there would make the intermediate C code
(which does the recycling) larger and probably slightly
slower because of conceptually two more for loops which would in
99.9% only have one case ..

I'd have found that ugly to add. ... ...
... but of course, if you can prove that the code bloat would not be large
and not deteriorate speed in a measurable way and if you'd find
someone to produce a comprehensive and tested patch ...

Martin


 > With best wishes,
 > Matthias



 > [[alternative HTML version deleted]]

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

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



  I agree with everything said above, but think that adding a warning 
when length(lower.tail) > 1 (rather than silently ignoring) might be 
helpful ...  ??


  As for the vectorization, it seems almost trivial to do at the user 
level when needed (albeit it's probably a little bit inefficient):


pv <- Vectorize(plogis, c("q", "location", "scale", "lower.tail"))
pv(q=c(0.5, 0.5), location=1, lower.tail=c(TRUE, FALSE))
[1] 0.3775407 0.6224593

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

Re: [R-pkg-devel] Using \donttest with R >= 4.0.0

[Ben Bolker]

  (This crossed with Martin Ondrus's reply).

  In the past few years CRAN screeners have gotten more strict about 
\dontrun{}; a first-round screening often comes back requesting that 
\dontrun{}, and commented-out examples, not be used.


https://stat.ethz.ch/pipermail/r-package-devel/2018q3/003084.html
https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002811.html

  Guido, perhaps the screening is being applied differently in your case?

  Another strategy, albeit one that is a little bit annoying/requires 
some more machinery, is to store pre-computed objects in 
inst/example-data, then do something like



fitted_model <- readRDS(system.file("example-data", "fit1.rds", package 
= "my_pkg"))


 the object (which takes too long to fit as part of a testing flow) 
then becomes available for showing how methods apply to it.


  cheers
   Ben


On 11/16/21 2:56 PM, Guido Schwarzer wrote:

Am 16.11.21 um 20:16 schrieb Martin Ondrus:


Hi Duncan,

That's a fair point, and I think making the examples run quicker probably
makes the most sense. I have bad experiences with using dontrun - my
package always gets flagged. Although not ideal, it's probably better to
include some very fast running examples rather than none at all. 
Appreciate

your advice/help!


I have been using dontrun for a long time (and I am still using it) 
without any real issues. Initially, I used it to get rid of runtime 
notes impeding submission to CRAN. Now I am also using it for additional 
features, e.g., to describe some additional analyses / figure layouts.


I always check my packages under R-devel on 
https://win-builder.r-project.org/ before submission to CRAN. If this 
does not trigger any notes, the package is good to go.


Best, Guido

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics

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

Re: [Rd] stats::fft produces inconsistent results

[Ben Bolker]

  Nice!

On 10/21/21 4:26 PM, Dipterix Wang wrote:
Thank you for such detailed and plain explanation. It is much clearer to 
me now w.r.t. the R internal memory management and how PROTECT should be 
used.


Also after diving into the documentation of FFTW3 library, I think I 
found why the data was centered.


https://www.fftw.org/fftw3_doc/Planner-Flags.html 



Basically
1. FFTW3 modifies the input data by default
2. one has to initialize the data after planning fft (except for some 
special situations). This “subtle” detail is buried in their 
documentation and is very hard to debug once a mistake is made.


The second one actually causes CRAN package fftwtools to produce 
inconsistent results on osx 
(https://github.com/krahim/fftwtools/issues/15 
)


Best,
Dipterix

On Oct 21, 2021, at 6:32 AM, GILLIBERT, Andre 
mailto:andre.gillib...@chu-rouen.fr>> 
wrote:


> Haha, thanks : ) I guess I will probably be grouchy too if seeing so many 
people making the same mistakes again and again. It just happened to be me.

Fortunately, you did not get offensed. :)

This is nice to have a large community of developers for R packages, 
even if, sometimes, buggy packages are annoying R developers because 
any small change in R may "break" them even though they were actually 
broken from the begining.


>Indeed, I found myself often confused about when to PROTECT and when not.

A (relatively) quick explanation.
There are several “pools” of data objects that have different rules. 
The most common “pool” is the pool of garbage collectable R objects, 
that can be allocated with allocVector and is passed from R to C code 
and vice versa. Another pool is the malloc/free pool, that works with 
explicit allocation/deallocation. R does not modify the malloc/free 
implementation in any way, and memory leaks may happen. Operating 
systems may have other pools of memory (e.g. mmap'ed memory) that are 
not handled by R either. There is also a transient storage 
(R_alloc/vmaxset/vmaxget) that is automatically freed when returning 
from C to R, and should be used for temporary storage but not for 
objects returned to R code.


The PROTECT system is needed for garbage collectable objects.
The garbage collector may trigger whenever a R internal function is 
called. Typically, when some memory is internally allocated.
The garbage collector frees objects that are neither referenced 
directly nor indirectly from R code and from the PROTECT stack.
The PROTECT stack is used by C code to make sure objects that are not 
yet (or will never be) referenced by R code, are not destroyed when 
the garbage collector runs.


The functions allocating new R objects, such as allocVector(), but 
also coerceVector(), duplicate(),return unprotected objects, that may 
be destroyed the next time an internal R function is called, unless it 
is explicitly PROTECT'ed before. Indeed, such objects would have no 
reference from R code and so, would be deleted.


The PROTECT stack must be balanced on a call from R to a C function. 
There must be as many UNPROTECT'ions than PROTECT'ions.


The typical C code PROTECTs any object allocated as soon as it is 
allocated (e.g. call to allocVector or coerceVector). It UNPROTECTs 
temporary objects to "free" them (the actual memory release may be 
delayed to the next garbage collection). It UNPROTECTs the object it 
returns to R code. Indeed, in pure C code, there will be no garbage 
collection between the time the object is UNPROTECTed and the time R 
grabs the object. You must be very careful if you are using C++, 
because destructors must not call any R internal function that may 
trigger a garbage collection.
The arguments to the C code, do not have to be PROTECT'ed, unless they 
are re-allocated. For instance, it is frequent to call coerceVector or 
arguments and re-assign them to the C variable that represents the 
argument. The new object must be PROTECT'ed.


Actually, you do not need to *directly* PROTECT all objects that are 
allocated in the C function, but you must make sure that all objects 
are *indirectly* PROTECT'ed. For instance, you may allocate a VECSXP 
(a "list" in R) and fill the slots with newly allocated objects. You 
only need to PROTECT the VECSXP, since its slots are indirectly protected.


If you have any doubt, it is not a bug to over-PROTECT objects. It may 
slightly slow down garbage collection and use space on the PROTECTion 
stack, but that is rarely a big deal. You should only avoid that when 
that would lead to thousands or millions of protections.


As I said, the PROTECT stack must be balanced between the entry and 
exit of the C code. This is not a problem for 99% of functions that 
free all the memory they use internally except the object that is 
returned. Sometimes, some "background" memory, hidden to R code, may 
have to be allocated for more time. A call to R_PreserveObject 

Re: [Rd] stats::fft produces inconsistent results

[Ben Bolker]

  This is a long shot, but here's a plausible scenario:

  as part of its pipeline, ravetools::mvfftw computes the mean of the 
input vector **and then centers it to a mean of zero** (intentionally or 
accidentally?)


  because variables are passed to compiled code by reference (someone 
can feel free to correct my terminology), this means that the original 
vector in R now has a mean of zero


  the first element of fft() is mean(x)*length(x), so if mean(x) has 
been forced to zero, that would explain your issue.


  I don't know about the non-reproducibility part.

On 10/19/21 7:06 PM, Dipterix Wang wrote:

Dear R-devel Team,

I'm developing a neuroscience signal pipeline package in R 
(https://github.com/dipterix/ravetools) and I noticed a weird issue that failed 
my unit test.

Basically I was trying to use `fftw3` library to implement fast multivariate 
fft function in C++. When I tried to compare my results with stats::fft, the 
test result showed the first element of **expected** (which was produced by 
stats::fft) was zero, which, I am pretty sure, is wrong, and I can confirm that 
my function produces correct results.

However, somehow I couldn’t reproduce this issue on my personal computer (osx, 
M1, R4.1.1), the error simply went away.

The catch is my function produced consistent and correct results but stats::fft 
was not. This does not mean `stats::fft` has bugs. Instead, I suspect there 
could be some weird interactions between my code and stats::fft at C/C++ level, 
but I couldn’t figure it out why.

+++ Details:

Here’s the code I used for the test:

https://github.com/dipterix/ravetools/blob/4dc35d64763304aff869d92dddad38a7f2b30637/tests/testthat/test-fftw.R#L33-L41

Test code
set.seed(1)
x <- rnorm(1000)
dim(x) <- c(100,10)
a <- ravetools:::mvfftw_r2c(x, 0)
c <- apply(x, 2, stats::fft)[1:51,]
expect_equal(a, c)


Here are the tests that gave me the errors:

The test logs on win-builder
https://win-builder.r-project.org/07586ios8AbL/00check.log

Test logs on GitHub
https://github.com/dipterix/ravetools/runs/3944874310?check_suite_focus=true


—— Failed tests ——
  -- Failure (test-fftw.R:41:3): mvfftw_r2c 
--
  `a` (`actual`) not equal to `c` (`expected`).

  actual vs expected
  [,1][,2]  
[,3]  [,4]...
  - actual[1, ] 10.8887367+ 0.000i  -3.7808077+ 0.000i   2.967354+ 
0.00i   5.160186+ 0.00i ...
  + expected[1, ]0.000+ 0.000i  -3.7808077+ 0.000i   2.967354+ 
0.00i   5.160186+ 0.00i...



The first columns are different, `actual` is the results I produced via 
`ravetools:::mvfftw_r2c`, and `expected` was produced by `stats::fft`


Any help or attention is very much appreciated.
Thanks,
- Zhengjia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] [Tagged] Re: multithreading in packages

[Ben Bolker]

  FWIW there is some machinery in the glmmTMB package for querying, 
setting, etc. the number of OpenMP threads.


https://github.com/glmmTMB/glmmTMB/search?q=omp

On 10/9/21 11:45 AM, Vladimir Dergachev wrote:



On Sat, 9 Oct 2021, Jeff Newmiller wrote:

Keep in mind that by embedding this decision into your package you may 
be consuming a resource (cores) that may be more efficiently allocated 
by an application-level partitioning. of available resources. I for 
one am not a fan of this kind of thinking, and it makes system 
requirements for your package more complex even if you allow me to 
disable it.


That's right, and this is why I was asking about any present or future 
plans for R support - if there was a way to find out how many threads R 
should use, I would use that.


So far, it looks like the most portable way is to use OpenMP and let the 
user set an appropriate environment variable if they want to restrict 
thread usage. I could use the same OpenMP variable for pthreads as well.


This is pretty common on clusters anyway, with openmp environment 
variables set automatically to the number of cores user requested.


I would probably also add a function to the package to report the number 
of threads being used. Not sure whether it would be a good idea to 
report this during package loading (and not sure what is the right way 
to display a message during package load either).


best

Vladimir Dergachev

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] [External] Formula modeling

[Ben Bolker]

  There's a Formula package on CRAN 
 that's 
designed for this use case.


  lme4 and nlme don't use it, but implement their own formula 
manipulation machinery. (The cleanest version of this machinery is 
actually in glmmTMB at 
https://github.com/glmmTMB/glmmTMB/blob/master/glmmTMB/R/reformulas.R .)


  I would probably recommend Duncan's or Richard's approach, but if you 
want to keep your original syntax then the Formula package is probably 
the way to go.



On 10/7/21 5:58 PM, Duncan Murdoch wrote:
I don't work with models like this, but I would find it more natural to 
express the multiple formulas in a list:


   list(d ~ p + x + y, s ~ p + w + y, p ~ z + y)

I'd really have no idea how either of the proposals below should be parsed.

Of course, if people working with models like this are used to working 
with notation like yours, that would be a strong argument to use your 
notation.


Duncan Murdoch

On 07/10/2021 5:51 p.m., Richard M. Heiberger wrote:
I am responding to a subset of what you asked.  There are packages 
which use multiple formulas

in their argument sequence.


What you have as a single formula with | as a separator
q | p | subject | time | rho ~ p + x + y | p + w + y | z + y
I think would be better as a comma-separated list of formulas

q , p , subject , time , rho ~ p + x + y , p + w + y , z + y

because in R notation | is usually an operator, not a separator.

lattice uses formulas and the | is used as a conditioning operator.

nlme and lme4 can have multiple formulas in the same calling sequence.

lme4 is newer.  from its ?lme4-package
‘lme4’ covers approximately the same ground as the earlier ‘nlme’
  package.

lme4 should probably be the modelyou are looking for for the package 
design.



On Oct 07, 2021, at 17:20, pikappa.de...@gmail.com wrote:

Dear R-package-devel subscribers,



My question concerns a package design issue relating to the usage of
formulas.



I am interested in describing via formulas systems of the form:



d = p + x + y

s = p + w + y

p = z + y

q = min(d,s).



The context in which I am working is that of market models with, 
primarily,

panel data. In the above system, one may think of the first equation as
demand, the second as supply, and the third as an equation 
(co-)determining
prices. The fourth equation is implicitly used by the estimation 
method, and
it does not need to be specified when programming the R formula. If 
you need

more information bout the system, you may check the package diseq.
Currently, I am using constructors to build market model objects. In a
constructor call, I pass [i] the right-hand sides of the first three
equations as strings, [ii] an argument indicating whether the 
equations of
the system have correlated shocks, [iii] the identifiers of the used 
dataset
(one for the subjects of the panel and one for time), and [iv] the 
quantity
(q) and price (p) variables. These four arguments contain all the 
necessary

information for constructing a model.



I would now like to re-implement model construction using formulas, 
which

would be a more regular practice for most R users. I am currently
considering passing all the above information with a single formula 
of the

form:



q | p | subject | time | rho ~ p + x + y | p + w + y | z + y



where subject and time are the identifiers, and rho indicates whether
correlated or independent shocks should be used.



I am unaware of other packages that use formulas in this way (for 
instance,

passing the identifiers in the formula), and I wonder if this would go
against any good practices. Would it be better to exclude some of the
necessary elements for constructing the model? This might make the 
resuting
formulas more similar to those of models with multiple responses or 
multiple
parts. I am not sure, though, how one would use such model formulas 
without
all the relevant information. Is there any suggested design 
alternative that

I could check?



I would appreciate any suggestions and discussion!



Kind regards,

Pantelis


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=04%7C01%7Crmh%40temple.edu%7C21a51d63bc6242e5e24908d989d84fce%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637692385020500219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=UKazmoIzXSn8DDQY3diUTPmVIg1cfTI3e1roXyo2DMQ%3Dreserved=0 



__
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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics 

Re: [R-pkg-devel] Internet resources and Errors

[Ben Bolker]

  I think you're not supposed to stop().

  You should just proceed with the other tests (skipping any 
tests/examples that depend on access to the inaccessible internet 
resources, or values derived from the failing call, to work)


  Does that help?

On 9/24/21 10:49 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:

Hi All:

I am getting dinged again on CRAN  (just Solaris for some reason),  and the 
problem is how to exit if there is a failure of accessing the resource,  I know 
it has been discussed here before,  but I just am not understanding what is 
desired to end properly. As I have been reminded:

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

All internet calls are wrapped in 'try()'.  If that shows an error,  I  write a 
message to the screen about the error,  and call stop(), perhaps with a further 
message in that call.   Somehow this does not appear to meet the standard.
Can someone then please tell me what I should do instead.  The point is I have 
checked that the access to the internet resources has worked,  i have seen that 
it hasn't,  now what should be the steps to take to exit gracefully.

I also want to add to what others have said about the frustrations of dealing 
with Solaris.  I have spent a fair amount of time getting things to  work with 
Solaris which no one uses.  In this instance the package test is only failing 
on Solaris.   Not a good use of limited time IMO.

Thanks for any advice.

-Roy



**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] Solaris segfaults

[Ben Bolker]

 I think I got confused by the fact that the second line of

https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
is "Solaris 10 on ix64/x64".

  I interpreted that as "64-bit Solaris".  On the other hand the rest 
of the information in that file says that the default ODS compiler used 
is a 32-bit build; it doesn't say anything about the build of the 
alternative gcc compiler (which is used for packages with Rcpp etc.) 
Other comments farther down in the file (about versions of Java, 
protobuf used) do suggest that the system is indeed 32-bit.


 If the CRAN Solaris platform is indeed 32-bit, then I really have no 
idea why checks are failing on CRAN but succeeding on r-hub (but I also 
feel better about not trying to fix it ...)


  I do appreciate the provision of the resources for setting up a 
virtual Solaris box - I don't recall exactly what hurdle I encountered 
last time I tried, it was probably some weird idiosyncratic thing.


  For the record I haven't tried valgrind recently, but the CRAN 
versions of the valgrind tests weren't throwing any errors ... 
https://cran.r-project.org/web/checks/check_issue_kinds.html


  thanks
   Ben Bolker


On 9/15/21 2:19 AM, Gábor Csárdi wrote:

Hi Ben,

According to https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
CRAN's Solaris is also 32 bit.
But maybe I am missing something?

You can download a Solaris VM (for Virtualbox or VMware) from
https://files.r-hub.io/solaris/
It has both 32 bit and 64 bit R (with gcc) and ODS R as well. You can
update R on it like this:
https://github.com/r-hub/solarischeck/tree/master/packer#updating-r

Best,
Gabor

On Wed, Sep 15, 2021 at 1:51 AM Ben Bolker  wrote:


I may have asked something like this before, but ...

The glmmTMB package is currently segfaulting (on the very first example)
on its CRAN Solaris checks
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html


  > ## Comparing variance-covariance matrix with manual computation
  > data("sleepstudy",package="lme4")
  > fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)

   *** caught segfault ***
address 4539ec45, cause 'memory not mapped'
---



   We have to submit a new version to CRAN soon; we will most likely beg
the CRAN maintainers' indulgence for having it fail on Solaris, but it
would be nice to fix it if we can.

 The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because
the package uses Rcpp.

The package builds/checks fine on the r-hub `solaris-x86-patched`
platform, which is identical as far as I can tell **except** 32-bit
rather than 64-bit.

Short of installing 64-bit Solaris in a VM (which I have not done yet
because of random compatibility/command-line bullshittery that put me
off), does anyone have any wisdom to share for diagnosing and/or
guessing what the problem is?

Here are some links to similar errors, none of them seem terribly
useful/relevant.

https://github.com/gagolews/stringi/issues/94
https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html

glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen,
CppAD, TMB) - the problem could be somewhere in there (the TMB package
runs no tests and very few examples on CRAN, so there could be problems
there that only get flagged when we try glmmTMB examples).

More discussion at
   https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings)
if anyone is interested.

cheers
 Ben Bolker

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

[R-pkg-devel] Solaris segfaults

[Ben Bolker]

  I may have asked something like this before, but ...

The glmmTMB package is currently segfaulting (on the very first example) 
on its CRAN Solaris checks

https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html


> ## Comparing variance-covariance matrix with manual computation
> data("sleepstudy",package="lme4")
> fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)

 *** caught segfault ***
address 4539ec45, cause 'memory not mapped'
---



 We have to submit a new version to CRAN soon; we will most likely beg 
the CRAN maintainers' indulgence for having it fail on Solaris, but it 
would be nice to fix it if we can.


   The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because 
the package uses Rcpp.


  The package builds/checks fine on the r-hub `solaris-x86-patched` 
platform, which is identical as far as I can tell **except** 32-bit 
rather than 64-bit.


  Short of installing 64-bit Solaris in a VM (which I have not done yet 
because of random compatibility/command-line bullshittery that put me 
off), does anyone have any wisdom to share for diagnosing and/or 
guessing what the problem is?


  Here are some links to similar errors, none of them seem terribly 
useful/relevant.


https://github.com/gagolews/stringi/issues/94
https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html

  glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen, 
CppAD, TMB) - the problem could be somewhere in there (the TMB package 
runs no tests and very few examples on CRAN, so there could be problems 
there that only get flagged when we try glmmTMB examples).


More discussion at
 https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings) 
if anyone is interested.


  cheers
   Ben Bolker

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

Re: [Rd] Question about quantile fuzz and GPL license

[Ben Bolker]

On 9/14/21 9:22 AM, Abel AOUN wrote:

Hello,

I'm currently working on Python numpy package to develop linear interpolation 
methods for quantiles.
Currently, numpy only support the type 7 of Hyndman & Fan and I did the 
implementation for the 8 other methods to do as much as R ::quantile.

As you may guess, I was inspired by R implementation as well as other sources, 
which lead to my questions:

About fuzz (see first reference below for the source code),
fuzz <- 4 * .Machine $ double.eps
I think I understand why the machine epsilon is used to correct some edge cases 
where the float comparisons would fail.
However I don't get why epsilon is multiplied by 4 instead of simply using 
epsilon.
Is there someone who can explain this 4 ?


No, but doing a bit of archaeology

https://github.com/wch/r-source/blame/trunk/src/library/stats/R/quantile.R

  give the commit message for these lines as "add (modified) version of 
quantile.default from Rob Hyndman (17 years ago)".  This commit was made 
by Brian Ripley.


  However, the code from Rob Hyndman here:

https://stat.ethz.ch/pipermail/r-devel/2004-July/030204.html

  does **not** have the lines with the fuzz.  So my guess would be that 
Brian Ripley is the author of that particular bit of code.


  I can't say, myself, what the logic behind 4 * .Machine$double.eps is ...




About licence,
Numpy is under license BSD and R is on GPL.
The only thing I really cherry picked and rewrote for numpy is the fuzz part.
I'm quite new to open source development. We are wondering if doing this breaks 
the license GPL and if I can credit the original authors.
Plus, I'm not quite sure this is the right place to ask this, if not, sorry for 
the noise.
The relevant discussion on numpy PR is here: [ 
https://github.com/numpy/numpy/pull/19857#discussion_r706019184 | 
https://github.com/numpy/numpy/pull/19857#discussion_r706019184 ]


Thank you for your time.

Regards,
Abel Aoun


References:
The source code for R::quantile (fuzz is at line 82) [ 
https://github.com/wch/r-source/blob/79298c499218846d14500255efd622b5021c10ec/src/library/stats/R/quantile.R
 | 
https://github.com/wch/r-source/blob/79298c499218846d14500255efd622b5021c10ec/src/library/stats/R/quantile.R
 ] [ https://github.com/numpy/numpy/pull/19857 ]
R doc for quantile : [ 
https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile | 
https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile ]
The ongoing PR on numpy: [ https://github.com/numpy/numpy/pull/19857 | 
https://github.com/numpy/numpy/pull/19857 ]



[[alternative HTML version deleted]]

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] (no subject)

[Ben Bolker]

  You can go to the URL that is at the bottom of every message from 
this list <https://stat.ethz.ch/mailman/listinfo/r-package-devel> and 
search for "unsubscribe" in the page ...


On 9/3/21 1:13 PM, Krishan Gupta wrote:

Please please stop sending emil to me. i want to not recieve more mails.

*Best regards,*

*Krishan Gupta*
*PhD scholar, the Sengupta Laboratory*

[[alternative HTML version deleted]]

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


  cheers
   Ben Bolker

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

Re: [Rd] Issues with drop.terms

[Ben Bolker]

  Small follow-up: (1) in order for lm() to actually work you need 
keep.response=TRUE in the drop.terms() call (I realize that this is 
*not* the problem in your example)


test4 <- terms(mpg ~ hp + I(cyl==4) + disp + wt )
check4 <- drop.terms(test4, 3, keep.response = TRUE)
formula(check4)
lm( check4, data=mtcars)

(2) I'm ambivalent about your "We can argue that the user should have 
used I(cyl==4), but very many won't." argument. This is the ever-present 
"document precisely and require users to know and follow the 
documentation" vs. "try to protect users from themselves" debate - 
taking either side to an extreme is (IMO) unproductive. I don't know how 
hard it would be to make drop.terms() **not** drop parentheses, but it 
seems like it may be very hard/low-level. My vote would be to see if 
there is a reasonably robust way to detect these constructions and 
**warn** about them.


  I have probably asked about this before, but if anyone knows of 
useful materials that go into more details about the definitions and 
implementation of model matrix/terms/etc. machinery, *beyond* the 
appropriate chapter of "Statistical Models in S" (Becker/Chambers white 
book), *or* the source code itself, I would love some pointers ...


 Ben Bolker


On 8/23/21 10:36 AM, Therneau, Terry M., Ph.D. via R-devel wrote:

This is a follow-up to my earlier note on [.terms.   Based on a couple days' 
work getting
the survival package to work around  issues, this will hopefully be more 
concise and
better expressed than the prior note.

1.
test1 <- terms( y ~ x1:x2 + x3)
check <- drop.terms(termobj =test1, dropx = 1)
formula(check)
## ~x1:x2

The documentation for the dropx argument is "vector of positions of variables 
to drop from
the right hand side of the model", but it is not clear what "positions" is.   I 
originally
assumed "the order in the formula as typed", but was wrong.   I suggest adding 
a line
"Position refers to the order of terms in the term.labels attribute of the 
terms object,
which is also the order they will appear in a coefficient vector (not counting 
the
intercept).

2.
library(splines)
test2 <- terms(model.frame(mpg ~  offset(cyl) + ns(hp, df=3) + disp + wt, 
data=mtcars))
check2 <- drop.terms(test2,  dropx = 2)
formula(check2)
## ~ns(hp, df=3) + wt

One side effect of how drop.terms is implemented, and one that I suspect was 
not intended,
is that offsets are completly ignored.    The above drops both the offset and 
the disp
term from the formula   The dataClasses and predvars attributes of the result 
are also
incorrect: they have lost the ns() term rather than the disp term;
the results of predict will be incorrect.

attr(check2, "predvars")
##    list(offset(cyl), disp, wt)

Question: should the function be updated to not drop offsets? If not a line 
needs to be
added to the help file.   The handling of predvars needs to be fixed regardless.

3.
test3 <- terms(mpg ~ hp + (cyl==4) + disp + wt )
check3 <- drop.terms(test3, 3)
formula(check3)
lm( check3, data=mtcars)   # fails

The drop.terms action has lost the () around the logical expression, which 
leads to an
invalid formula.  We can argue that the user should have used I(cyc==4), but 
very many won't.

4. As a footnote, more confusion (for me) is generated by the fact that the 
"specials"
attribute of a formula does not use the numbering discussed in 1 above.   I had 
solved
this issue long ago in the untangle.specials function; long enough ago that I 
forgot I had
solved it, and just wasted a day rediscovering that fact.

---

I can create a patch for 1 and 2 (once we answer my question), but a fix for 3 
is not
clear to me.  It currently leads to failure in a coxph call that includes a 
strata so I am
directly interested in a solution; e.g.,  coxph(Surv(time, status) ~ age + 
(ph.ecog==2) +
strata(inst), data=lung)

Terry T



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] Solaris Support

[Ben Bolker]

  I think you're stuck with what you get as far as compilers go (see 
below), but it shouldn't be a deal-breaker for CRAN.


The list of CRAN test platforms 
<https://cran.r-project.org/web/checks/check_flavors.html> indicates 
that the platform uses the Oracle Developer Studio 12.6 compiler , but 
the DETAILS 
<https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86> say 
"GCC is used for packages linking to Rcpp|cpp11|StanHeaders, rgdal/sf 
(GDAL is only compilable with g++) and about 40 others."


  So if you link to one of those packages or the undisclosed 40 others, 
you will get GCC (details below).  If not, or if you're not sure, you 
should indicate in your submission message that your package only works 
with GCC on Solaris. According to the CRAN policies 
<https://cran.r-project.org/web/packages/policies.html>


Package authors should make all reasonable efforts to provide 
cross-platform portable code. Packages will not normally be accepted 
that do not run on at least two of the major R platforms. [I believe 
"the major R platforms" means {MacOS, Windows, Linux} but I don't think? 
this is explicitly defined anywhere.]


  So, at least as far as publicly viewable policies go, the CRAN 
maintainers would be able to ask you to make "all reasonable efforts". 
(In my opinion, figuring out how to make your package work properly with 
ODS 12.6 would take more than a "reasonable" effort, but .. ???)


  cheers
   Ben Bolker



=
Where these compilers cannot be used, use
GCC 5.2.0 from OpenCSW, with config.site:
CC="/opt/csw//bin/gcc"
CFLAGS=-O2
CPPFLAGS="-I/opt/csw/include -I/usr/local/include"
FC="/opt/csw//bin/gfortran"
FFLAGS=-O2
CXX="/opt/csw//bin/g++"
CXXFLAGS=-O2
LDFLAGS="-L/opt/csw/lib -L/usr/local/lib"
R_LD_LIBRARY_PATH="/usr/local/lib:/opt/csw/lib:/home/ripley/developerstudio12.6/lib:/usr/openwin/lib"




On 8/23/21 3:31 PM, Reed A. Cartwright wrote:

What is the proper way to indicate that a package submitted to CRAN
requires the gcc compiler on Solaris? I haven't been able to find any
information about how to indicate that in a way that the CRAN builders will
pick up on it.

--
Reed A. Cartwright, PhD
Associate Professor of Genomics, Evolution, and Bioinformatics
School of Life Sciences and The Biodesign Institute
Arizona State University
==
Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA
Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
85287-5301 USA
Office: Biodesign B-220C, 1-480-965-9949
Website: http://cartwrig.ht/

[[alternative HTML version deleted]]

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] Expired Incoming Package

[Ben Bolker]

  That would be my best guess.

On 8/23/21 3:19 PM, Reed A. Cartwright wrote:

If my submission is no longer visible using foghorn::cran_incoming(), that
means it has expired and I should resubmit, right?

--
Reed A. Cartwright, PhD
Associate Professor of Genomics, Evolution, and Bioinformatics
School of Life Sciences and The Biodesign Institute
Arizona State University
==
Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA
Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
85287-5301 USA
Office: Biodesign B-220C, 1-480-965-9949
Website: http://cartwrig.ht/

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

[R-pkg-devel] advice on reminders/nags to CRAN maintainers

[Ben Bolker]

  Wondering about etiquette/if I should start over again with a package 
submission. tl;dr, the package has been 'waiting' since 30 July (I 
responded the same day to the queries that were sent).


  For what it's worth, the 'pretest-waiting-recheck' message below was 
sent from *a* CRAN maintainer, but hitting "reply-all" in my mail client 
only included the "cran-submissi...@-rproject.org" address. Maybe my 
mail client is misconfigured → supposed to respond to the sender as well 
as the Reply-To: address? I could poke the individual CM who sent it 
personally, but I'm loath to do that unnecessarily ...



   thoughts?
   Ben Bolker

---

(Some previous history omitted here for brevity; there had been a bit of 
back-and-forth about this package previously.)


  07/30: Submitted version 1.1.2.2 of the glmmTMB package.  Got a 
"pretest-waiting-recheck" message asking us to confirm that we had 
addressed issues; I responded the same day.


  08/04, 08/06: Tried to confirm that the message was received (maybe I 
was too pushy?) -- no answer that I have seen.


  The CRAN queue in general seems to be moving OK 
(foghorn::cran_incoming(), 'archive' folder filtered out, sorted by 
time: 57 total, 45 from today or yesterday).


   package  versioncran_folder time
   
 1 BIRDS0.2.1  pending 2021-07-21 17:01:00
 2 glmmTMB  1.1.2.2waiting 2021-07-30 20:29:00
 3 PEcAn.logger 1.8.0  waiting 2021-08-05 18:58:00
 4 IPDFileCheck 0.7.4  waiting 2021-08-06 11:15:00
 5 R6   2.5.1  waiting 2021-08-06 22:27:00
 6 ibdreg   0.3.3  pending 2021-08-06 23:41:00
 7 mark 0.2.0  waiting 2021-08-08 23:25:00
 8 DataGraph1.2.3  pending 2021-08-09 03:11:00
 9 tibble   3.1.4  waiting 2021-08-09 05:46:00

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

Re: [Rd] Feature request: Change default library path on Windows

[Ben Bolker]

  Given (AFAICS) the absence of any actual R-core members 
<https://www.r-project.org/contributors.html> chiming into the 
discussion here, and provided that you think that the issue has been 
sufficiently discussed, I would say the next step ("how to go about 
making the change") is to compose & submit a wishlist request to the R 
bug tracker ...
  It might also be worth reaching out to/double-checking with Jeroen 
Ooms (Rtools maintainer and Windows infrastructure expert; I don't know 
if he has any more formal association with R-core/CRAN ?)


  cheers
   Ben Bolker


On 7/25/21 6:35 PM, Steve Haroz wrote:

So I would say that I still believe Microsoft doesn't give clear
guidance for this.


Sure, there is some ambiguity on where MS would prefer these kinds of
files. But what is clear is that the current location USER/Documents
is causing a serious issue.

And while we can all understand frustration with Microsoft, Windows
users represent a major proportion of the R install base. So let's see
what we can do to help out those users. Changing the default location
to either USER/R or USER/AppData/Local/R would help a lot of users,
both beginners and those with moderate experience who switch to a new
cloud backup.

Microsoft is unlikely to put out new guidance any time soon. And the
current guidance doesn't seem opposed to putting R libraries in either
suggested location. So how about we just pick one (I suggest USER/R
for simplicity) and discuss how to go about making the change?

-Steve

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



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

Re: [R-pkg-devel] Using parallel:::sendMaster despite warnings

[Ben Bolker]

  Patches to parallel could certainly be *considered*, but people will 
probably want to argue about the details quite a bit.  I would suggest 
presenting/discussing your ideas for modification on r-devel before 
posting them as a 'wishlist' item to the R bug tracker. (If an R-core 
member participates in the discussion on r-devel and is convinced of the 
utility and harmlessness of your modifications the last step might be 
unnecessary).


  cheers
   Ben Bolker


On 7/23/21 1:17 PM, David Norris wrote:

My understanding about this issue with progressr is that it is nontrivial, and will 
take author Henrik Bengtsson some time & thought to resolve.
OTOH if patches to 'parallel' were welcome, I could embed my solution in a 
modified version of parallel::mclapply by introducing 1 or 2 new parameters 
(e.g., mc.prog=NULL) to support progress reporting consistently with the 
existing interface.

From: Duncan Murdoch 
Date: Friday, July 23, 2021 at 11:26 AM
To: Hugh Parsonage , David Norris 

Cc: "r-package-devel@r-project.org" 
Subject: Re: [R-pkg-devel] Using parallel:::sendMaster  despite warnings

On 23/07/2021 10:59 a.m., Hugh Parsonage wrote:
Happily, package parallel is open-source. If you would like to make
use of the unexported functions, you could copy the source code with
acknowledgement into your package.

There's a good chance that wouldn't work, because parallel is a base
package.  Base packages can work with R internals and user-written
packages can't.

Probably David's best course of action is to submit patches where
necessary so that he doesn't need ::: access.  The original motivation
appeared to be avoiding inefficiency in a contributed package; if
there's a patch that can fix that, it could be available in a few days.
   If it needs changes to the parallel package (e.g. exposing functions
that are currently internal), that will take much longer, and needs a
strong argument why the current API isn't sufficient.

Alternatively, he can go ahead and use :::, but just not expect his
package to be on CRAN.  There are other ways to distribute packages.

Duncan Murdoch

   Naturally this might be a lot of
work and risks different behaviour between your package and parallel,
but neither might be that terrible for you.  And certainly would be
better than trying to pretend that the functions you want are exported
from parallel.



On Fri, 23 Jul 2021 at 23:09, David Norris <mailto:da...@precisionmethods.guru> 
wrote:

I can confirm that getFromNamespace() does indeed circumvent the WARNING.
I might otherwise prefer ':::', however, for making its 'bad intentions' so 
clear.
I was very much aware of the cautionary language under `?readChild`, but 
wondered whether *in practice* more liberal community policies might be in 
force pending the maturation of the futureverse.
Although the sparse history of the relevant file hardly supports 
"might-break-at-any-time" alarmism, I do note that the last commit (in May 
2020) introduced an argument sendMaster(raw.asis=TRUE) that I am actually using.
https://github.com/wch/r-source/commits/trunk/src/library/parallel/R/unix/mcfork.R

(Also agree with Yohann that ideally one might support Windows with a warning 
such as data.table issues regarding my Mac's non-support for OpenMP.)

Best, David

From: Sebastian Meyer <mailto:seb.me...@fau.de>
Organization: Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
Date: Friday, July 23, 2021 at 8:05 AM
To: David Norris <mailto:da...@precisionmethods.guru>, 
"mailto:r-package-devel@r-project.org; <mailto:r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] Using parallel:::sendMaster  despite warnings

Am 23.07.21 um 13:19 schrieb David Norris:
Because parallelized progress reporting in the futureverse.org incurs latencies 
too great for my application 
(https://github.com/HenrikBengtsson/progressr/issues/118), I have found it 
necessary to implement my own progress reporting using some of the non-exported 
functionality from `parallel`. (I do appreciate that Windows lacks the fork() 
system call, and will not support this. But am willing to make this an OS_type: 
unix-only package.)

Of course, I get a WARNING for this:

── R CMD check results  precautionary 0.2.6 
Duration: 6m 41.8s

❯ checking dependencies in R code ... WARNING
   Unexported objects imported by ':::' calls:
 ‘parallel:::readChild’ ‘parallel:::selectChildren’
 ‘parallel:::sendMaster’
 See the note in ?`:::` about the use of this operator.
 Including base/recommended package(s):
 ‘parallel’

Is this warning an absolute deal-killer on CRAN? Is there a 'correct' way to do 
`:::` that avoids the warning altogether?

The 'parallel' functions your package intends to access seem to be
intentionally unexported. Their help page says: "They are not available
on Windows, and not exported from the namespace&quo

Re: [R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Ben Bolker]

  Thanks very much.  In the end I gave up and removed the offending
LaTeX files, as the goal of this was to get the package to build on
r-hub's Fedora platform, and it seems more promising to work with the
r-hub folks to get a sufficiently complete LaTeX installation
available there (as the required files seem to be present on every
_other_ Linux platform I've tried). (For future readers/references,
the  huxtable package is driving these requirements.)

  cheers
   Ben Bolker

On Thu, Jul 15, 2021 at 9:49 PM Hadley Wickham  wrote:
>
> On Wed, Jul 14, 2021 at 9:11 AM Ben Bolker  wrote:
> >
> >
> >In the process of trying to get a package to build successfully on
> > r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files
> > to the vignette directory.  One of these was collectbox.sty, which
> > triggers the NOTE
> >
> > ---
> > NOTE
> > The following files contain a license that requires
> > distribution of original sources:
> >‘collectbox.sty’
> > ---
> >
> >The licensing/copyright information in collectbox.sty is as follows:
> >
> >
> > %% The original source files were:
> > %%
> > %% collectbox.dtx  (with options: `collectbox.sty')
> > %%
> > %% IMPORTANT NOTICE:
> > %%
> > %% For the copyright see the source file.
> > %%
> > %% Any modified versions of this file must be renamed
> > %% with new filenames distinct from collectbox.sty.
> > %%
> > %% For distribution of the original source see the terms
> > %% for copying and modification in the file collectbox.dtx.
> > %%
> > %% This generated file may be distributed as long as the
> > %% original source files, as listed above, are part of the
> > %% same distribution. (The sources need not necessarily be
> > %% in the same archive or directory.)
> > %% Copyright (C) 2012 by Martin Scharrer 
> > %% 
> > %% This work may be distributed and/or modified under the
> > %% conditions of the LaTeX Project Public License, either version 1.3
> > %% of this license or (at your option) any later version.
> > %% The latest version of this license is in
> > %%   http://www.latex-project.org/lppl.txt
> > %% and version 1.3 or later is part of all distributions of LaTeX
> > %% version 2005/12/01 or later.
> >
> > So I put collectbox.dtx into the inst/misc directory in the package.
> > Fine.
> >
> >   Now, what do I need to do to (1) make sure that my DESCRIPTION file is
> > correct and (2) hopefully, suppress the NOTE so I don't have to explain
> > it to the CRAN maintainers every time?
> >
> > * Do I change the LICENCE line (which is currently AGPL-3)? According to
> > https://cran.r-project.org/doc/manuals/R-exts.html#Licensing it would
> > seem I would have to switch to "file LICENCE" (adding a
> > "Licence_is_FOSS: yes"), where "LICENCE" contains something like
> >
> > package code licensed under AGPL-3; file vignettes/collectbox.sty is
> > under the LaTeX Project Public License (source provided in
> > misc/collectbox.dtx)
> >
> > ? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?
> >
> > * Do I just include the files without comment, since I have complied (as
> > far as I can tell) with the terms of the LPPL?
>
> It's my understanding that the goal of the license field is to list
> one license that the entire package can be distributed under (i.e. is
> compatible with all licenses in the package). As long as you believe
> that LPPL is compatible with the AGPL-3, then it's fine to keep the
> license as AGPL-3.
>
> I don't believe it would be correct to use "AGPL-3 + file LICENSE` as
> R-exts only lists three uses of file LICENSE, none of which apply to
> your case:
>
> > If a package license restricts a base license (where permitted, e.g., using 
> > GPL-3 or AGPL-3 with an
> > attribution clause), the additional terms should be placed in file LICENSE 
> > (or LICENCE), and the
> > string ‘+ file LICENSE’ (or ‘+ file LICENCE’, respectively) should be 
> > appended to the corresponding
> > individual license specification.
>
> > The optional file LICENSE/LICENCE contains a copy of the license of the 
> > package...
> > Whereas you should feel free to include a license file in your source 
> > distribution, please do not arrange to
> install yet another copy of the GNU COPYING or COPYING.LIB files ...
> > Since files named LICENSE or LICENCE will be installed, do not use these 
> > names for stan

Re: [R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Ben Bolker]

  AGPL was chosen by my colleagues.  I'll pass on the information.

On 7/13/21 6:40 PM, Steven Scott wrote:
I'll let others discuss the technical details of how to set up the 
licence files.  I want to make sure you know that using AGPL is a good 
way to ensure that nobody in tech uses your package.  Maybe that's 
intended, but when I was at Google the ONLY software we were 
specifically prohibited from using was code released under AGPL. I won't 
try to convince you of that being a good or bad thing, but wanted to 
make sure you were aware of it.


On Tue, Jul 13, 2021 at 2:11 PM Ben Bolker <mailto:bbol...@gmail.com>> wrote:



    In the process of trying to get a package to build successfully on
r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files
to the vignette directory.  One of these was collectbox.sty, which
triggers the NOTE

---
NOTE
The following files contain a license that requires
distribution of original sources:
    ‘collectbox.sty’
---

    The licensing/copyright information in collectbox.sty is as follows:


%% The original source files were:
%%
%% collectbox.dtx  (with options: `collectbox.sty')
%%
%% IMPORTANT NOTICE:
%%
%% For the copyright see the source file.
%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from collectbox.sty.
%%
%% For distribution of the original source see the terms
%% for copying and modification in the file collectbox.dtx.
%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
%% in the same archive or directory.)
%% Copyright (C) 2012 by Martin Scharrer mailto:mar...@scharrer-online.de>>
%% 
%% This work may be distributed and/or modified under the
%% conditions of the LaTeX Project Public License, either version 1.3
%% of this license or (at your option) any later version.
%% The latest version of this license is in
%% http://www.latex-project.org/lppl.txt
<http://www.latex-project.org/lppl.txt>
%% and version 1.3 or later is part of all distributions of LaTeX
%% version 2005/12/01 or later.

     So I put collectbox.dtx into the inst/misc directory in the
package.
Fine.

   Now, what do I need to do to (1) make sure that my DESCRIPTION
file is
correct and (2) hopefully, suppress the NOTE so I don't have to explain
it to the CRAN maintainers every time?

* Do I change the LICENCE line (which is currently AGPL-3)?
According to
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing
<https://cran.r-project.org/doc/manuals/R-exts.html#Licensing> it would
seem I would have to switch to "file LICENCE" (adding a
"Licence_is_FOSS: yes"), where "LICENCE" contains something like

package code licensed under AGPL-3; file vignettes/collectbox.sty is
under the LaTeX Project Public License (source provided in
misc/collectbox.dtx)

? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?

* Do I just include the files without comment, since I have complied
(as
far as I can tell) with the terms of the LPPL?

* Is there a way to signal to R CMD check that I *have* complied with
the terms?

    cheers
     Ben Bolker

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

[R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Ben Bolker]

  In the process of trying to get a package to build successfully on 
r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files 
to the vignette directory.  One of these was collectbox.sty, which 
triggers the NOTE


---
NOTE
The following files contain a license that requires
distribution of original sources:
  ‘collectbox.sty’
---

  The licensing/copyright information in collectbox.sty is as follows:


%% The original source files were:
%%
%% collectbox.dtx  (with options: `collectbox.sty')
%%
%% IMPORTANT NOTICE:
%%
%% For the copyright see the source file.
%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from collectbox.sty.
%%
%% For distribution of the original source see the terms
%% for copying and modification in the file collectbox.dtx.
%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
%% in the same archive or directory.)
%% Copyright (C) 2012 by Martin Scharrer 
%% 
%% This work may be distributed and/or modified under the
%% conditions of the LaTeX Project Public License, either version 1.3
%% of this license or (at your option) any later version.
%% The latest version of this license is in
%%   http://www.latex-project.org/lppl.txt
%% and version 1.3 or later is part of all distributions of LaTeX
%% version 2005/12/01 or later.

   So I put collectbox.dtx into the inst/misc directory in the package. 
Fine.


 Now, what do I need to do to (1) make sure that my DESCRIPTION file is 
correct and (2) hopefully, suppress the NOTE so I don't have to explain 
it to the CRAN maintainers every time?


* Do I change the LICENCE line (which is currently AGPL-3)? According to 
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing it would 
seem I would have to switch to "file LICENCE" (adding a 
"Licence_is_FOSS: yes"), where "LICENCE" contains something like


package code licensed under AGPL-3; file vignettes/collectbox.sty is 
under the LaTeX Project Public License (source provided in 
misc/collectbox.dtx)


? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?

* Do I just include the files without comment, since I have complied (as 
far as I can tell) with the terms of the LPPL?


* Is there a way to signal to R CMD check that I *have* complied with 
the terms?


  cheers
   Ben Bolker

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