Re: [R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently

[Ivan Krylov]

On Thu, 12 Oct 2023 11:32:24 -0400
Mikael Jagan  wrote:

>  > mk <- file.path(R.home("share"), "make", "vars.mk")
>  > pp <- sub("^.*= +", "", grep("^R_PKGS_RECOMMENDED",
>  > readLines(mk), value = TRUE))
>  > sort(strsplit(pp, " ")[[1L]])  
>   [1] "KernSmooth" "MASS"   "Matrix" "boot"   "class"
>   [6] "cluster""codetools"  "foreign""lattice""mgcv"
>  [11] "nlme"   "nnet"   "rpart"  "spatial" "survival"
> 
> I grepped around and did not find variables in any base namespace
> containing the names of these packages.  It wouldn't be too hard to
> define such variables when R is configured/built, but maybe there are
> "reasons" to not do that ... ?

tools:::.get_standard_package_names does that at package installation
time, but it's still not public API.

A call to installed.packages() may take a long while because it has to
list files in every library (some of which can be large and/or
network-mounted) and parse each Meta/package.rds file, but at least
list.files() is faster than that.

If I had to make a choice at this point, I would hard-code the list of
packages, but a better option may surface once we know what Tony needs
the package lists for.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently

[Mikael Jagan]

Maybe something like this:

> isRecommendedPkg <- utils:::isBasePkg
> body(isRecommendedPkg)[[c(3L, 3L)]] <- "recommended"
> installed <- unique(list.files(.libPaths()))
> installed[vapply(installed, isRecommendedPkg, NA)]
 [1] "KernSmooth" "MASS"   "Matrix" "boot"   "class"
 [6] "cluster""codetools"  "foreign""lattice""mgcv"
[11] "nlme"   "nnet"   "rpart"  "spatial""survival"

where in your package you would define isRecommendedPkg "manually".

Another (but quite undocumented and so maybe not "recommended" :-))
possibility is this:

> mk <- file.path(R.home("share"), "make", "vars.mk")
> pp <- sub("^.*= +", "", grep("^R_PKGS_RECOMMENDED", readLines(mk), value 
= TRUE))

> sort(strsplit(pp, " ")[[1L]])
 [1] "KernSmooth" "MASS"   "Matrix" "boot"   "class"
 [6] "cluster""codetools"  "foreign""lattice""mgcv"
[11] "nlme"   "nnet"   "rpart"  "spatial""survival"

I grepped around and did not find variables in any base namespace containing
the names of these packages.  It wouldn't be too hard to define such variables
when R is configured/built, but maybe there are "reasons" to not do that ... ?

Mikael

> It would be much faster (but slightly less reliable) to use
> list.files(.libPaths()) to get the names of all installed packages, and
> then filter them to the known list of base and recommended packages,
> which changes very rarely.
>
> Duncan Murdoch
>
> On 12/10/2023 8:34 a.m., Tony Wilkes wrote:
> > Dear all,
> >
> > In my R package that I'm developing, I use `installed.packages(priority = 
"base")` to programmatically get all core/base R packages (i.e. base, stats, 
etc.). And similarly, I use installed.packages(priority = "recommended")​` to 
programmatically get the recommended R packages (i.e. mgcv, lattice, etc.).

> >
> > However, CRAN has requested to not use `installed.packages()`, as it is 
slow. I fully get and agree with that assesment. I used installed.packages()​` 
anyway because I could not find a better, fool-proof alternative.

> >
> > Nonetheless, I was asked to change this code for optimalisation. So I would 
like to ask: how do I programmatically get all base/core R packages safely and 
efficiently, but without using `installed.packages()`? And the same question for 
recommended R packages. I have of course Googled it, and looked at R's 
documentation (though R's documentation is large, so it's easy to miss 
something); no solution found. So if any of you has a smart idea: I'm all ears.

> >
> > Thank you in advance.
> >
> > Kind regards,
> >
> > Tony.

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

Re: [R-pkg-devel] pkg check: SyntaxError: break must be inside loop or switch

[Charles Driver]

So apparently there is a corrupted file in the current Stanheaders, 
which is hopefully fixed soon...

On 11/10/2023 9:40 am, Ivan Krylov wrote:
> В Tue, 10 Oct 2023 16:36:31 +0200
> Charles Driver  пишет:
>
>>SyntaxError: break must be inside loop or switch
> This looks like an error coming from a JavaScript engine or from a
> JavaScript-derived language:
>
> https://github.com/blld/libecc/blob/88877a46ba9b0a47567aa999a4380b9e793783a8/src/main.c#L714
> https://github.com/ynezz/openwrt-ucode/blob/5163867269fc04fa01ec5e9f8df3384c99f2/compiler.c#L2930https://github.com/Bobris/Njsast/blob/930f59a9694432580a7b1367680c56672cfe4cd2/Njsast/Compress/LoopControlFinderTreeWalker.cs#L34
>
> (Most modern implementations say "_unlabeled_ break must be inside loop
> or switch", but this may come from an older version.)
>
> This seems to have nothing to do with Stan either; at the very least I
> cannot find this exact error message inhttps://github.com/stan-dev.
> When R complains about a wrongly placed `break`, it also looks
> differently:
>
> break
> # Error: no loop for break/next, jumping to top level
>
> An infrastructure hiccup on Win-Builder?
>

[[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] Question regarding listing base and recommended packages programmatically and efficiently

[Duncan Murdoch]

It would be much faster (but slightly less reliable) to use 
list.files(.libPaths()) to get the names of all installed packages, and 
then filter them to the known list of base and recommended packages, 
which changes very rarely.


Duncan Murdoch

On 12/10/2023 8:34 a.m., Tony Wilkes wrote:

Dear all,

In my R package that I'm developing, I use `installed.packages(priority = "base")` to 
programmatically get all core/base R packages (i.e. base, stats, etc.). And similarly, I use 
installed.packages(priority = "recommended")​` to programmatically get the recommended R 
packages (i.e. mgcv, lattice, etc.).

However, CRAN has requested to not use `installed.packages()`, as it is slow. I 
fully get and agree with that assesment. I used installed.packages()​` anyway 
because I could not find a better, fool-proof alternative.

Nonetheless, I was asked to change this code for optimalisation. So I would 
like to ask: how do I programmatically get all base/core R packages safely and 
efficiently, but without using `installed.packages()`? And the same question 
for recommended R packages. I have of course Googled it, and looked at R's 
documentation (though R's documentation is large, so it's easy to miss 
something); no solution found. So if any of you has a smart idea: I'm all ears.

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


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

Re: [R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently

[Thierry Onkelinx]

Dear Tony,

Much will depend on what information you need from the output of
installed.packages()?

Best regards,

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
Havenlaan 88 bus 73, 1000 Brussel
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
///




Op do 12 okt 2023 om 14:34 schreef Tony Wilkes :

> Dear all,
>
> In my R package that I'm developing, I use `installed.packages(priority =
> "base")` to programmatically get all core/base R packages (i.e. base,
> stats, etc.). And similarly, I use installed.packages(priority =
> "recommended")​` to programmatically get the recommended R packages (i.e.
> mgcv, lattice, etc.).
>
> However, CRAN has requested to not use `installed.packages()`, as it is
> slow. I fully get and agree with that assesment. I used
> installed.packages()​` anyway because I could not find a better, fool-proof
> alternative.
>
> Nonetheless, I was asked to change this code for optimalisation. So I
> would like to ask: how do I programmatically get all base/core R packages
> safely and efficiently, but without using `installed.packages()`? And the
> same question for recommended R packages. I have of course Googled it, and
> looked at R's documentation (though R's documentation is large, so it's
> easy to miss something); no solution found. So if any of you has a smart
> idea: I'm all ears.
>
> 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

[R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently

[Tony Wilkes]

Dear all,

In my R package that I'm developing, I use `installed.packages(priority = 
"base")` to programmatically get all core/base R packages (i.e. base, stats, 
etc.). And similarly, I use installed.packages(priority = "recommended")​` to 
programmatically get the recommended R packages (i.e. mgcv, lattice, etc.).

However, CRAN has requested to not use `installed.packages()`, as it is slow. I 
fully get and agree with that assesment. I used installed.packages()​` anyway 
because I could not find a better, fool-proof alternative.

Nonetheless, I was asked to change this code for optimalisation. So I would 
like to ask: how do I programmatically get all base/core R packages safely and 
efficiently, but without using `installed.packages()`? And the same question 
for recommended R packages. I have of course Googled it, and looked at R's 
documentation (though R's documentation is large, so it's easy to miss 
something); no solution found. So if any of you has a smart idea: I'm all ears.

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

Re: [R-pkg-devel] Question about Clang 17 Error

[Martin Maechler]

> Reed A Cartwright 
> on Wed, 11 Oct 2023 22:25:35 -0700 writes:

> Okay, I'll reach out to the CRAN team shortly.
> I wanted to run it by the group here first because my interactions with 
the
> CRAN team haven't always been positive and I need to make sure that I'm 
not
> missing something "obvious".

well..  one thing not enough obvious:  Simon Urbanek _is_
part of the CRAN team (*).   So at least you had a positive
interaction with "them", now ! ;-)

---
*) https://cran.r-project.org/CRAN_team.htm
  (which is the *first* hit when I web search "CRAN team" {with
  DuckDuckGo, a reasonable non-prying Google-alternative I})


Best,
Martin


> On Wed, Oct 11, 2023, 22:22 Simon Urbanek 
> wrote:

>> Reed,
>> 
>> please contact CRAN - this list can only help with general developer's
>> questions, not specific issues with a particular CRAN setup - only the
>> corresponding member of CRAN running the setup can help. I don't see
>> anything obvious - we can see that it's a mismatch of run-times between 
the
>> cmake build and the R linking, but from the package alone it's not clear 
to
>> me why.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> On Oct 12, 2023, at 3:51 PM, Reed A. Cartwright 
>> wrote:
>> 
>> Update: I submitted a new version of the package, but it did not fix the
>> issue. The package has now been archived and I do not have access to the
>> error log output anymore from r-devel-linux-x86_64-fedora-clang.
>> 
>> I did reproduce CRAN's configuration in a VM using the information
>> provided by CRAN for r-devel-linux-x86_64-fedora-clang. I still cannot
>> reproduce the error and at this point I believe that there is a chance 
that
>> CRAN's machine is misconfigured.
>> 
>> The specific error happens after rbedrock has been compiled and linked
>> successfully. The specific error is that the symbol
>> _ZNSt3__122__libcpp_verbose_abortEPKcz cannot be found when rbedrock.so 
is
>> loaded.This symbol was introduced into libc++ in Clang 15.0. What I 
believe
>> to be happening to cause the error is that Clang++ 17 is adding a 
reference
>> to this symbol when compiling and linking rbedrock.so but the dynamic
>> linker is loading an older version of libc++.so when trying to load
>> rbedrock.so and the symbol is not found.
>> 
>> If this is the cause, then I think that the CRAN machine needs to
>> configure the dynamic linker to use the Clang++ 17 libc++.so, or add the
>> proper command line options to R's config variables.
>> 
>> It's possible that the CRAN's r-devel-linux-x86_64-fedora-clang machine 
is
>> fine and I've missed something, and I would be happy if someone could 
help
>> me figure out what it is.
>> 
>> Also, a new issue cropped up when 0.3.1 was tested on the
>> r-oldrel-macos-x86_64 machine. /usr/bin/ar seems to have failed to 
produce
>> an archive. The other Mac versions did fine, so I'm not sure if this is a
>> random error or something related to my package. The error log is here:
>> 
https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/rbedrock-00install.html
>> 

>> 
>> If anyone can help me resolve this, I'd appreciate it.
>> 
>> 
>> On Wed, Sep 27, 2023 at 2:54 PM Reed A. Cartwright 

>> wrote:
>> 
>>> Is there any way to submit packages directly to the CRAN's clang17 
setup?
>>> I can enable verbose output for CMake and compare the output, but I'd
>>> rather not clog up the CRAN incoming queue just to debug a linker error?
>>> 
>>> On Wed, Sep 27, 2023 at 2:43 PM Simon Urbanek <
>>> simon.urba...@r-project.org> wrote:
>>> 
 It looks like a C++ run-time mismatch between what cmake is using to
 build the static library and what is used by R. Unfortunately, cmake 
hides
 the actual compiler calls so it's hard to tell the difference, but that
 setup relies on the correct sequence of library paths.
 
 The rhub manually forces -stdlib=libc++ to all its CXX flags
 
 
https://urldefense.com/v3/__https://github.com/r-hub/rhub-linux-builders/blob/master/fedora-clang-devel/Makevars__;!!IKRxdwAv5BmarQ!bAZgiOQaK4hd5BTk_Ldx9IEHgzHKVbC-uMkvYv5GOVkZDvbedcGwS8dQ4MWXRjukFfds7UpiR9NDZfEoUCWeoVnCfrDa$
 so it is quite different from the gannet tests-clang-trunk setup (also
 note the different library paths), but that's not something you can do
 universally in the package, because it strongly depends on the 
toolchain
 setup.
 
 Cheers,
 Simon
 
 
 > On 28/09/20