Thank you for the PR, it’s really appreciated. That will save me hours.

Regarding the URL, there’s nothing I can do. The issue is known and the URLs are correct; the server is simply rejecting CRAN (and likely other bot-like requests).

As for SETLENGTH, this is not an issue. It appears because you ran R CMD check as-is. By default, the code is compiled with -DWITHSETLENGTH on GitHub and r-universe to preserve features that have been removed on CRAN. I’ve been submitting the package to CRAN without this feature for the past two years, since resizable vectors trigger issues. This part of the code is therefore not included on CRAN. I'm waiting better programmers to find a workaround (e.g. data.table team). The link you shared look like the first workable workaround I've seen in two years. Thank you.

Ok for the links it is now a 404. Different issue. The links were actually invalided.

Makes sense for SETLENGTH. I have not had a need to reduce vector size (apart from the obious 'copy-and-destroy-old-one') but like you I am aware that the data.table team insists it is key (because IIRC they start overallocating to speculatively save some cycles...).

Glad the PR worked for you. I once again learned something new about ALTREP.

Oh and by the way: You could generalize the nrow use. In a way downcasting to int was 'easier' as we do not need to differentiate between R-devel and R-release but you could make the size variable R_xlen_t too in order to accommodate larger size. Which may be very rare but now we can...

BTW regarding that use of ALTREP_CLASS looks like things are simpler now. For the RSS feed of NEWS changes for R:

CHANGES IN R-devel C-LEVEL FACILITIES

• New functions ‘R_altrep_class_name’ and ‘R_altrep_class_package’ for retrieving the class name symbol and package name symbol of an ALTREP object. These should be used instead of ‘ALTREP_CLASS’.

• New function ‘R_getAttributes’ returns the same result as the R function ‘attributes’. New functions ‘R_getAttribCount’, ‘R_getAttribNames’, ‘R_hasAttrib’, ‘R_nrow’, and ‘R_ncol’.

Hi @Jean-Romain : I am hearning from @kurthornik that CRAN would really like an updated Rcpp package but this, as discussed here via this PR, would break over your package lidR. I am monitoring incoming/ at CRAN (my function ciw::ciw() aka makes that easy) and it is up to 97 packages now but yours it not yet part of it. Could you be of assistance here and upload it? Else I can ask CRAN to override. Many thanks!

I'll release today or tomorrow. Is everything ok in the current state on github?

Do you mean with Rcpp? Yes. It required one other package to change, it is also now in incoming. What is in the Rcpp repo will be 1.1.1 once @kurthornik and I dot all i-s and cross all t-s on URLs. Code will not change -- Rcpp 1.1.0.14 as committed will be the same as 1.1.1. A few purely cosmetic README and vignette and .bib changes in the air.

Thanks for the prompt update of lidR -- much appreciated.

sent on CRAN. Thanks

So it did not pass CRAN pretest on windows

* checking compiled code ... NOTE
File 'lidR/libs/x64/lidR.dll':
  Found non-API call to R: 'ATTRIB'

Compiled code should not call non-API entry points in R.

despite is passed on win-builder

That is me / that is us but it is circular (and "expected"):

• R-devel added this NOTE
• Rcpp adapted in December. But that Rcpp version is not yet on CRAN
• However they got tired of the note so in $CRAN/src/contrib/4.6.0/
  • we already had an interim Rcpp 1.1.0.8.1
  • this was needed because another (rushed) R-devel change broke compilation, this re-enabled it
  • they (not me) just added Rcpp 1.1.0.8.2 a day ago to suppress this very NOTE
• so it seems to have added this Rcpp 1.1.0.8.2 for Linux (i.e. Kurt) but not Windows (i.e. Uwe)

You can safely explain this away to them. It is just a NOTE. The note disappears once Rcpp 1.1.1 arrives. But in order to get Rcpp 1.1.1 onto CRAN we need the updated lidR to survive the change of return value from nrow() from int to R_xlen_t which upsets your std::min() in your CRAN version.

Makes sense?

PS Also 'NOTE' != 'WARNING', and is generally not a blocker. And it really isn't your code.

Ok I understand. So I replied to the CRAN. I hope it gonna pass with manual validation. I know that a NOTE is not a WARNING but usually a rejection is a rejection even with a NOTE. But the explantions sound strong 😄

Yes. I wrote a little helper package ciw (== CRAN Incoming Watcher) so that ciw::ciw() shows (quickly, easily) what is in the queue and lidR got moved to section 'archive/' which is puzzling. I hope this gets straightened out -- it also happens to some packages of mine (e.g. Rcpp has one old grandfathered exception but it still comes up each time -- sigh). That is to say: email to them should help explain it.

On its way on CRAN. Thanks

All good -- thanks so much for the prompt update!