Re: [R-pkg-devel] 'Default' macos (x86) download URL now gone?

[Dirk Eddelbuettel]

Simon,

On 24 April 2023 at 18:28, Simon Urbanek wrote:
| thanks - the problem is that there is not a single installer package (for 
several years now), so that URL is ambiguous. Whether the missing link is a 
good or bad depends on how it is used. I would argue that any link to that URL 
is inherently bad, because there is no way of knowing that the link works for a 
particular system - that's why I have originally removed it with the R 4.3.0 
release. I have restored it now, making it point to the R 4.3.0 arm64 release 
since that is arguably the closest to a single "latest R". R releases have not 
been stored in /bin/macosx since 2015, so anyone using a link there is asking 
for trouble.

Restoring it _but switching the architecture under it_ is another subtle way
to still break things where the expectation based on a decade+ of prior
practice was that this works:

   installer: Error - R 4.3.0 for macOS (ARM64) can’t be installed on this 
computer.
   Error: Process completed with exit code 1.

I long have repaired my (main) script in r-ci but this will likely surprise 
others.

| For any CI I would strongly recommend using the "last-success" links: 
https://mac.r-project.org/big-sur/last-success/ in particular the .xz versions 
are they are specifically designed to be used by CI (small download, fast and 
localized install).

That is a fine idea but no replacement as it leads to a need for a different
deployment and how / where to untar etc.

Maybe you are someone wants to wrap that into a suitable script or 'action
snippet' and document that?   I can't, I don't even have a mac.

Dirk

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

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

[R-pkg-devel] RFC: An ad-hoc "cluster" one can leave and rejoin later

[Ivan Krylov]

Hello R-package-devel members,

I've got an idea for a package. I'm definitely reinventing a wheel, but
I couldn't find anything that would fulfil 100% of my requirements.

I've got a computational experiment that takes a while to complete, but
the set of machines that can run it varies during the day. For example,
I can leave a computer running in my bedroom, but I'd rather turn it
off for the night. For now, I work around the problem with a lot of
caching [*], restarting the job with different cluster geometries and
letting it load the parts that are already done from the disk.

Here's a proof of concept implementation of a server that sits between
the clients and a pool of compute nodes, dynamically distributing the
tasks between the nodes: https://github.com/aitap/nodepool

In addition to letting nodes come and go as they like, it also doesn't
strain R's NCONNECTIONS limit on nodes and clients (although the pool
would still benefit from it being increased) and only requires the pool
to be available for inbound connections [**].

It's definitely not CRAN quality yet and at the very least needs a
better task submission API, but it does seem to work. Does it sound
like it could be useful in your own work? Any ideas I could implement,
besides those mentioned in the README?

Here's a terrible hack: the pool speaks R's cluster protocol. One
could, in theory, construct a mock-"cluster" object consisting of
connections to the pool server and use parLapplyLB to distribute a
number of tasks between the pool nodes. But that's a bad idea for a lot
of reasons.

-- 
Best regards,
Ivan

[*] I need caching anyway because some of my machines have hardware
problems and may just reboot for no reason.

[**] Although Henrik Bengtsson's excellent
parallelly::makeClusterPSOCK() makes it much less of a problem.

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

[R-pkg-devel] CRAN check fails on NEWS

[Gert van Valkenhoef]

Hi all,

I'm hoping you can help me understand this new CRAN check failure that 
occurs on Debian but not on Windows:

Debian:
Status: 1 NOTE

* checking package subdirectories ... NOTE
Problems with news in ‘NEWS’:
   Cannot process chunk/lines:
 smaa 0.3-0
   ... etc ...

This error was not raised by previous versions and I did not change the 
NEWS file for this version. The same package passes the same check on 
Debian r-devel on r-hub (see the full build log: HTML 
,
 
text 
,
 
artifacts 
.)

I couldn't find any documentation regarding this error or a clear 
specification of how NEWS should be formatted. I had understood it t be 
a plain text file.

Thanks in advance,

Gert

[[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] CRAN check fails on NEWS

[Ivan Krylov]

On Wed, 26 Apr 2023 20:38:36 +0200
Gert van Valkenhoef  wrote:

> I'm hoping you can help me understand this new CRAN check failure
> that occurs on Debian but not on Windows:

Unfortunately, not all checks are enabled on all check machines.

> * checking package subdirectories ... NOTE
> Problems with news in ‘NEWS’:
>Cannot process chunk/lines:
>  smaa 0.3-0
>... etc ...

Your NEWS file at
 looks like
valid Markdown to me. In fact, I can parse it using R's NEWS.md parser
without any warnings, so in order to solve the problem, you just need
to rename it to NEWS.md.

R's requirements for "plain text" NEWS files are documented in
help(news) (together with requirements for NEWS.md and NEWS.Rd).

> The same package passes the same check on  Debian r-devel on r-hub
> (see the full build log:
> HTML
> ,
>  

Are they running R CMD check without --as-cran? This could be the
reason why they didn't pick up this problem sooner. Running
rhub::check_for_cran() will run a more comprehensive set of checks on
your package.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] CRAN check fails on NEWS

[Henrik Bengtsson]

To reproduce this, you can use tools:::.news_reader_default(), e.g.

> utils::download.file("https://raw.githubusercontent.com/gertvv/rsmaa/master/smaa/NEWS";,
>  "NEWS", quiet = TRUE)
> news <- tools:::.news_reader_default("NEWS")
Warning messages:
1: Cannot process chunk/lines:
  smaa 0.3-0
2: Cannot process chunk/lines:
  smaa 0.2-5
...
9: Cannot process chunk/lines:
  smaa 0.1

You can check for attribute 'bad' to detect if there are parsing errors, e.g.

> bad <- which(attr(news, "bad"))
> news[bad, "Version"]
[1] "0.3-0" "0.2-5" "0.2-4" "0.2-3" "0.2-2" "0.2-1" "0.2"   "0.1-1" "0.1"

I have a check_news() [0] that does this job for me (it checks both
NEWS and NEWS.md), e.g.

> check_news("NEWS")
Error: Detected 9 malformed entries in 'NEWS': 0.3-0, 0.2-5, 0.2-4,
0.2-3, 0.2-2, 0.2-1, 0.2, 0.1-1, 0.1

Hope this helps,

/Henrik

[0] 
https://github.com/HenrikBengtsson/dotfiles-for-R/blob/master/Rprofile.d/interactive%3DTRUE/check_news.R

On Wed, Apr 26, 2023 at 12:32 PM Ivan Krylov  wrote:
>
> On Wed, 26 Apr 2023 20:38:36 +0200
> Gert van Valkenhoef  wrote:
>
> > I'm hoping you can help me understand this new CRAN check failure
> > that occurs on Debian but not on Windows:
>
> Unfortunately, not all checks are enabled on all check machines.
>
> > * checking package subdirectories ... NOTE
> > Problems with news in ‘NEWS’:
> >Cannot process chunk/lines:
> >  smaa 0.3-0
> >... etc ...
>
> Your NEWS file at
>  looks like
> valid Markdown to me. In fact, I can parse it using R's NEWS.md parser
> without any warnings, so in order to solve the problem, you just need
> to rename it to NEWS.md.
>
> R's requirements for "plain text" NEWS files are documented in
> help(news) (together with requirements for NEWS.md and NEWS.Rd).
>
> > The same package passes the same check on  Debian r-devel on r-hub
> > (see the full build log:
> > HTML
> > ,
>
> Are they running R CMD check without --as-cran? This could be the
> reason why they didn't pick up this problem sooner. Running
> rhub::check_for_cran() will run a more comprehensive set of checks on
> your package.
>
> --
> Best regards,
> Ivan
>
> __
> 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