Re: [R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?

[Friedemann von Lampe]

Thanks. Thankfully Ivan looked up the source package 
(https://github.com/fvlampe/goeveg) and his response previously on this 
list solved the problem for CRAN. I simply needed to change the argument 
from  'NUL' to NULL. The package was now successfully submitted.


However, in R-hub the NOTE remains, which apparently is is one of their 
problems.


Am 13.12.2023 um 15:55 schrieb Jeff Newmiller via R-package-devel:

Rhub is not CRAN. Please include a link to your source package if you want 
help. If there is actually a bug in Rhub then this NUL error may not reflect 
the response you will get from CRAN if and when you submit.

On December 13, 2023 12:58:41 AM PST, Friedemann von Lampe 
 wrote:

Hi,

when trying to update my package on CRAN it is rejected, because it gets a note 
during checks on Debian:

Flavor: r-devel-linux-x86_64-debian-gcc
Check: for non-standard things in the check directory, Result: NOTE
Found the following files/directories:
'NUL'

There is no such file in my folder and therefore it can't be removed. With 
Windows everything is OK.
As far as I understood, this is a problem with Rhub? 
(https://github.com/clessn/locateip/issues/99)

Or what can I do, to fix this problem and get my package update submitted to 
CRAN?

Thanks,
Friedemann von Lampe

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

[Henrik Bengtsson]

On Wed, Dec 13, 2023 at 8:06 AM McGrath, Justin M  wrote:
>
> On Windows, packages will be in "C:\Users\[User 
> Name]\Documents\R\win-library\[R version]\[Package Name]".

In R (>= 4.2.0), the default R_LIBS_USER path has moved to under
LOCALAPPDATA, e.g. "C:\Users\[User
Name]\AppData\Local\R\win-library\[R version]".  See
https://cran.r-project.org/bin/windows/base/rw-FAQ.html

FWIW, one workaround for too long paths on MS Windows is to map a long
path to a drive letter, e.g.

subst Y: 'C:/VeryLongPathToo/Users/JohnDoe/AppData/Local/R/'.

and then work with Y: instead of C:. We had to use that in some
projects with nested data folder structures. This approach is tedious,
and might require special permissions (not sure).

/Henrik

>
> With a 150 byte limit, that leaves 70 bytes for the user name, R version and 
> package name. That seems more than sufficient. If people are downloading the 
> source files, that also leaves plenty of space regardless where they choose 
> to extract the files.
>
> 
> From: Dirk Eddelbuettel 
> Sent: Wednesday, December 13, 2023 9:13 AM
> To: Tomas Kalibera
> Cc: Dirk Eddelbuettel; McGrath, Justin M; Ben Bolker; Martin Maechler; 
> r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length 
> limit be lifted?
>
>
> On 13 December 2023 at 16:02, Tomas Kalibera wrote:
> |
> | On 12/13/23 15:59, Dirk Eddelbuettel wrote:
> | > On 13 December 2023 at 15:32, Tomas Kalibera wrote:
> | > | Please don't forget about what has been correctly mentioned on this
> | > | thread already: there is essentially a 260 character limit on Windows
> | > | (see
> | > | 
> https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-NHAlEZQvY2kegkNVkuY3Lf84nKmMahrpZ4Euz2XXFDPvMWEcP28iepLlRiKzVZdAh752lyhHxd6zvk$
> | > | for more). Even if the relative path length limit for a CRAN package was
> | > | no longer regarded important for tar compatibility, it would still make
> | > | sense for compatibility with Windows. It may still be a good service to
> | > | your users if you keep renaming the files to fit into that limit.
> | >
> | > So can lift the limit from 100 char to 260 char ?
> |
> | The 260 char limit is for the full path. A package would be extracted in
> | some directory, possibly also with a rather long name.
>
> Call a cutoff number.
>
> Any move from '100' to '100 + N' for any nonzero N is a win. Pick one, and
> then commit the change.  N = 50 would be a great start as arbitrary as it is.
>
> 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-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?

[Jeff Newmiller via R-package-devel]

This is a narrow view of the world. As has been mentioned here by Tomas, the 
issue at this point is that a very widely-used operating system does not allow 
the absolute path to be longer than 254 characters unless users make 
possibly-breaking changes to their OS configuration. If a user is currently 
working in a directory with a path that is 150 characters long, and you try to 
un-tar a package there, it will work. If they are in a directory path that is 
170 characters long, then the un-tar will fail. They then have to do some 
research and discover that they have to share the total absolute path length 
with the package creators, and they become accustomed to working in directories 
with path length no longer than 154 characters.

Now you want to propose giving the entire path length budget plus 2 to the 
package developers. Not gonna happen. And Dirk wants 50 more characters. Then 
the user working at 150 characters tries to un-tar a package with paths 150 
characters long and 150 user plus 150 package gets you to 300 characters and 
what used to work for them stops working suddenly.

I think a package developer can figure out how to shorten their internal paths 
easier than thousands of users can restructure their historically useful 
directory structures or break their existing software. I vote no to both of 
these proposals.

Eventually, Microsoft is going to virtualize running old Windows APIs, and once 
people migrate away from the old API then this stupid problem will go away. But 
as it is we are stuck.

On December 13, 2023 7:27:42 AM PST, "McGrath, Justin M" 
 wrote:
>I'm not even asking for that. I'm asking for the decades old ustar 
>comparability, which is 255 characters, at most. In practice it is slightly 
>less than that. ustar is older than R itself. There is no one using R who 
>doesn't have ustar compatible tar.
>
>
>From: Dirk Eddelbuettel 
>Sent: Wednesday, December 13, 2023 8:59 AM
>To: Tomas Kalibera
>Cc: McGrath, Justin M; Ben Bolker; Martin Maechler; 
>r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel]  Wrong mailing list: Could the 100 byte path length 
>limit be lifted?
>
>
>On 13 December 2023 at 15:32, Tomas Kalibera wrote:
>| Please don't forget about what has been correctly mentioned on this
>| thread already: there is essentially a 260 character limit on Windows
>| (see
>| 
>https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-YZg5PVpulgNXCVfVklP442UG_0ofB8omMLlMq5dNadF9RP_6uofnrT6IbZpG1fpvjmAtLyAm1Y9rbc$
>| for more). Even if the relative path length limit for a CRAN package was
>| no longer regarded important for tar compatibility, it would still make
>| sense for compatibility with Windows. It may still be a good service to
>| your users if you keep renaming the files to fit into that limit.
>
>So can lift the limit from 100 char to 260 char ?
>
>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

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

[McGrath, Justin M]

On Windows, packages will be in "C:\Users\[User 
Name]\Documents\R\win-library\[R version]\[Package Name]".

With a 150 byte limit, that leaves 70 bytes for the user name, R version and 
package name. That seems more than sufficient. If people are downloading the 
source files, that also leaves plenty of space regardless where they choose to 
extract the files.


From: Dirk Eddelbuettel 
Sent: Wednesday, December 13, 2023 9:13 AM
To: Tomas Kalibera
Cc: Dirk Eddelbuettel; McGrath, Justin M; Ben Bolker; Martin Maechler; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length 
limit be lifted?


On 13 December 2023 at 16:02, Tomas Kalibera wrote:
|
| On 12/13/23 15:59, Dirk Eddelbuettel wrote:
| > On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| > | Please don't forget about what has been correctly mentioned on this
| > | thread already: there is essentially a 260 character limit on Windows
| > | (see
| > | 
https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-NHAlEZQvY2kegkNVkuY3Lf84nKmMahrpZ4Euz2XXFDPvMWEcP28iepLlRiKzVZdAh752lyhHxd6zvk$
| > | for more). Even if the relative path length limit for a CRAN package was
| > | no longer regarded important for tar compatibility, it would still make
| > | sense for compatibility with Windows. It may still be a good service to
| > | your users if you keep renaming the files to fit into that limit.
| >
| > So can lift the limit from 100 char to 260 char ?
|
| The 260 char limit is for the full path. A package would be extracted in
| some directory, possibly also with a rather long name.

Call a cutoff number.

Any move from '100' to '100 + N' for any nonzero N is a win. Pick one, and
then commit the change.  N = 50 would be a great start as arbitrary as it is.

Dirk

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

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

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

[McGrath, Justin M]

I'm not even asking for that. I'm asking for the decades old ustar 
comparability, which is 255 characters, at most. In practice it is slightly 
less than that. ustar is older than R itself. There is no one using R who 
doesn't have ustar compatible tar.


From: Dirk Eddelbuettel 
Sent: Wednesday, December 13, 2023 8:59 AM
To: Tomas Kalibera
Cc: McGrath, Justin M; Ben Bolker; Martin Maechler; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel]  Wrong mailing list: Could the 100 byte path length 
limit be lifted?


On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| Please don't forget about what has been correctly mentioned on this
| thread already: there is essentially a 260 character limit on Windows
| (see
| 
https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-YZg5PVpulgNXCVfVklP442UG_0ofB8omMLlMq5dNadF9RP_6uofnrT6IbZpG1fpvjmAtLyAm1Y9rbc$
| for more). Even if the relative path length limit for a CRAN package was
| no longer regarded important for tar compatibility, it would still make
| sense for compatibility with Windows. It may still be a good service to
| your users if you keep renaming the files to fit into that limit.

So can lift the limit from 100 char to 260 char ?

Dirk

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

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

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

[McGrath, Justin M]

The maximum path length supported by ustar is 255 bytes, and any path 
compatible with ustar is compatible with path limits for all file systems used 
by any operating system for the last several decades. Anything that is ustar 
compatible is compatible with all other requirements. There is no reason today 
to reject packages with ustar compatible paths that are not v7 compatible.

Best wishes,
Justin


From: Tomas Kalibera 
Sent: Wednesday, December 13, 2023 8:32 AM
To: McGrath, Justin M; Ben Bolker; Martin Maechler; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length 
limit be lifted?

On 12/13/23 14:56, McGrath, Justin M wrote:
>> 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’).
>
> R CMD check --as-cran gives a WARNING if a path is not ustar compatible, and 
> gives the same message as a NOTE if it is not v7 compatible.
>
> The path in the example below is ustar compatible, but not v7 compatible.
>
> ***
> * checking for portable file names ... NOTE
> Found the following non-portable file path:
>
> BioCro/inc/boost/numeric/odeint/stepper/generation/generation_controlled_adams_bashforth_moulton_really_long_file_name_one_two_three.hpp
>
> Tarballs are only required to store paths of up to 100 bytes and cannot
> store those of more than 256 bytes, with restrictions including to 100
> bytes for the final component.
> ***
>
> The code is in library/tools/R/check.R. An equivalent test is performed by R 
> CMD build in library/tools/utils/tar.R.
>
> AFAIK, CRAN rejects a package regardless whether the message is given as a 
> NOTE or a WARNING. ustar is 35 years old and is older than R itself, and thus 
> anyone using R in the last several decades will have ustar support. Any path 
> stored by ustar will be suitable for any common file system in use for the 
> last several decades. Overall, if a path is supported by ustar, there is no 
> reason to generate any message, even if that path is not v7 compatible. If 
> the NOTE about v7 incompatibility is still desired, then could CRAN not 
> reject packages for which the check reports a NOTE?

Please don't forget about what has been correctly mentioned on this
thread already: there is essentially a 260 character limit on Windows
(see
https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-9O1ZyZet_W6lAzZI0JZDI27SKTG6H4M4E5zB9xFItNpCD-I-eH2xmFxJ10uU1WAy1JNb4EiygQzkDsHkO1chmsk4TKd$
for more). Even if the relative path length limit for a CRAN package was
no longer regarded important for tar compatibility, it would still make
sense for compatibility with Windows. It may still be a good service to
your users if you keep renaming the files to fit into that limit.

Also please do not share private emails on the list.

Thanks
Tomas

>
> Best wishes,
> Justin
>
>
> _

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

[Dirk Eddelbuettel]

On 13 December 2023 at 16:02, Tomas Kalibera wrote:
| 
| On 12/13/23 15:59, Dirk Eddelbuettel wrote:
| > On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| > | Please don't forget about what has been correctly mentioned on this
| > | thread already: there is essentially a 260 character limit on Windows
| > | (see
| > | 
https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html
| > | for more). Even if the relative path length limit for a CRAN package was
| > | no longer regarded important for tar compatibility, it would still make
| > | sense for compatibility with Windows. It may still be a good service to
| > | your users if you keep renaming the files to fit into that limit.
| >
| > So can lift the limit from 100 char to 260 char ?
| 
| The 260 char limit is for the full path. A package would be extracted in 
| some directory, possibly also with a rather long name.

Call a cutoff number. 

Any move from '100' to '100 + N' for any nonzero N is a win. Pick one, and
then commit the change.  N = 50 would be a great start as arbitrary as it is.

Dirk

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

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

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

[Tomas Kalibera]

On 12/13/23 15:59, Dirk Eddelbuettel wrote:

On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| Please don't forget about what has been correctly mentioned on this
| thread already: there is essentially a 260 character limit on Windows
| (see
| https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html
| for more). Even if the relative path length limit for a CRAN package was
| no longer regarded important for tar compatibility, it would still make
| sense for compatibility with Windows. It may still be a good service to
| your users if you keep renaming the files to fit into that limit.

So can lift the limit from 100 char to 260 char ?


The 260 char limit is for the full path. A package would be extracted in 
some directory, possibly also with a rather long name.


Tomas



Dirk



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

[Dirk Eddelbuettel]

On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| Please don't forget about what has been correctly mentioned on this 
| thread already: there is essentially a 260 character limit on Windows 
| (see 
| https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html 
| for more). Even if the relative path length limit for a CRAN package was 
| no longer regarded important for tar compatibility, it would still make 
| sense for compatibility with Windows. It may still be a good service to 
| your users if you keep renaming the files to fit into that limit.

So can lift the limit from 100 char to 260 char ?

Dirk

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

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

Re: [R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?

[Jeff Newmiller via R-package-devel]

Rhub is not CRAN. Please include a link to your source package if you want 
help. If there is actually a bug in Rhub then this NUL error may not reflect 
the response you will get from CRAN if and when you submit.

On December 13, 2023 12:58:41 AM PST, Friedemann von Lampe 
 wrote:
>Hi,
>
>when trying to update my package on CRAN it is rejected, because it gets a 
>note during checks on Debian:
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: for non-standard things in the check directory, Result: NOTE
>Found the following files/directories:
>'NUL'
>
>There is no such file in my folder and therefore it can't be removed. With 
>Windows everything is OK.
>As far as I understood, this is a problem with Rhub? 
>(https://github.com/clessn/locateip/issues/99)
>
>Or what can I do, to fix this problem and get my package update submitted to 
>CRAN?
>
>Thanks,
>Friedemann von Lampe
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Tomas Kalibera]

On 12/13/23 14:56, McGrath, Justin M wrote:

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’).

R CMD check --as-cran gives a WARNING if a path is not ustar compatible, and 
gives the same message as a NOTE if it is not v7 compatible.

The path in the example below is ustar compatible, but not v7 compatible.

***
* checking for portable file names ... NOTE
Found the following non-portable file path:
   
BioCro/inc/boost/numeric/odeint/stepper/generation/generation_controlled_adams_bashforth_moulton_really_long_file_name_one_two_three.hpp

Tarballs are only required to store paths of up to 100 bytes and cannot
store those of more than 256 bytes, with restrictions including to 100
bytes for the final component.
***

The code is in library/tools/R/check.R. An equivalent test is performed by R 
CMD build in library/tools/utils/tar.R.

AFAIK, CRAN rejects a package regardless whether the message is given as a NOTE 
or a WARNING. ustar is 35 years old and is older than R itself, and thus anyone 
using R in the last several decades will have ustar support. Any path stored by 
ustar will be suitable for any common file system in use for the last several 
decades. Overall, if a path is supported by ustar, there is no reason to 
generate any message, even if that path is not v7 compatible. If the NOTE about 
v7 incompatibility is still desired, then could CRAN not reject packages for 
which the check reports a NOTE?


Please don't forget about what has been correctly mentioned on this 
thread already: there is essentially a 260 character limit on Windows 
(see 
https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html 
for more). Even if the relative path length limit for a CRAN package was 
no longer regarded important for tar compatibility, it would still make 
sense for compatibility with Windows. It may still be a good service to 
your users if you keep renaming the files to fit into that limit.


Also please do not share private emails on the list.

Thanks
Tomas



Best wishes,
Justin


_


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

[McGrath, Justin M]

> 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’).

R CMD check --as-cran gives a WARNING if a path is not ustar compatible, and 
gives the same message as a NOTE if it is not v7 compatible.

The path in the example below is ustar compatible, but not v7 compatible.

***
* checking for portable file names ... NOTE
Found the following non-portable file path:
  
BioCro/inc/boost/numeric/odeint/stepper/generation/generation_controlled_adams_bashforth_moulton_really_long_file_name_one_two_three.hpp

Tarballs are only required to store paths of up to 100 bytes and cannot
store those of more than 256 bytes, with restrictions including to 100
bytes for the final component.
***

The code is in library/tools/R/check.R. An equivalent test is performed by R 
CMD build in library/tools/utils/tar.R.

AFAIK, CRAN rejects a package regardless whether the message is given as a NOTE 
or a WARNING. ustar is 35 years old and is older than R itself, and thus anyone 
using R in the last several decades will have ustar support. Any path stored by 
ustar will be suitable for any common file system in use for the last several 
decades. Overall, if a path is supported by ustar, there is no reason to 
generate any message, even if that path is not v7 compatible. If the NOTE about 
v7 incompatibility is still desired, then could CRAN not reject packages for 
which the check reports a NOTE?

Best wishes,
Justin



From: Martin Maechler 
Sent: Wednesday, December 13, 2023 2:22 AM
To: Ben Bolker; McGrath, Justin M
Cc: Simon Urbanek; Duncan Murdoch
Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length 
limit be lifted?

> Ben Bolker
> on Tue, 12 Dec 2023 15:48:11 -0500 writes:

> 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://urldefense.com/v3/__https://stackoverflow.com/questions/30599326/warning-message-during-building-an-r-package-invalid-uid-value-replaced-by-that__;!!DZ3fjg!7eG1psjusIaxJny-wr4z56esZliTkCKpBunUO0IPxzllvu3oSRehH6ZnQh8vJN6ZkaAAmNXHaAHfrqwULOipdsJh2VOFww$

> (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 ...)

Well, yes, in parts at least.

Originally, even when it did not seem clear, it mostly seemed about the
part of the  help(tar)  page you mention above  and the
implementation of tar() .. i.e.  R-devel.

... but it's not really important anymore now, and hence this goes only to you.

Best regards,
Martin


> 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
  

Re: [Rd] Request: documenting more specifically language objects in the R Language Definition document

[Iago Giné Vázquez]

Thank you for your answers.

Just let me disagree slightly with Tomas view.

On 13/12/2023 12:05, Tomas Kalibera wrote:
> On 12/13/23 11:27, Duncan Murdoch wrote:
>> I doubt if anyone will take you up on this request.  Only R Core 
>> members can change those manuals, and it's hard work to write clear 
>> and correct documentation.  This probably won't make it high enough 
>> on their lists of priorities to actually be addressed.
>
> There is another aspect of this - portable R packages only use 
> documented behavior of R, relying on that such behavior will not 
> change unless absolutely necessary. A very hard part of 
> writing/expanding the official documentation is deciding on what 
> should and what shouldn't be the stable/documented behavior, and even 
> more so when it is about fundamental things. It is essential that some 
> behavior stays undocumented and is not relied on, otherwise it 
> wouldn't be possible to maintain and improve R.

Actually, I would say that "portable R packages" use a lot these types 
of objects (formulas, calls, ...) and I would bet that they even use 
quite a lot of the undocumented behaviour I would expect to find, which 
is more needed precisely "when it is about fundamental things".


Iago


>
> So if you primarily wanted to get an answer to a specific technical 
> question about say formulas, it is best to just ask that question, 
> rather than asking for expanding the documentation.
>
> Tomas
>
>
>>
>> What you could do is try to write it yourself.  Find some helpers who 
>> really know the details (not necessarily R Core members) to review 
>> your proposal.  Once you have it written and everyone agrees it is 
>> correct, either publish it as a blog entry somewhere, or submit it to 
>> R Core for inclusion in the manual. I don't recommend posting early 
>> drafts to this mailing list, though you could post near-final ones 
>> here:  you're only going to get a few comments before people lose 
>> interest.
>>
>> This would be a lot of work for you.  Besides the work of writing 
>> clearly and correctly, you need to learn the material. But that's a 
>> big benefit for you if you are really interested in working with this 
>> kind of thing.
>>
>> Duncan Murdoch
>>
>> On 13/12/2023 4:19 a.m., Iago Giné Vázquez wrote:
>>> Dear  all,
>>>
>>>
>>> This is a request to get language objects more documented in the R 
>>> Language Definition document (CRAN 
>>> version, 
>>> ETHZ R-devel 
>>> version).
>>>
>>> Section '2.1.3 Language objects' claims
>>> There are three types of objects that constitute the R language. 
>>> They are calls, expressions, and names.
>>> But then there is only a subsection '2.1.3.1 Symbol objects' which, 
>>> if I do not understand wrongly, correspond to names subtype of 
>>> language objects. It would be great if calls and expressions 
>>> subtypes were specified with more detail as well. And also calls 
>>> subtype 'formula'.
>>>
>>> I came to here since when looking help for formula, it documents the 
>>> stats function formula -Model Formula-, and it just says that it 
>>> produces an object of class '"formula"' [...] and that a formula 
>>> object has an associated environment [...]. Maybe this, and saying  
>>> that the mode of a formula is a call it is enough to describe a 
>>> formula?
>>>
>>> Same section 2.1.3 also claims
>>>
>>> They can be [...] converted to and from lists by the as.list and 
>>> as.call functions
>>>
>>> It could be added also a description of how these lists should be 
>>> (structured, their components, names, etc.) for the different 
>>> language objects, that is, for names, expressions, calls, formulas 
>>> and so on.
>>>
>>> Thank you.
>>>
>>> Best wishes,
>>> Iago
>>>
>>>
>>>
>>>
>>> [[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
[[alternative HTML version deleted]]

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

Re: [Rd] Request: documenting more specifically language objects in the R Language Definition document

[Tomas Kalibera]

On 12/13/23 11:27, Duncan Murdoch wrote:
I doubt if anyone will take you up on this request.  Only R Core 
members can change those manuals, and it's hard work to write clear 
and correct documentation.  This probably won't make it high enough on 
their lists of priorities to actually be addressed.


There is another aspect of this - portable R packages only use 
documented behavior of R, relying on that such behavior will not change 
unless absolutely necessary. A very hard part of writing/expanding the 
official documentation is deciding on what should and what shouldn't be 
the stable/documented behavior, and even more so when it is about 
fundamental things. It is essential that some behavior stays 
undocumented and is not relied on, otherwise it wouldn't be possible to 
maintain and improve R.


So if you primarily wanted to get an answer to a specific technical 
question about say formulas, it is best to just ask that question, 
rather than asking for expanding the documentation.


Tomas




What you could do is try to write it yourself.  Find some helpers who 
really know the details (not necessarily R Core members) to review 
your proposal.  Once you have it written and everyone agrees it is 
correct, either publish it as a blog entry somewhere, or submit it to 
R Core for inclusion in the manual.  I don't recommend posting early 
drafts to this mailing list, though you could post near-final ones 
here:  you're only going to get a few comments before people lose 
interest.


This would be a lot of work for you.  Besides the work of writing 
clearly and correctly, you need to learn the material.  But that's a 
big benefit for you if you are really interested in working with this 
kind of thing.


Duncan Murdoch

On 13/12/2023 4:19 a.m., Iago Giné Vázquez wrote:

Dear  all,


This is a request to get language objects more documented in the R 
Language Definition document (CRAN 
version, 
ETHZ R-devel 
version).


Section '2.1.3 Language objects' claims
There are three types of objects that constitute the R language. They 
are calls, expressions, and names.
But then there is only a subsection '2.1.3.1 Symbol objects' which, 
if I do not understand wrongly, correspond to names subtype of 
language objects. It would be great if calls and expressions subtypes 
were specified with more detail as well. And also calls subtype 
'formula'.


I came to here since when looking help for formula, it documents the 
stats function formula -Model Formula-, and it just says that it 
produces an object of class '"formula"' [...] and that a formula 
object has an associated environment [...]. Maybe this, and saying  
that the mode of a formula is a call it is enough to describe a formula?


Same section 2.1.3 also claims

They can be [...] converted to and from lists by the as.list and 
as.call functions


It could be added also a description of how these lists should be 
(structured, their components, names, etc.) for the different 
language objects, that is, for names, expressions, calls, formulas 
and so on.


Thank you.

Best wishes,
Iago




[[alternative HTML version deleted]]

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


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


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

Re: [Rd] Request: documenting more specifically language objects in the R Language Definition document

[Duncan Murdoch]

I doubt if anyone will take you up on this request.  Only R Core members 
can change those manuals, and it's hard work to write clear and correct 
documentation.  This probably won't make it high enough on their lists 
of priorities to actually be addressed.


What you could do is try to write it yourself.  Find some helpers who 
really know the details (not necessarily R Core members) to review your 
proposal.  Once you have it written and everyone agrees it is correct, 
either publish it as a blog entry somewhere, or submit it to R Core for 
inclusion in the manual.  I don't recommend posting early drafts to this 
mailing list, though you could post near-final ones here:  you're only 
going to get a few comments before people lose interest.


This would be a lot of work for you.  Besides the work of writing 
clearly and correctly, you need to learn the material.  But that's a big 
benefit for you if you are really interested in working with this kind 
of thing.


Duncan Murdoch

On 13/12/2023 4:19 a.m., Iago Giné Vázquez wrote:

Dear  all,


This is a request to get language objects more documented in the R Language Definition 
document (CRAN version, 
ETHZ R-devel version).

Section '2.1.3 Language objects' claims
There are three types of objects that constitute the R language. They are 
calls, expressions, and names.
But then there is only a subsection '2.1.3.1 Symbol objects' which, if I do not 
understand wrongly, correspond to names subtype of language objects. It would 
be great if calls and expressions subtypes were specified with more detail as 
well. And also calls subtype 'formula'.

I came to here since when looking help for formula, it documents the stats function 
formula -Model Formula-, and it just says that it produces an object of class 
'"formula"' [...] and that a formula object has an associated environment 
[...]. Maybe this, and saying  that the mode of a formula is a call it is enough to 
describe a formula?

Same section 2.1.3 also claims

They can be [...] converted to and from lists by the as.list and as.call 
functions

It could be added also a description of how these lists should be (structured, 
their components, names, etc.) for the different language objects, that is, for 
names, expressions, calls, formulas and so on.

Thank you.

Best wishes,
Iago




[[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] How to fix: non-standard things in the check directory: 'NUL' ?

[Ivan Krylov]

Dear Friedemann von Lampe,

Welcome to R-package-devel! This is a good, concise description of the
problem, but please also provide a link to your code in the future.

В Wed, 13 Dec 2023 09:58:41 +0100
Friedemann von Lampe 
пишет:

> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: for non-standard things in the check directory, Result: NOTE
> Found the following files/directories:
> 'NUL'

The file named 'NUL' is created in the function screeplot_NMDS:

R/screeplot_NMDS.R:  capture.output(nmds_i <- invisible(metaMDS(matrix,
distance = distance, k = i, trymax = trymax, engine = "monoMDS",
autotransform = autotransform)), file='NUL')

https://github.com/fvlampe/goeveg/blob/db94c4a567eeac67b6df1df5a4f2d1aa771e629a/R/screeplot_NMDS.R#L76

On Windows, everything goes right and the output is redirected to the
null device. On Linux, the null device is '/dev/null', not 'NUL', and
this name doesn't hold any special powers, so the file with this name
gets created.

Use the base function nullfile() to obtain the name of the null device
in a portable manner. I think you can also not supply the `file`
argument and ignore the return value of the capture.output(...)
expression. This may be less efficient if there's truly a lot of output.

-- 
Best regards,
Ivan

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

[Rd] Request: documenting more specifically language objects in the R Language Definition document

[Iago Giné Vázquez]

Dear  all,


This is a request to get language objects more documented in the R Language 
Definition document (CRAN 
version, ETHZ 
R-devel version).

Section '2.1.3 Language objects' claims
There are three types of objects that constitute the R language. They are 
calls, expressions, and names.
But then there is only a subsection '2.1.3.1 Symbol objects' which, if I do not 
understand wrongly, correspond to names subtype of language objects. It would 
be great if calls and expressions subtypes were specified with more detail as 
well. And also calls subtype 'formula'.

I came to here since when looking help for formula, it documents the stats 
function formula -Model Formula-, and it just says that it produces an object 
of class '"formula"' [...] and that a formula object has an associated 
environment [...]. Maybe this, and saying  that the mode of a formula is a call 
it is enough to describe a formula?

Same section 2.1.3 also claims

They can be [...] converted to and from lists by the as.list and as.call 
functions

It could be added also a description of how these lists should be (structured, 
their components, names, etc.) for the different language objects, that is, for 
names, expressions, calls, formulas and so on.

Thank you.

Best wishes,
Iago




[[alternative HTML version deleted]]

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

[R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?

[Friedemann von Lampe]

Hi,

when trying to update my package on CRAN it is rejected, because it gets 
a note during checks on Debian:


Flavor: r-devel-linux-x86_64-debian-gcc
Check: for non-standard things in the check directory, Result: NOTE
Found the following files/directories:
'NUL'

There is no such file in my folder and therefore it can't be removed. 
With Windows everything is OK.
As far as I understood, this is a problem with Rhub? 
(https://github.com/clessn/locateip/issues/99)


Or what can I do, to fix this problem and get my package update 
submitted to CRAN?


Thanks,
Friedemann von Lampe

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

Re: [Rd] Partial matching performance in data frame rownames using [

[Hilmar Berger via R-devel]

Dear Ivan,

thanks a lot, that is helpful.

Still, I feel that default partial matching cripples the functionality
of data.frame for larger tables.

Thanks again and best regards

Hilmar

On 12.12.23 13:55, Ivan Krylov wrote:

В Mon, 11 Dec 2023 21:11:48 +0100
Hilmar Berger via R-devel  пишет:


What was unexpected is that in this case was that [.data.frame was
hanging for a long time (I waited about 10 minutes and then restarted
R). Also, this cannot be interrupted in interactive mode.

That's unfortunate. If an operation takes a long time, it ought to be
interruptible. Here's a patch that passes make check-devel:

--- src/main/unique.c   (revision 85667)
+++ src/main/unique.c   (working copy)
@@ -1631,6 +1631,7 @@
}
  }

+unsigned int ic = ;
  if(nexact < n_input) {
/* Second pass, partial matching */
for (R_xlen_t i = 0; i < n_input; i++) {
@@ -1642,6 +1643,10 @@
mtch = 0;
mtch_count = 0;
for (int j = 0; j < n_target; j++) {
+   if (!--ic) {
+   R_CheckUserInterrupt();
+   ic = ;
+   }
if (no_dups && used[j]) continue;
if (strncmp(ss, tar[j], temp) == 0) {
mtch = j + 1;



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