Re: [Rd] configure --with-pcre1 fails with latest R 4.0 on Ubuntu 14.04
On 3/17/20 8:18 PM, Hervé Pagès wrote: Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on an Ubuntu 14.04.5 LTS system gives me the following error: ... checking if lzma version >= 5.0.3... yes checking for pcre2-config... no checking for pcre_fullinfo in -lpcre... yes checking pcre.h usability... yes checking pcre.h presence... yes checking for pcre.h... yes checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE1 version >= 8.32 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre2 library and headers are required, or use --with-pcre1 Maybe the real problem is that the PCRE version on this OS is 8.31? Yes, R requires PCRE version at least 8.32 as documented in R-Admin, and this is since September 2019. The error message is not particularly helpful. An earlier version of the message gave the requirement explicitly, when people would have been more likely to have that old versions of PCRE1. The few who still have it now need to see also the output line above to get the requirement and/or look into the manual. R 4.0 is still keeping support for PCRE1 (>=8.32), but PCRE2 should be used whenever possible. Best, Tomas Thanks, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] substitute inconsistent output
On 18/03/2020 1:36 a.m., Jan Gorecki wrote: Dear R-devel, Is there anything that we can do to make output of those call more consistent? So the first one will return `c(1L, 2L)` rather than `1:2`. Note that it is not related to compact integer sequence introduced by altrep, it is reproducible on R 3.1.0 as well. substitute(v+x, list(x=c(1L,2L))) #v + 1:2 substitute(v+x, list(x=c(0L,2L))) #v + c(0L, 2L) That's purely the deparser (the returned value from substitute doesn't contain a call to ":"), but it's not optional. So the output is consistent, it's the printing that is inconsistent. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure --with-pcre1 fails with latest R 4.0 on Ubuntu 14.04
Thanks Tomas. Any chance the old version of the error message could be restored? It would definitely be more helpful than the current one. It's confusing to get an error and be told to use --with-pcre1 when you're already using it. H. On 3/18/20 01:08, Tomas Kalibera wrote: On 3/17/20 8:18 PM, Hervé Pagès wrote: Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on an Ubuntu 14.04.5 LTS system gives me the following error: ... checking if lzma version >= 5.0.3... yes checking for pcre2-config... no checking for pcre_fullinfo in -lpcre... yes checking pcre.h usability... yes checking pcre.h presence... yes checking for pcre.h... yes checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE1 version >= 8.32 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre2 library and headers are required, or use --with-pcre1 Maybe the real problem is that the PCRE version on this OS is 8.31? Yes, R requires PCRE version at least 8.32 as documented in R-Admin, and this is since September 2019. The error message is not particularly helpful. An earlier version of the message gave the requirement explicitly, when people would have been more likely to have that old versions of PCRE1. The few who still have it now need to see also the output line above to get the requirement and/or look into the manual. R 4.0 is still keeping support for PCRE1 (>=8.32), but PCRE2 should be used whenever possible. Best, Tomas Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails
AFAIU, 'R CMD check --as-cran' tries to hide any site and user package
libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary
to R_LIBS_SITE, it fails for R_LIBS_USER and the user's personal
library is still available for test scripts. Should I revise my
assumptions, or is that intentional?
The short version. Shouldn't:
$ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
[1] "/home/hb/R/x86_64-pc-linux-gnu-library/4.0"
[2] "/home/hb/software/R-devel/trunk/lib/R/library"
give the same output as:
$ R_LIBS_USER="no_such_dir" Rscript --vanilla -e ".libPaths()"
[1] "/home/hb/software/R-devel/trunk/lib/R/library"
?
The long version:
R_LIBS_SITE='no_such_dir' and R_LIBS_USER='' is set up at the very
end of tools:::setRlibs():
setRlibs <-
...
c(paste0("R_LIBS=", rlibs),
if(WINDOWS) " R_ENVIRON_USER='no_such_file'" else "R_ENVIRON_USER=''",
if(WINDOWS) " R_LIBS_USER='no_such_dir'" else "R_LIBS_USER=''",
" R_LIBS_SITE='no_such_dir'")
}
Monitoring with 'pstree' confirms this. On Linux with R 3.6.3, the
call stack of a 'R CMD check --as-cran teeny_0.1.0.tar.gz' call looks
like this when a test script is running:
`-sh /usr/lib/R/bin/check --as-cran teeny_0.1.0.tar.gz
`-R --no-restore --slave --args nextArg--as-crannextArgteeny_0.1.0.tar.gz
`-sh -c LANGUAGE=en _R_CHECK_INTERNALS2_=1
R_LIBS=/tmp/hb/RtmpQj4hXb/RLIBS_26e766e32c18 R_ENVIRON_USER=''
R_LIBS_USER='' R_LIBS_SITE='no_such_dir' '/usr/lib/R/bin/R' --vanilla
--slave < '/tmp/hb/RtmpQj4hXb/file26e763770b6a'
`-R --vanilla --slave
`-sh -c LANGUAGE=C R_TESTS=startup.Rs '/usr/lib/R/bin/R' CMD BATCH
--vanilla 'env.R' 'env.Rout'
`-sh /usr/lib/R/bin/BATCH --vanilla env.R env.Rout
`-R -f env.R --restore --save --no-readline --vanilla
`-sh -c 'pstree' --arguments --long --show-parents 10558
`-pstree --arguments --long --show-parents 10558
However, if I call print(Sys.getenv("R_LIBS_USER")) in my tests/env.R,
I'll find that it is no longer empty but it is indeed set to my
personal library "~/R/x86_64-pc-linux-gnu-library/3.6".
TROUBLESHOOTING:
It looks like R_LIBS_USER is set if and only if it's empty by Renviron
in my system folder:
$ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.6'}
#R_LIBS_USER=${R_LIBS_USER-'~/Library/R/3.6/library'}
# edd Jul 2007 Now use R_LIBS_SITE, not R_LIBS
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
This is from installing R on Ubuntu 18.04 using 'apt install
r-base-core'. To make sure it's not an issue with that distribution,
I also check a 'configure/make/make install' from SVN trunk and there
I see the same:
$ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/4.0'}
#R_LIBS_USER=${R_LIBS_USER-'~/Library/R/4.0/library'}
Printing it during tests/env.R confirms that it is indeed set to
"~/R/x86_64-pc-linux-gnu-library/4.0".
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails
On 18 March 2020 at 19:19, Henrik Bengtsson wrote:
| AFAIU, 'R CMD check --as-cran' tries to hide any site and user package
| libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary
What makes you think that? AFAIK --as-cran just sets a bunch of the (nearly
countless) environment variables (all described in R Inst+Admin, as I recall)
to a set of values "close to" values CRAN uses.
| to R_LIBS_SITE, it fails for R_LIBS_USER and the user's personal
| library is still available for test scripts. Should I revise my
| assumptions, or is that intentional?
I would place a nickel on the former if betting was allowed in Illinois.
edd@rob:~$ Rscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
edd@rob:~$ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
edd@rob:~$
I happen to turn per-user libraries off by default, which may affect things.
That said, I actually quite like having the same paths. Your mileage, as they
say, may vary.
Dirk
| The short version. Shouldn't:
|
| $ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
| [1] "/home/hb/R/x86_64-pc-linux-gnu-library/4.0"
| [2] "/home/hb/software/R-devel/trunk/lib/R/library"
|
| give the same output as:
|
| $ R_LIBS_USER="no_such_dir" Rscript --vanilla -e ".libPaths()"
| [1] "/home/hb/software/R-devel/trunk/lib/R/library"
|
| ?
|
| The long version:
|
| R_LIBS_SITE='no_such_dir' and R_LIBS_USER='' is set up at the very
| end of tools:::setRlibs():
|
| setRlibs <-
| ...
| c(paste0("R_LIBS=", rlibs),
| if(WINDOWS) " R_ENVIRON_USER='no_such_file'" else "R_ENVIRON_USER=''",
| if(WINDOWS) " R_LIBS_USER='no_such_dir'" else "R_LIBS_USER=''",
| " R_LIBS_SITE='no_such_dir'")
| }
|
| Monitoring with 'pstree' confirms this. On Linux with R 3.6.3, the
| call stack of a 'R CMD check --as-cran teeny_0.1.0.tar.gz' call looks
| like this when a test script is running:
|
| `-sh /usr/lib/R/bin/check --as-cran teeny_0.1.0.tar.gz
| `-R --no-restore --slave --args nextArg--as-crannextArgteeny_0.1.0.tar.gz
| `-sh -c LANGUAGE=en _R_CHECK_INTERNALS2_=1
| R_LIBS=/tmp/hb/RtmpQj4hXb/RLIBS_26e766e32c18 R_ENVIRON_USER=''
| R_LIBS_USER='' R_LIBS_SITE='no_such_dir' '/usr/lib/R/bin/R' --vanilla
| --slave < '/tmp/hb/RtmpQj4hXb/file26e763770b6a'
|`-R --vanilla --slave
| `-sh -c LANGUAGE=C R_TESTS=startup.Rs '/usr/lib/R/bin/R' CMD BATCH
| --vanilla 'env.R' 'env.Rout'
| `-sh /usr/lib/R/bin/BATCH --vanilla env.R env.Rout
| `-R -f env.R --restore --save --no-readline --vanilla
|`-sh -c 'pstree' --arguments --long --show-parents 10558
| `-pstree --arguments --long --show-parents 10558
|
| However, if I call print(Sys.getenv("R_LIBS_USER")) in my tests/env.R,
| I'll find that it is no longer empty but it is indeed set to my
| personal library "~/R/x86_64-pc-linux-gnu-library/3.6".
|
|
| TROUBLESHOOTING:
|
| It looks like R_LIBS_USER is set if and only if it's empty by Renviron
| in my system folder:
|
| $ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
| R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.6'}
| #R_LIBS_USER=${R_LIBS_USER-'~/Library/R/3.6/library'}
| # edd Jul 2007 Now use R_LIBS_SITE, not R_LIBS
|
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
|
| This is from installing R on Ubuntu 18.04 using 'apt install
| r-base-core'. To make sure it's not an issue with that distribution,
| I also check a 'configure/make/make install' from SVN trunk and there
| I see the same:
|
| $ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
| R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/4.0'}
| #R_LIBS_USER=${R_LIBS_USER-'~/Library/R/4.0/library'}
|
| Printing it during tests/env.R confirms that it is indeed set to
| "~/R/x86_64-pc-linux-gnu-library/4.0".
|
| /Henrik
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails
On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel wrote:
>
>
> On 18 March 2020 at 19:19, Henrik Bengtsson wrote:
> | AFAIU, 'R CMD check --as-cran' tries to hide any site and user package
> | libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary
>
> What makes you think that? AFAIK --as-cran just sets a bunch of the (nearly
> countless) environment variables (all described in R Inst+Admin, as I recall)
> to a set of values "close to" values CRAN uses.
1. --as-cran sets R_LIBS_SITE='no_such_dir' and R_LIBS_USER='',
whereas without --as-cran they're not set.
2. --as-cran sets R_LIBS_USER='no_such_dir' on Windows and there it is
masked, i.e. tests scripts do NOT see user's personal library because
print(Sys.getenv("R_LIBS_USER")) is reported as "'no_such_dir'"
(sic!).
The only other interpretation I can imagine from using R_LIBS_USER=''
on Linux is that is exists there to force the default settings in case
it is already set externally by user. For example, if one do
export R_LIBS_USER="$PWD"
R --vanilla CMD check --as-cran teeny_0.1.0.tar.gz
then tests scripts still get R_LIBS_USER="~/R/x86_64-pc-linux-gnu-library/3.6".
But, then why is there a difference between Windows and Linux in this
essential behavior? To me, this suggests there is a mistake
somewhere. OTH, I know that lots of oddities in R exist for a reason.
/Henrik
>
> | to R_LIBS_SITE, it fails for R_LIBS_USER and the user's personal
> | library is still available for test scripts. Should I revise my
> | assumptions, or is that intentional?
>
> I would place a nickel on the former if betting was allowed in Illinois.
>
> edd@rob:~$ Rscript --vanilla -e ".libPaths()"
> [1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
> [3] "/usr/lib/R/library"
> edd@rob:~$ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
> [1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
> [3] "/usr/lib/R/library"
> edd@rob:~$
>
> I happen to turn per-user libraries off by default, which may affect things.
> That said, I actually quite like having the same paths. Your mileage, as they
> say, may vary.
>
> Dirk
>
>
> | The short version. Shouldn't:
> |
> | $ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
> | [1] "/home/hb/R/x86_64-pc-linux-gnu-library/4.0"
> | [2] "/home/hb/software/R-devel/trunk/lib/R/library"
> |
> | give the same output as:
> |
> | $ R_LIBS_USER="no_such_dir" Rscript --vanilla -e ".libPaths()"
> | [1] "/home/hb/software/R-devel/trunk/lib/R/library"
> |
> | ?
> |
> | The long version:
> |
> | R_LIBS_SITE='no_such_dir' and R_LIBS_USER='' is set up at the very
> | end of tools:::setRlibs():
> |
> | setRlibs <-
> | ...
> | c(paste0("R_LIBS=", rlibs),
> | if(WINDOWS) " R_ENVIRON_USER='no_such_file'" else "R_ENVIRON_USER=''",
> | if(WINDOWS) " R_LIBS_USER='no_such_dir'" else "R_LIBS_USER=''",
> | " R_LIBS_SITE='no_such_dir'")
> | }
> |
> | Monitoring with 'pstree' confirms this. On Linux with R 3.6.3, the
> | call stack of a 'R CMD check --as-cran teeny_0.1.0.tar.gz' call looks
> | like this when a test script is running:
> |
> | `-sh /usr/lib/R/bin/check --as-cran teeny_0.1.0.tar.gz
> | `-R --no-restore --slave --args nextArg--as-crannextArgteeny_0.1.0.tar.gz
> | `-sh -c LANGUAGE=en _R_CHECK_INTERNALS2_=1
> | R_LIBS=/tmp/hb/RtmpQj4hXb/RLIBS_26e766e32c18 R_ENVIRON_USER=''
> | R_LIBS_USER='' R_LIBS_SITE='no_such_dir' '/usr/lib/R/bin/R' --vanilla
> | --slave < '/tmp/hb/RtmpQj4hXb/file26e763770b6a'
> |`-R --vanilla --slave
> | `-sh -c LANGUAGE=C R_TESTS=startup.Rs '/usr/lib/R/bin/R' CMD BATCH
> | --vanilla 'env.R' 'env.Rout'
> | `-sh /usr/lib/R/bin/BATCH --vanilla env.R env.Rout
> | `-R -f env.R --restore --save --no-readline --vanilla
> |`-sh -c 'pstree' --arguments --long --show-parents 10558
> | `-pstree --arguments --long --show-parents 10558
> |
> | However, if I call print(Sys.getenv("R_LIBS_USER")) in my tests/env.R,
> | I'll find that it is no longer empty but it is indeed set to my
> | personal library "~/R/x86_64-pc-linux-gnu-library/3.6".
> |
> |
> | TROUBLESHOOTING:
> |
> | It looks like R_LIBS_USER is set if and only if it's empty by Renviron
> | in my system folder:
> |
> | $ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
> | R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.6'}
> | #R_LIBS_USER=${R_LIBS_USER-'~/Library/R/3.6/library'}
> | # edd Jul 2007 Now use R_LIBS_SITE, not R_LIBS
> |
> R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
> |
> | This is from installing R on Ubuntu 18.04 using 'apt install
> | r-base-core'. To make sure it's not an issue with that distribution,
> | I also check a 'configure/make/make install' from SVN trunk and there
> | I see the same:
> |
> | $ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
> | R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/4.0'}
> | #R
