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

[Reed A. Cartwright]

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".

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/2023, at 9:37 AM, Reed A. Cartwright 
>>> wrote:
>>> >
>>> > I was unable to reproduce the error on the rhub's clang17 docker image.
>>> >
>>> > I notice that the linking command is slightly different between
>>> systems.
>>> > And this suggests that I need to find some way to get CRAN to pass
>>> -stdlib
>>> > flag at the linking stage.
>>> >
>>> > CRAN:
>>> > /usr/local/clang17/bin/clang++ -std=gnu++17 -shared
>>> > -L/usr/local/clang/lib64 -L/usr/local/clang17/lib
>>> -L/usr/local/gcc13/lib64
>>> > -L/usr/local/lib64 -o rbedrock.so actors.o bedrock_leveldb.o dummy.o
>>> init.o
>>> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
>>> > -pthread -lleveldb -lz
>>> >
>>> > RHUB:
>>> > clang++-17 -stdlib=libc++ -std=gnu++14 -shared -L/opt/R/devel/lib/R/lib
>>> > -L/usr/local/lib -o rbedrock.so actors.o bedrock_leveldb.o dummy.o
>>> init.o
>>> > key_conv.o nbt.o 

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

[Simon Urbanek]

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  > 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/2023, at 9:37 AM, Reed A. Cartwright  > > wrote:
> > 
> > I was unable to reproduce the error on the rhub's clang17 docker image.
> > 
> > I notice that the linking command is slightly different between systems.
> > And this suggests that I need to find some way to get CRAN to pass -stdlib
> > flag at the linking stage.
> > 
> > CRAN:
> > /usr/local/clang17/bin/clang++ -std=gnu++17 -shared
> > -L/usr/local/clang/lib64 -L/usr/local/clang17/lib -L/usr/local/gcc13/lib64
> > -L/usr/local/lib64 -o rbedrock.so actors.o bedrock_leveldb.o dummy.o init.o
> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
> > -pthread -lleveldb -lz
> > 
> > RHUB:
> > clang++-17 -stdlib=libc++ -std=gnu++14 -shared -L/opt/R/devel/lib/R/lib
> > -L/usr/local/lib -o rbedrock.so actors.o bedrock_leveldb.o dummy.o init.o
> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
> > -pthread -lleveldb -lz -L/opt/R/devel/lib/R/lib -lR
> > 
> > On Wed, Sep 27, 2023 at 11:36 AM Gábor Csárdi  > 

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

[Michael Chirico via R-devel]

Great to know this exists in package space!

Of course, using re2 validation for a regex to be executed with TRE
(via grep*) is just begging for trouble (e.g. [1] suggests re2 is
closer to PCRE, [2] says "mostly" PCRE compatible). And overhauling
everything to use re2 just for regex validation is hardly practical.

[1] https://laurikari.net/tre/google-releases-the-re2-library/
[2] https://hackerboss.com/is-your-regex-matcher-up-to-snuff/

On Wed, Oct 11, 2023 at 4:02 PM Toby Hocking  wrote:
>
> Hi Michael, it sounds like you don't want to use a CRAN package for
> this, but you may try re2, see below.
>
> > grepl("(invalid","subject",perl=TRUE)
> Error in grepl("(invalid", "subject", perl = TRUE) :
>   invalid regular expression '(invalid'
> In addition: Warning message:
> In grepl("(invalid", "subject", perl = TRUE) :
>   PCRE pattern compilation error
> 'missing closing parenthesis'
> at ''
>
> > grepl("(invalid","subject",perl=FALSE)
> Error in grepl("(invalid", "subject", perl = FALSE) :
>   invalid regular expression '(invalid', reason 'Missing ')''
> In addition: Warning message:
> In grepl("(invalid", "subject", perl = FALSE) :
>   TRE pattern compilation error 'Missing ')''
>
> > re2::re2_regexp("(invalid")
> Error: missing ): (invalid
>
> On Tue, Oct 10, 2023 at 7:57 AM Michael Chirico via R-devel
>  wrote:
> >
> > > Grepping an empty string might work in many cases...
> >
> > That's precisely why a base R offering is important, as a surer way of
> > validating in all cases. To be clear I am trying to directly access the
> > results of tre_regcomp().
> >
> > > it is probably more portable to simply be prepared to propagate such
> > errors from the actual use on real inputs
> >
> > That works best in self-contained calls -- foo(re) and we execute re inside
> > foo().
> >
> > But the specific context where I found myself looking for a regex validator
> > is more complicated (https://github.com/r-lib/lintr/pull/2225). User
> > supplies a regular expression in a configuration file, only "later" is it
> > actually supplied to grepl().
> >
> > Till now, we've done your suggestion -- just surface the regex error at run
> > time. But our goal is to make it friendlier and fail earlier at "compile
> > time" as the config is loaded, "long" before any regex is actually executed.
> >
> > At a bare minimum this is a good place to return a classed warning (say
> > invalid_regex_warning) to allow finer control than tryCatch(condition=).
> >
> > On Mon, Oct 9, 2023, 11:30 PM Tomas Kalibera 
> > wrote:
> >
> > >
> > > On 10/10/23 01:57, Michael Chirico via R-devel wrote:
> > >
> > > It will be useful to package authors trying to validate input which is
> > > supposed to be a valid regular expression.
> > >
> > > As near as I can tell, the only way we can do so now is to run any
> > > regex function and check for the warning and/or condition to bubble
> > > up:
> > >
> > > valid_regex <- function(str) {
> > >   stopifnot(is.character(str), length(str) == 1L)
> > >   !inherits(tryCatch(grepl(str, ""), condition = identity), "condition")
> > > }
> > >
> > > That's pretty hefty/inscrutable for such a simple validation. I see a
> > > variety of similar approaches in CRAN packages [1], all slightly
> > > different. It would be good for R to expose a "canonical" way to run
> > > this validation.
> > >
> > > At root, the problem is that R does not expose the regex compilation
> > > routines like 'tre_regcomp', so from the R side we have to resort to
> > > hacky approaches.
> > >
> > > Hi Michael,
> > >
> > > I don't think you need compilation functions for that. If a regular
> > > expression is found invalid by a specific third party library R uses, the
> > > library should return and error to R and R should return an error to you,
> > > and you should probably propagate that to your users. Grepping an empty
> > > string might work in many cases as a test, but it is probably more 
> > > portable
> > > to simply be prepared to propagate such errors from the actual use on real
> > > inputs. In theory, there could be some optimization for a particular case,
> > > the checking may not be the same - but that is the same say for 
> > > compilation
> > > and checking.
> > >
> > > Things get slightly complicated by encoding/useBytes modes
> > > (tre_regwcomp, tre_regncomp, tre_regwncomp, tre_regcompb,
> > > tre_regncompb; all in tre.h), but all are already present in other
> > > regex routines, so this is doable.
> > >
> > > Re encodings, simply R strings should be valid in their encoding. This is
> > > not just for regular expressions but also for anything else. You shouldn't
> > > assume that R can handle invalid strings in any reasonable way. Definitely
> > > you shouldn't try adding invalid strings in tests - behavior with invalid
> > > strings is unspecified. To test whether a string is valid, there is
> > > validEnc() (or validUTF8()). But, again, it is probably safest to 
> > > propagate
> > > errors from the 

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

[Reed A. Cartwright]

Also the most recent source code tested by CRAN is here:

https://github.com/reedacartwright/rbedrock/tree/v0.3.1

On Wed, Oct 11, 2023 at 7: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/2023, at 9:37 AM, Reed A. Cartwright 
>>> wrote:
>>> >
>>> > I was unable to reproduce the error on the rhub's clang17 docker image.
>>> >
>>> > I notice that the linking command is slightly different between
>>> systems.
>>> > And this suggests that I need to find some way to get CRAN to pass
>>> -stdlib
>>> > flag at the linking stage.
>>> >
>>> > CRAN:
>>> > /usr/local/clang17/bin/clang++ -std=gnu++17 -shared
>>> > -L/usr/local/clang/lib64 -L/usr/local/clang17/lib
>>> -L/usr/local/gcc13/lib64
>>> > -L/usr/local/lib64 -o rbedrock.so actors.o bedrock_leveldb.o dummy.o
>>> init.o
>>> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
>>> > -pthread -lleveldb -lz
>>> >
>>> > RHUB:
>>> > clang++-17 -stdlib=libc++ -std=gnu++14 -shared -L/opt/R/devel/lib/R/lib
>>> > -L/usr/local/lib -o rbedrock.so actors.o bedrock_leveldb.o dummy.o
>>> init.o
>>> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
>>> > -pthread -lleveldb -lz -L/opt/R/devel/lib/R/lib -lR
>>> >
>>> > On Wed, Sep 27, 2023 at 11:36 AM Gábor Csárdi 
>>> > wrote:
>>> >
>>> >> You might be able to reproduce it with the clang17 container here:
>>> >>
>>> >>
>>> https://urldefense.com/v3/__https://r-hub.github.io/containers/__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoLqhhk9c$
>>> >> You can either run it directly or with the rhub2 package:
>>> >>
>>> >>
>>> https://urldefense.com/v3/__https://github.com/r-hub/rhub2*readme__;Iw!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoxPbUQlE$
>>> >>
>>> >> Gabor
>>> >>
>>> >> On Wed, Sep 27, 2023 at 8:29 PM Reed A. Cartwright
>>> >>  wrote:
>>> >>>

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

[Reed A. Cartwright]

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 
> 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/2023, at 9:37 AM, Reed A. Cartwright 
>> wrote:
>> >
>> > I was unable to reproduce the error on the rhub's clang17 docker image.
>> >
>> > I notice that the linking command is slightly different between systems.
>> > And this suggests that I need to find some way to get CRAN to pass
>> -stdlib
>> > flag at the linking stage.
>> >
>> > CRAN:
>> > /usr/local/clang17/bin/clang++ -std=gnu++17 -shared
>> > -L/usr/local/clang/lib64 -L/usr/local/clang17/lib
>> -L/usr/local/gcc13/lib64
>> > -L/usr/local/lib64 -o rbedrock.so actors.o bedrock_leveldb.o dummy.o
>> init.o
>> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
>> > -pthread -lleveldb -lz
>> >
>> > RHUB:
>> > clang++-17 -stdlib=libc++ -std=gnu++14 -shared -L/opt/R/devel/lib/R/lib
>> > -L/usr/local/lib -o rbedrock.so actors.o bedrock_leveldb.o dummy.o
>> init.o
>> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
>> > -pthread -lleveldb -lz -L/opt/R/devel/lib/R/lib -lR
>> >
>> > On Wed, Sep 27, 2023 at 11:36 AM Gábor Csárdi 
>> > wrote:
>> >
>> >> You might be able to reproduce it with the clang17 container here:
>> >>
>> >>
>> https://urldefense.com/v3/__https://r-hub.github.io/containers/__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoLqhhk9c$
>> >> You can either run it directly or with the rhub2 package:
>> >>
>> >>
>> https://urldefense.com/v3/__https://github.com/r-hub/rhub2*readme__;Iw!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoxPbUQlE$
>> >>
>> >> Gabor
>> >>
>> >> On Wed, Sep 27, 2023 at 8:29 PM Reed A. Cartwright
>> >>  wrote:
>> >>>
>> >>> My package, RBedrock, is now throwing an error when compiled against
>> >>> Clang17. The error log is here:
>> >>>
>> >>>
>> >>
>> https://urldefense.com/v3/__https://www.stats.ox.ac.uk/pub/bdr/clang17/rbedrock.log__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoNhThuZA$
>> >>>
>> 

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

[Toby Hocking]

Hi Michael, it sounds like you don't want to use a CRAN package for
this, but you may try re2, see below.

> grepl("(invalid","subject",perl=TRUE)
Error in grepl("(invalid", "subject", perl = TRUE) :
  invalid regular expression '(invalid'
In addition: Warning message:
In grepl("(invalid", "subject", perl = TRUE) :
  PCRE pattern compilation error
'missing closing parenthesis'
at ''

> grepl("(invalid","subject",perl=FALSE)
Error in grepl("(invalid", "subject", perl = FALSE) :
  invalid regular expression '(invalid', reason 'Missing ')''
In addition: Warning message:
In grepl("(invalid", "subject", perl = FALSE) :
  TRE pattern compilation error 'Missing ')''

> re2::re2_regexp("(invalid")
Error: missing ): (invalid

On Tue, Oct 10, 2023 at 7:57 AM Michael Chirico via R-devel
 wrote:
>
> > Grepping an empty string might work in many cases...
>
> That's precisely why a base R offering is important, as a surer way of
> validating in all cases. To be clear I am trying to directly access the
> results of tre_regcomp().
>
> > it is probably more portable to simply be prepared to propagate such
> errors from the actual use on real inputs
>
> That works best in self-contained calls -- foo(re) and we execute re inside
> foo().
>
> But the specific context where I found myself looking for a regex validator
> is more complicated (https://github.com/r-lib/lintr/pull/2225). User
> supplies a regular expression in a configuration file, only "later" is it
> actually supplied to grepl().
>
> Till now, we've done your suggestion -- just surface the regex error at run
> time. But our goal is to make it friendlier and fail earlier at "compile
> time" as the config is loaded, "long" before any regex is actually executed.
>
> At a bare minimum this is a good place to return a classed warning (say
> invalid_regex_warning) to allow finer control than tryCatch(condition=).
>
> On Mon, Oct 9, 2023, 11:30 PM Tomas Kalibera 
> wrote:
>
> >
> > On 10/10/23 01:57, Michael Chirico via R-devel wrote:
> >
> > It will be useful to package authors trying to validate input which is
> > supposed to be a valid regular expression.
> >
> > As near as I can tell, the only way we can do so now is to run any
> > regex function and check for the warning and/or condition to bubble
> > up:
> >
> > valid_regex <- function(str) {
> >   stopifnot(is.character(str), length(str) == 1L)
> >   !inherits(tryCatch(grepl(str, ""), condition = identity), "condition")
> > }
> >
> > That's pretty hefty/inscrutable for such a simple validation. I see a
> > variety of similar approaches in CRAN packages [1], all slightly
> > different. It would be good for R to expose a "canonical" way to run
> > this validation.
> >
> > At root, the problem is that R does not expose the regex compilation
> > routines like 'tre_regcomp', so from the R side we have to resort to
> > hacky approaches.
> >
> > Hi Michael,
> >
> > I don't think you need compilation functions for that. If a regular
> > expression is found invalid by a specific third party library R uses, the
> > library should return and error to R and R should return an error to you,
> > and you should probably propagate that to your users. Grepping an empty
> > string might work in many cases as a test, but it is probably more portable
> > to simply be prepared to propagate such errors from the actual use on real
> > inputs. In theory, there could be some optimization for a particular case,
> > the checking may not be the same - but that is the same say for compilation
> > and checking.
> >
> > Things get slightly complicated by encoding/useBytes modes
> > (tre_regwcomp, tre_regncomp, tre_regwncomp, tre_regcompb,
> > tre_regncompb; all in tre.h), but all are already present in other
> > regex routines, so this is doable.
> >
> > Re encodings, simply R strings should be valid in their encoding. This is
> > not just for regular expressions but also for anything else. You shouldn't
> > assume that R can handle invalid strings in any reasonable way. Definitely
> > you shouldn't try adding invalid strings in tests - behavior with invalid
> > strings is unspecified. To test whether a string is valid, there is
> > validEnc() (or validUTF8()). But, again, it is probably safest to propagate
> > errors from the regular expression R functions (in case the checks differ,
> > particularly for non-UTF-8), also, duplicating the encoding checks can be a
> > non-trivial overhead.
> >
> > If there was a strong need to have an automated way to somehow classify
> > specifically errors from the regex libraries, perhaps R could attach some
> > classes to them when the library tells.
> >
> > Tomas
> >
> > Exposing a function to compile regular expressions is common in other
> > languages, e.g. Go [2], Python [3], JavaScript [4].
> >
> > [1] 
> > https://github.com/search?q=lang%3AR+%2Fis%5Ba-zA-Z0-9._%5D*reg%5Ba-zA-Z0-9._%5D*ex.*%28%3C-%7C%3D%29%5Cs*function%2F+org%3Acran=code
> > [2] https://pkg.go.dev/regexp#Compile
> > [3] 

Re: [Rd] About FlexiBLAS in the R-admin docs

[George Ostrouchov]

I agree that the "R Installation and Administration" guide statement about 
FlexiBLAS needs an update. Standard R in CentOS Stream 9, which is now 
downstream from Fedora, gives the following result for Matrix products in 
sessionInfo():

> sessionInfo()
R version 4.3.1 (2023-06-16)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: CentOS Stream 9

Matrix products: default
BLAS/LAPACK: FlexiBLAS OPENBLAS-OPENMP;  LAPACK version 3.9.0
…

So OpenBLAS compiled with OpenMP is the default. FlexiBLAS (via the flexiblas 
package) is my favorite way to manage core use in multithreaded BLAS 
computations. It is also the default in the EasyBuild foss compiler toolchain 
for HPC clusters: https://docs.easybuild.io/common-toolchains/ 

What would be a good way to suggest or construct an update?

Best regards,
George


> Date: Wed, 27 Sep 2023 15:14:43 +0200
> From: =?UTF-8?Q?I=C3=B1aki_Ucar?= 
> To: "r-devel@r-project.org" 
> Subject: [Rd] About FlexiBLAS in the R-admin docs
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
> Not sure if this is the right place for this. The "R Installation and
> Administration" guide states:
> 
>> Apparently undocumented: FlexiBLAS on Fedora provides a complete LAPACK, but 
>> not the enhanced routines from ATLAS or OpenBLAS.
> 
> I'm not sure what this means. FlexiBLAS does provide 100% of BLAS and
> LAPACK, and if the active backend (say, OpenBLAS) implements an
> enhanced LAPACK routine, then the call is redirected to the backend.
> If the user switches to another backend and that routine is not
> available there, then the original LAPACK routine is dispatched
> instead.
> 
> Best,
> -- 
> Iñaki Úcar
> 


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] arm64 on Mac build fails due to problem with MPO.db

[Hervé Pagès]

Hi Matteo,

Thanks for letting us know.

FWIW the dependency on MPO.db is via clusterProfiler and DOSE.

Not directly addressing the issue but note that clusterProfiler is a 
heavy-weight dependency that triggers the loading of 120+ packages. All 
together, loading Moonlight2R with library(Moonlight2R) triggers the 
loading of 170+ packages which takes about 20 seconds.

Have you considered trying to make Moonlight2R dependencies lighter? For 
example it seems that the only thing that the package uses from 
clusterProfiler is clusterProfiler::bitr(), which is a simple 
convenience wrapper around AnnotationDbi::select() used inside your 
GSEA() function. I wonder if some of these deps could perhaps be moved 
from Imports to Suggests, with the hope to make library(Moonlight2R) 
lighter and faster.

Best,
H.

On 10/11/23 02:18, Matteo Tiberti via Bioc-devel wrote:
> Dear all,
>
> We are seeing a couple of build fails of our MoonlightR and 
> Moonlight2R packages in the devel (3.18) MacOS arm64 builder that seem 
> to be related to the MPO.db package. This is the error message we get:
>
> * installing to library 
> ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library’
> * installing *source* package ‘Moonlight2R’ ...
> ** using staged installation
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: Couldn't set cache size: file is not a database
> Use `cache_size` = NULL to turn off this warning.
> Warning: Couldn't set synchronous mode: file is not a database
> Use `synchronous` = NULL to turn off this warning.
> Error: .onLoad failed in loadNamespace() for 'MPO.db', details:
>  call: NULL
>  error: file is not a database
> Execution halted
> ERROR: lazy loading failed for package ‘Moonlight2R’
> * removing 
> ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/Moonlight2R’
>
> We don’t have MPO.db as an explicit requirement for our packages, and 
> it checks all green on its own build report. We poked around 3.18 
> MacOS arm64 build reports and saw several other packages with similar 
> failures (e.g. 
> miRspongeR
>  
> miRSM
>  
> MicrobiomeProfiler
>  
> EasyCellType
>  
> MetaPhOR
>  
> meshes
>  
> CBNplot
>  
> …) so we were wondering if there’s a more general problem with the 
> builder/set up or if there is a general solution to this. Suggestions 
> are welcome
>
> Thank you,
>
> Matteo Tiberti
>
> Danish Cancer Institute
> Strandboulevarden 49
> DK-2100 Copenhagen
> Telephone: +45 35 25 73 07
> – a part of the Danish Cancer Society
>
> [cid:image001.png@01D9FB90.6FE2D7A0]
>  
>
>
> www.cancer.dk | Our privacy 
> policy
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Question regarding CRAN submission with notes

[Duncan Murdoch]

The note says it contains "an installed version" of the package, 
presumably referring to your test package.


I think you shouldn't do that.  For a trivial package it might be true 
that the installed version is the same on all systems, but it won't 
continue to be as the installation code evolves.


What you could try is to include files that would let you install the 
test package into a library under tempdir().  Your tests would start by 
installing the test package there, then run the tests, then clean up 
afterwards.


It's possible the tests will still complain about that, in which case 
I'd go one step further back, and write a function to create the source 
package, rather than including it.  For example, have a file 
DESCRIPTION.txt which your test renames to DESCRIPTION, etc.


Duncan Murdoch



On 11/10/2023 3:06 a.m., Tony Wilkes wrote:

Dear all,

I'm trying to publish an R package to CRAN. Their checks come back with 2 NOTES. The first one is 
saying that the package is a new submission, and the second one is that there is a subdirectory 
with a package inside my package. Both notes are correct. I have explained in my submission 
comments that this is indeed a new submission. I also gave the following explanation for the second 
note in my submission comments: "There is 1 NOTE given by the R CMD check results. This is due 
to the fact that I have placed fake libraries with fake packages inside the 
"inst/tinytest/" folder. This was necessary to test the various import-system related 
functions in my package. As stated, these are fake packages, and only contain trivial functions of 
no consequence. These fake libraries with fake packages ONLY exist because it is necessary for 
proper and extensive unit testing, that is all."

They asked me to fix these notes a few days ago. I replied (politely) repeating 
my comments a few days ago. I have not heard back from CRAN since. I am 
assuming that I am missing something, but CRAN won't explain what exactly I am 
missing.

Here are the NOTES:
Windows: 
>
Status: 1 NOTE
Debian: 
>
Status: 2 NOTEs

More details are given in the directory:
>

Could anyone tell me what exactly I'm doing wrong? 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 CRAN submission with notes

[Uwe Ligges]

This is under discussion with the CRAN team now.

Best,
Uwe Ligges


On 11.10.2023 09:06, Tony Wilkes wrote:

Dear all,

I'm trying to publish an R package to CRAN. Their checks come back with 2 NOTES. The first one is 
saying that the package is a new submission, and the second one is that there is a subdirectory 
with a package inside my package. Both notes are correct. I have explained in my submission 
comments that this is indeed a new submission. I also gave the following explanation for the second 
note in my submission comments: "There is 1 NOTE given by the R CMD check results. This is due 
to the fact that I have placed fake libraries with fake packages inside the 
"inst/tinytest/" folder. This was necessary to test the various import-system related 
functions in my package. As stated, these are fake packages, and only contain trivial functions of 
no consequence. These fake libraries with fake packages ONLY exist because it is necessary for 
proper and extensive unit testing, that is all."

They asked me to fix these notes a few days ago. I replied (politely) repeating 
my comments a few days ago. I have not heard back from CRAN since. I am 
assuming that I am missing something, but CRAN won't explain what exactly I am 
missing.

Here are the NOTES:
Windows: 
>
Status: 1 NOTE
Debian: 
>
Status: 2 NOTEs

More details are given in the directory:
>

Could anyone tell me what exactly I'm doing wrong? 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

[R-pkg-devel] Question regarding CRAN submission with notes

[Tony Wilkes]

Dear all,

I'm trying to publish an R package to CRAN. Their checks come back with 2 
NOTES. The first one is saying that the package is a new submission, and the 
second one is that there is a subdirectory with a package inside my package. 
Both notes are correct. I have explained in my submission comments that this is 
indeed a new submission. I also gave the following explanation for the second 
note in my submission comments: "There is 1 NOTE given by the R CMD check 
results. This is due to the fact that I have placed fake libraries with fake 
packages inside the "inst/tinytest/" folder. This was necessary to test the 
various import-system related functions in my package. As stated, these are 
fake packages, and only contain trivial functions of no consequence. These fake 
libraries with fake packages ONLY exist because it is necessary for proper and 
extensive unit testing, that is all."

They asked me to fix these notes a few days ago. I replied (politely) repeating 
my comments a few days ago. I have not heard back from CRAN since. I am 
assuming that I am missing something, but CRAN won't explain what exactly I am 
missing.

Here are the NOTES:
Windows: 
>
Status: 1 NOTE
Debian: 
>
Status: 2 NOTEs

More details are given in the directory:
>

Could anyone tell me what exactly I'm doing wrong? 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

[Bioc-devel] arm64 on Mac build fails due to problem with MPO.db

[Matteo Tiberti via Bioc-devel]

Dear all,

We are seeing a couple of build fails of our MoonlightR and Moonlight2R 
packages in the devel (3.18) MacOS arm64 builder that seem to be related to the 
MPO.db package. This is the error message we get:

* installing to library 
‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library’
* installing *source* package ‘Moonlight2R’ ...
** using staged installation
** R
** data
** inst
** byte-compile and prepare package for lazy loading
Warning: Couldn't set cache size: file is not a database
Use `cache_size` = NULL to turn off this warning.
Warning: Couldn't set synchronous mode: file is not a database
Use `synchronous` = NULL to turn off this warning.
Error: .onLoad failed in loadNamespace() for 'MPO.db', details:
 call: NULL
 error: file is not a database
Execution halted
ERROR: lazy loading failed for package ‘Moonlight2R’
* removing 
‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/Moonlight2R’

We don’t have MPO.db as an explicit requirement for our packages, and it checks all green on its own build report. We 
poked around 3.18 MacOS arm64 build reports and saw several other packages with similar failures (e.g. 
miRspongeR 
miRSM 
MicrobiomeProfiler 
EasyCellType 
MetaPhOR 
meshes 
CBNplot …) so we were wondering if 
there’s a more general problem with the builder/set up or if there is a general solution to this. Suggestions are welcome

Thank you,

Matteo Tiberti

Danish Cancer Institute
Strandboulevarden 49
DK-2100 Copenhagen
Telephone: +45 35 25 73 07
– a part of the Danish Cancer Society

[cid:image001.png@01D9FB90.6FE2D7A0]

www.cancer.dk | Our privacy 
policy

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Ivan Krylov]

В 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 in https://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? 

-- 
Best regards,
Ivan

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