[Bioc-devel] cliqueMS request for undeprecation as all errors have been fixed

[Oriol Senan Campos]

Dear Bioconductor Core Team,

I am the maintainer of cliqueMS. The package was flagged to deprecation 
but I have been able to fix the error that was causing the failure in 
the checks. I just had to remove a dependency that is no longer on CRAN 
and replace for a package available there. After checks and passing all 
the test I could find another dependency that does a similar 
calculation. I already pushed to Bioc devel (3.18 I cannot make any more 
commits). So please remove cliqueMS from the list of deprecated packages 
for 3.19. Tomorrow we will see a new build and I expect all OS and hosts 
to pass.


Kind Regards,
Oriol Senan

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

Re: [R-pkg-devel] Some, but not all vignettes compressed

[Ivan Krylov via R-package-devel]

В Thu, 25 Apr 2024 11:54:49 -0700
Bryan Hanson  пишет:

> So my version of gs blows things up!

The relatively good news is that GhostScript is not solely to blame. A
fresh build of "GPL Ghostscript 10.03.0 (2024-03-06)" was able to
reduce the files to 16..70% of their original size on my computer. But
I just typed ./configure && make and relied on the dependencies already
present on my system.

We can try to compare the build settings (which will involve compiling
things by hand) or ask the Homebrew people [*] (and they will probably
ask for a PDF file and a specific command line that works on some
builds of gs-10.03.0 but not with Homebrew).

What would you rather do?

qpdf, on the other hand, results in no size reduction (99.7% or worse),
just like on your system.

-- 
Best regards,
Ivan

[*]
https://docs.brew.sh/Troubleshooting
https://github.com/Homebrew/homebrew-core/issues?q=ghostscript

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

Re: [R-pkg-devel] Some, but not all vignettes compressed

[Bryan Hanson]

Thank you so much Ivan for investigating.  I didn’t even notice the *increase*! 
 The results of the tests you requested are very interesting:

R > tools::compactPDF("doc", gs_quality = "none", verbose = TRUE)
qs_quality="none" : use_gs=FALSE, use_qpdf=TRUE
#{pdf}s = length(paths) = 8
- doc/Vig_01_Start_Here.pdf:  only qpdf: res=0; 
==> (new=45281)/(old=45281) = 1 .. not worth using
- doc/Vig_02_Conceptual_Intro_PCA.pdf:  only qpdf: res=0; 
==> (new=441808)/(old=442464) = 0.998517 .. not worth using
- doc/Vig_03_Step_By_Step_PCA.pdf:  only qpdf: res=0; 
==> (new=422940)/(old=423750) = 0.998088 .. not worth using
- doc/Vig_04_Scores_Loadings.pdf:  only qpdf: res=0; 
==> (new=342335)/(old=341955) = 1.00111 .. not worth using
- doc/Vig_05_Visualizing_PCA_3D.pdf:  only qpdf: res=0; 
==> (new=692950)/(old=693206) = 0.999631 .. not worth using
- doc/Vig_06_Math_Behind_PCA.pdf:  only qpdf: res=0; 
==> (new=571600)/(old=571761) = 0.999718 .. not worth using
- doc/Vig_07_Functions_PCA.pdf:  only qpdf: res=0; 
==> (new=389451)/(old=389747) = 0.999241 .. not worth using
- doc/Vig_08_Notes.pdf:  only qpdf: res=0; 
==> (new=39131)/(old=39131) = 1 .. not worth using

Looks like my version of qpdf (which I think shipped with R) can’t reduce the 
sizes.

R > tools::compactPDF("doc", gs_quality = "ebook", gs_cmd = 
"/opt/homebrew/bin/gs", verbose = TRUE, qpdf = "")
qs_quality="ebook" : use_gs=TRUE, use_qpdf=FALSE
#{pdf}s = length(paths) = 8
- doc/Vig_01_Start_Here.pdf:gs: res=0; 
==> (new=50865)/(old=45281) = 1.12332 .. not worth using
- doc/Vig_02_Conceptual_Intro_PCA.pdf:gs: res=0; 
==> (new=1.00061e+07)/(old=442464) = 22.6146 .. not worth using
- doc/Vig_03_Step_By_Step_PCA.pdf:gs: res=0; 
==> (new=5.76371e+06)/(old=423750) = 13.6017 .. not worth using
- doc/Vig_04_Scores_Loadings.pdf:gs: res=0; 
==> (new=5.41358e+06)/(old=341955) = 15.8312 .. not worth using
- doc/Vig_05_Visualizing_PCA_3D.pdf:gs: res=0; 
==> (new=1.23619e+07)/(old=693206) = 17.833 .. not worth using
- doc/Vig_06_Math_Behind_PCA.pdf:gs: res=0; 
==> (new=818313)/(old=571761) = 1.43122 .. not worth using
- doc/Vig_07_Functions_PCA.pdf:gs: res=0; 
==> (new=1.36534e+06)/(old=389747) = 3.50315 .. not worth using
- doc/Vig_08_Notes.pdf:gs: res=0; 
==> (new=41780)/(old=39131) = 1.0677 .. not worth using

So my version of gs blows things up!

Also modified the above using gs_quality = “printer” or “screen” and the 
results are very similar.

Bryan


> On Apr 25, 2024, at 11:26 AM, Ivan Krylov  wrote:
> 
> В Thu, 25 Apr 2024 08:54:41 -0700
> Bryan Hanson  пишет:
> 
>>  'gs+qpdf' made some significant size reductions:
>> compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb
>> compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb
>> compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb
>> compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb
>> compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb
> 
> I'm getting similar (but not same) results on Debian Stable, gs 10.00.0
> & qpdf 11.3.0:
> 
> # R CMD build --no-resave-data --compact-vignettes=both
>compacted ‘Vig_01_Start_Here.pdf’ from 244Kb to 45Kb   
>compacted ‘Vig_02_Conceptual_Intro_PCA.pdf’ from 432Kb to 143Kb
>compacted ‘Vig_03_Step_By_Step_PCA.pdf’ from 411Kb to 100Kb
>compacted ‘Vig_04_Scores_Loadings.pdf’ from 335Kb to 78Kb  
>compacted ‘Vig_05_Visualizing_PCA_3D.pdf’ from 679Kb to 478Kb  
>compacted ‘Vig_06_Math_Behind_PCA.pdf’ from 556Kb to 145Kb 
>compacted ‘Vig_07_Functions_PCA.pdf’ from 378Kb to 89Kb
>compacted ‘Vig_08_Notes.pdf’ from 239Kb to 39Kb
> 
> 
>> - doc/Vig_01_Start_Here.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=49942)/(old=45101) = 1.10734 .. not worth using  
>> - doc/Vig_02_Conceptual_Intro_PCA.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using  
>> - doc/Vig_03_Step_By_Step_PCA.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using  
>> - doc/Vig_04_Scores_Loadings.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using  
>> - doc/Vig_05_Visualizing_PCA_3D.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using  
>> - doc/Vig_06_Math_Behind_PCA.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=816690)/(old=571493) = 1.42905 .. not worth using  
>> - doc/Vig_07_Functions_PCA.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using  
>> - doc/Vig_08_Notes.pdf:gs: res=0;  + qpdf: res=0; 
>>==> (new=40919)/(old=38953) = 1.05047 .. not worth using  
> 
> Thank you for providing this data! Somehow, instead of compacting the
> PDFs, one of the tools manages to blow them up in size, as much as ~23
> times.

Re: [R-pkg-devel] Some, but not all vignettes compressed

[Ivan Krylov via R-package-devel]

В Thu, 25 Apr 2024 08:54:41 -0700
Bryan Hanson  пишет:

>   'gs+qpdf' made some significant size reductions:
>  compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb
>  compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb
>  compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb
>  compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb
>  compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb

I'm getting similar (but not same) results on Debian Stable, gs 10.00.0
& qpdf 11.3.0:

# R CMD build --no-resave-data --compact-vignettes=both
compacted ‘Vig_01_Start_Here.pdf’ from 244Kb to 45Kb   
compacted ‘Vig_02_Conceptual_Intro_PCA.pdf’ from 432Kb to 143Kb
compacted ‘Vig_03_Step_By_Step_PCA.pdf’ from 411Kb to 100Kb
compacted ‘Vig_04_Scores_Loadings.pdf’ from 335Kb to 78Kb  
compacted ‘Vig_05_Visualizing_PCA_3D.pdf’ from 679Kb to 478Kb  
compacted ‘Vig_06_Math_Behind_PCA.pdf’ from 556Kb to 145Kb 
compacted ‘Vig_07_Functions_PCA.pdf’ from 378Kb to 89Kb
compacted ‘Vig_08_Notes.pdf’ from 239Kb to 39Kb

 
> - doc/Vig_01_Start_Here.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=49942)/(old=45101) = 1.10734 .. not worth using  
> - doc/Vig_02_Conceptual_Intro_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using  
> - doc/Vig_03_Step_By_Step_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using  
> - doc/Vig_04_Scores_Loadings.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using  
> - doc/Vig_05_Visualizing_PCA_3D.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using  
> - doc/Vig_06_Math_Behind_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=816690)/(old=571493) = 1.42905 .. not worth using  
> - doc/Vig_07_Functions_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using  
> - doc/Vig_08_Notes.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=40919)/(old=38953) = 1.05047 .. not worth using  

Thank you for providing this data! Somehow, instead of compacting the
PDFs, one of the tools manages to blow them up in size, as much as ~23
times.

Can you try tools::compactPDF() separately with gs_quality = 'none'
(isolating qpdf) and with qpdf = '' (isolating GhostScript)?

If the culprit turns out to be GhostScript, it may be due to their
rewritten PDF rendering engine (now in C instead of PostScript with
special extensions) not being up to par when the PDF file needs to be
compressed. If it turns out to be qpdf, we might have to extract the
exact command lines and compare results further.

-- 
Best regards,
Ivan

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

Re: [Bioc-devel] Build errors related to the new pwalign package

[Hervé Pagès]

I forgot to mention that the BLOSUM and PAM substitution matrices have 
also moved from Biostrings to the new pwalign package.

37 software packages were affected by this move (see list below). All of 
them have been fixed. If you maintain one of them, please resync your 
GitHub repo with the repo at git.bioconductor.org.

Let me know if you have any questions.

Cheers,

H.

List of software packages that were affected by the Biostrings/pwalign 
split (in alphabetical order):

amplican
ChIPpeakAnno
ClustIRR
CNEr
crisprShiny
DECIPHER
DominoEffect
enhancerHomologSearch
girafe
GUIDEseq
hiReadsProcessor
HTSeqGenie
idpr
IMMAN
iPAC
IsoformSwitchAnalyzeR
LinTInd
MethTargetedNGS
methylscaper
motifbreakR
msa
MSA2dist
openPrimeR
QSutils
QuartPAC
R453Plus1Toolbox
Rcpi
RSVSim
sangeranalyseR
sangerseqR
scanMiR
ShortRead
SPLINTER
StructuralVariantAnnotation
svaNUMT
TFBSTools
XNAString


On 4/24/24 09:52, Hervé Pagès wrote:
>
> Hi developers,
>
> pairwiseAlignement() and stringDist() have recently moved from 
> Biostrings to the new pwalign package. This is causing a number of 
> failures today on the 3.19 report. Since yesterday I've been actively 
> repairing packages affected by this by pushing fixes to 
> git.bioconductor.org. Most packages are now fixed but this won't 
> reflect before tomorrow's report.
>
> Later in the day I'll send emails to the maintainers of packages that 
> I have touched and ask them to resync their GitHub repos with 
> git.bioconductor.org.
>
> Sorry for the inconvenience.
>
> Let me know if you have any questions.
>
> Best,
>
> H.
>
> -- 
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com

-- 
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: [Rd] [External] Re: Is ALTREP "non-API"?

[Kevin Ushey]

On Thu, Apr 25, 2024 at 4:24 AM Ivan Krylov via R-devel
 wrote:
>
> On Wed, 24 Apr 2024 15:31:39 -0500 (CDT)
> luke-tierney--- via R-devel  wrote:
>
> > We would be better off (in my view, not necessarily shared by others
> > in R-core) if we could get to a point where:
> >
> >  all entry points listed in installed header files can be used in
> >  packages, at least with some caveats;
> >
> >  the caveats are expressed in a standard way that is searchable,
> >  e.g. with a standardized comment syntax at the header file or
> >  individual declaration level.
>
> This sounds almost like Doxygen, although the exact syntax used to
> denote the entry points and the necessary comments is far from the most
> important detail at this point.

I'm guessing Doxygen would be overkill here? I think instead these
would just be structured comments that mark a particular function, or
set of functions, as part of the API -- and some automated tool could
then just pull those functions out into a list of API functions. Then,
we would have a single "source of truth" for what is in the API, and
could be seen at a glance by browsing / grepping the installed R
headers. I see this as a structured way of accomplishing what is
already being done to clarify whether functions are part of the API in
the R headers.

A similar approach would have macros like R_API, or with a bit more
specificity, maybe something like R_API(ALTREP), which would have no
actual definition -- they would exist in the source purely to mark
functions as part of (some subset of) the API. Or, similarly, anything
declared within a block like R_API {} would be considered part of the
API (to avoid the need to tag every declaration individually.) This
would at least make it easy to figure out what functions are part of
the R API, without requiring too much extra maintenance effort from
the R maintainers.

The other alternative I could imagine would be an installed header
like R_ext/API.h, which package authors who want to submit packages to
CRAN would be required to use, with direct usage of other headers
eventually being phased out. But that would be a larger maintenance
burden, unless its generation could be automated (e.g. from the
functions tagged above).

As a side note, it's worth stating that the set of API endpoints that
R Core wants to make available to CRAN packages, versus those that are
intended for other usages (e.g. applications embedding R), are
different sets. But I suspect this discussion is most relevant to R
package authors who wish to submit their packages to CRAN.

> > There are some 500 entry points in the R shared library that are in
> > the installed headers but not mentioned in WRE. These would need to
> > be reviewed and adjusted.
>
> Is there a way for outsiders to help? For example, would it help to
> produce the linking graph (package P links to entry points X, Y)? I
> understand that an entry point being unpopular doesn't mean it
> shouldn't be public (and the other way around), but combined with a
> list of entry points that are listed in WRE, such a graph could be
> useful to direct effort or estimate impact from interface changes.

I'm guessing the most welcome kinds of contributions would be
documentation? IMHO, "documenting an API" and "describing how an API
can be used" are somewhat separate endeavors. I believe R-exts does an
excellent job of the latter, but may not be the right vehicle for the
former. To that end, I believe it would be helpful to have some
structured API documentation as a separate R-api document. Each
documented function would have described inputs, outputs, whether
inputs + outputs require protection from the garbage collector, and
other important usage notes. This is something that I think could be
developed and maintained by community members, with members of the R
community submitting documentation for each of the available API
functions. Such an effort could be started independently from R Core,
but some guidance would be appreciated as far as (1) would such a
document eventually be accepted as part of the official R manuals, and
(2) if so, what would be required of such a document.

> --
> Best regards,
> Ivan
>
> __
> 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] Question regarding .make_numeric_version with non-character input

[Hervé Pagès]

On 4/25/24 07:04, Kurt Hornik wrote:

...
> Sure, I'll look into adding something.  (Too late for 4.4.0, of course.)
>
> Best
> -k

Great. Thanks!

H.

-- 
Hervé Pagès

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

[[alternative HTML version deleted]]

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

[R-pkg-devel] Some, but not all vignettes compressed

[Bryan Hanson]

I have a peculiar problem regarding vignette compaction. Package LearnPCA has 8 
vignettes.  I am working on the devel branch with code at 
https://github.com/bryanhanson/LearnPCA/tree/devel.

The problem is that at CRAN and on win-builder they detect that 5/8 vignettes 
need to be compacted.  Locally however, 2/8 vignettes, not overlapping with the 
5/8 identified at CRAN, are compacted during build.  When I try to compact 
manually, compactPDF() reports it is not necesssary.

I have looked at a related question by Ben Bolker 
(https://stat.ethz.ch/pipermail/r-package-devel/2020q4/006086.html) but that 
doesn't seem resolved.  I am already taking the steps listed in this question: 
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009831.html as well as 
several others.

Regarding versions, I get

gs --version
10.03.0

qpdf --version
qpdf version 11.9.0

Which seem to be the latest.  Note these were installed with HomeBrew but I 
think R ships with at its own version of qpdf:

Sys.which(Sys.getenv("R_QPDF", "qpdf"))
  /Library/Frameworks/R.framework/Resources/bin/qpdf 
"/Library/Frameworks/R.framework/Resources/bin/qpdf" 

I did not try the HomeBrew versions until I ran into trouble.

Here are the steps I am taking.  I am on MacOS 14.4.1, an M1 chip.

1. Build via a makefile, with this command:

R --no-init-file CMD build --resave-data --compact-vignettes=both $(PKG_NAME)

The build process reports:

* creating vignettes ... OK
* compacting vignettes and other PDF files
compacted ‘Vig_01_Start_Here.pdf’ from 244Kb to 44Kb
compacted ‘Vig_08_Notes.pdf’ from 239Kb to 38Kb 

Fine so far.

I also tried to force the path to gs:

export R_GSCMD="/opt/homebrew/bin/gs"; \
export GS_QUALITY="ebook"; \
R --no-init-file CMD build --resave-data --compact-vignettes=both $(PKG_NAME)

With the same result.  I did this because it seems R doesn't see my 
installation of GhostScript.

And I tried to force a path to both compacting services:

export R_GSCMD="/opt/homebrew/bin/gs"; \
export GS_QUALITY="ebook"; \
export R_QPDF="/opt/homebrew/bin/qpdf"; \
R --no-init-file CMD build --resave-data --compact-vignettes=both $(PKG_NAME)

With the same results.

2. Submit to win-builder (same result seen on actual CRAN submission).  The 
(partial) report is:

* checking sizes of PDF files under 'inst/doc' ... WARNING
  'gs+qpdf' made some significant size reductions:
 compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb
 compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb
 compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb
 compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb
 compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb
  consider running tools::compactPDF(gs_quality = "ebook") on these files,
  or build the source package with --compact-vignettes=both

Note that these are *different* vignettes than those compacted during build, so 
build seems to have missed some (?).

3. If I expand the tarball locally, point to the inst directory, and run

tools::compactPDF("doc", gs_quality = "ebook", gs_cmd = "/opt/homebrew/bin/gs", 
verbose = TRUE)

I get this:

qs_quality="ebook" : use_gs=TRUE, use_qpdf=TRUE
#{pdf}s = length(paths) = 8
- doc/Vig_01_Start_Here.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=49942)/(old=45101) = 1.10734 .. not worth using
- doc/Vig_02_Conceptual_Intro_PCA.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using
- doc/Vig_03_Step_By_Step_PCA.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using
- doc/Vig_04_Scores_Loadings.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using
- doc/Vig_05_Visualizing_PCA_3D.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using
- doc/Vig_06_Math_Behind_PCA.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=816690)/(old=571493) = 1.42905 .. not worth using
- doc/Vig_07_Functions_PCA.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using
- doc/Vig_08_Notes.pdf:gs: res=0;  + qpdf: res=0; 
==> (new=40919)/(old=38953) = 1.05047 .. not worth using

Any suggestions as to what is going on here and how to fix it?

sessionInfo():

R version 4.4.0 RC (2024-04-16 r86468)
Platform: aarch64-apple-darwin20
Running under: macOS Sonoma 14.4.1

Matrix products: default
BLAS:   
/Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRblas.0.dylib
 
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib;
  LAPACK version 3.12.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Phoenix
tzcode source: internal

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

loaded via a namespace (and not attached):
 [1] foghorn_1.5.2utf8_1.2.4   

Re: [Rd] Big speedup in install.packages() by re-using connections

[Ivan Krylov via R-devel]

On Thu, 25 Apr 2024 14:45:04 +0200
Jeroen Ooms  wrote:

> Thoughts?

How verboten would it be to create an empty external pointer object,
add it to the preserved list, and set an on-exit finalizer to clean up
the curl multi-handle? As far as I can tell, the internet module is not
supposed to be unloaded, so this would not introduce an opportunity to
jump to an unmapped address. This makes it possible to avoid adding a
CurlCleanup() function to the internet module:

Index: src/modules/internet/libcurl.c
===
--- src/modules/internet/libcurl.c  (revision 86484)
+++ src/modules/internet/libcurl.c  (working copy)
@@ -55,6 +55,47 @@
 
 static int current_timeout = 0;
 
+// The multi-handle is shared between downloads for reusing connections
+static CURLM *shared_mhnd = NULL;
+static SEXP mhnd_sentinel = NULL;
+
+static void cleanup_mhnd(SEXP ignored)
+{
+if(shared_mhnd){
+curl_multi_cleanup(shared_mhnd);
+shared_mhnd = NULL;
+}
+curl_global_cleanup();
+}
+static void rollback_mhnd_sentinel(void* sentinel) {
+// Failed to allocate memory while registering a finalizer,
+// therefore must release the object
+R_ReleaseObject((SEXP)sentinel);
+}
+static CURLM *get_mhnd(void)
+{
+if (!mhnd_sentinel) {
+  SEXP sentinel = PROTECT(R_MakeExternalPtr(NULL, R_NilValue, R_NilValue));
+  R_PreserveObject(sentinel);
+  UNPROTECT(1);
+  // Avoid leaking the sentinel before setting the finalizer
+  RCNTXT cntxt;
+  begincontext(, CTXT_CCODE, R_NilValue, R_BaseEnv, R_BaseEnv,
+   R_NilValue, R_NilValue);
+  cntxt.cend = _mhnd_sentinel;
+  cntxt.cenddata = sentinel;
+  R_RegisterCFinalizerEx(sentinel, cleanup_mhnd, TRUE);
+  // Succeeded, no need to clean up if endcontext() fails allocation
+  mhnd_sentinel = sentinel;
+  cntxt.cend = NULL;
+  endcontext();
+}
+if(!shared_mhnd) {
+  shared_mhnd = curl_multi_init();
+}
+return shared_mhnd;
+}
+
 # if LIBCURL_VERSION_MAJOR < 7 || (LIBCURL_VERSION_MAJOR == 7 && 
LIBCURL_VERSION_MINOR < 28)
 
 // curl/curl.h includes  and headers it requires.
@@ -565,8 +606,6 @@
if (c->hnd && c->hnd[i])
curl_easy_cleanup(c->hnd[i]);
 }
-if (c->mhnd)
-   curl_multi_cleanup(c->mhnd);
 if (c->headers)
curl_slist_free_all(c->headers);
 
@@ -668,7 +707,7 @@
c.headers = headers = tmp;
 }
 
-CURLM *mhnd = curl_multi_init();
+CURLM *mhnd = get_mhnd();
 if (!mhnd)
error(_("could not create curl handle"));
 c.mhnd = mhnd;


-- 
Best regards,
Ivan

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Hervé Pagès writes:

> On 4/24/24 23:07, Kurt Hornik wrote:
>>> Hervé Pagès writes:
>>> Hi Kurt,
>>> Is it intended that numeric_version() returns an error by default on
>>> non-character input in R 4.4.0?
>> Dear Herve, yes, that's the intention.
>> 
>>> It seems that I can turn this into a warning by setting
>>> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
>>> seem to be able to find any of this mentioned in the NEWS file.
>> That's what I added for smoothing the transition: it will be removed
>> from the trunk shortly.

> Thanks for clarifying.  Could this be documented in the NEWS file? This 
> is a breaking change (it breaks a couple of Bioconductor packages) and 
> people are not going to set this environment variable if they are not 
> aware of it.

Sure, I'll look into adding something.  (Too late for 4.4.0, of course.)

Best
-k

> Thanks again,

> H.

>> 
>> Best
>> -k
>> 
>>> Thanks,
>>> H.
>>> On 4/1/24 05:28, Kurt Hornik wrote:
>>> Andrea Gilardi via R-devel writes:
>> 
>>> Thanks: should be fixed now in the trunk.
>> 
>>> Best
>>> -k
>>> Thank you very much Dirk for your kind words and for confirming the bug.
>>> Next week I will open a new issue on Bugzilla adding the related patch.
>> 
>>> Kind regards
>> 
>>> Andrea
>> 
>>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>> 
>>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>> | Dear all,
>>> |
>>> | I have a question regarding the R-devel version of 
>>> .make_numeric_version() function. As far as I can understand, the current 
>>> code 
>>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>>  runs the following steps in case of non-character input:
>>> |
>>> | 1. It creates a message named msg using gettextf.
>>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>>> the following condition
>>> |
>>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>>> "false")
>>> |
>>> | However, I don't understand the previous code since the output of 
>>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
>>> is just a boolean value and tolower() will just return "true" or "false". 
>>> Maybe the intended code is 
>>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>>> "false" ? Or am I missing something?
>> 
>>> Yes, agreed -- good catch.  In full, the code is (removing leading
>>> whitespace, and putting it back onto single lines)
>> 
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") 
>>> != "false"))
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>>> where msg is constant (but reflecting language settings via standard i18n)
>>> and as you not the parentheses appear wrong.  What was intended is likely
>> 
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>>> != "false")
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>>> If you use bugzilla before and have a handle, maybe file a bug report with
>>> this as patch athttps://bugs.r-project.org/
>> 
>>> Dirk
>>> __
>>> 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
>> 
>>> -- 
>>> Hervé Pagès
>>> Bioconductor Core Team
>>> hpages.on.git...@gmail.com

> -- 
> Hervé Pagès

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

>   [[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: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> Hi Kurt,

> On 25 April 2024 at 08:07, Kurt Hornik wrote:
> | > Hervé Pagès writes:
> | 
> | > Hi Kurt,
> | > Is it intended that numeric_version() returns an error by default on
> | > non-character input in R 4.4.0? 
> | 
> | Dear Herve, yes, that's the intention.
> | 
> | > It seems that I can turn this into a warning by setting
> | > _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> | > seem to be able to find any of this mentioned in the NEWS file.
> | 
> | That's what I added for smoothing the transition: it will be removed
> | from the trunk shortly.

> I would actually be nice to have a more robust variant for non-CRAN
> versions. For example I just had to do a local hack to be able to use
> what the QuantLib 'rc' 1.34-rc reported (when I then used to R
> facilities to condition code and tests on whether I was dealing with
> code before or after an API transition).  So as a wishlist: could you
> envision an extension to package_version() casting that, say, removes
> all [a-zA-Z]+ first (if opted into) ?

Well, if I could turn back time and start again, I'd implement package
versions in the Debian way, and not numeric only.  As you know, the
current approach does not conveniently allow for handling binary
revisions or NMUs.

Currently, package_version extends numeric_version, but in principle
that could be changed: we would of course have to ensure that we go on
using numeric-only package versions for source packages so that older
versions of R can handle these.

One could in principle also enhance the 'strict' argument so that
e.g. strict = NA says drop all non-numeric non-sep parts, but it would
be better to first figure out whether it wouldn't be better to make
things work for non-numeric version components too :-)

Best
-k



> Dirk

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

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

Re: [Rd] [External] View() segfaulting ...

[Ben Bolker]

  A clean build solves it for me too. Thank you!
  (I need to add this to my "have you tried turning it off and back on 
again?" list ...)


  Ben


On 2024-04-25 8:07 a.m., luke-tier...@uiowa.edu wrote:

I saw it also on some of my Ubuntu builds, but the issue went away
after a make clean/make, so maybe give that a try.

Best,

luke

On Wed, 24 Apr 2024, Ben Bolker wrote:

 I'm using bleeding-edge R-devel, so maybe my build is weird. Can 
anyone else reproduce this?


 View() seems to crash on just about anything.

View(1:3)
*** stack smashing detected ***: terminated
Aborted (core dumped)

 If I debug(View) I get to the last line of code with nothing 
obviously looking pathological:


Browse[1]>
debug: invisible(.External2(C_dataviewer, x, title))
Browse[1]> x
$x
[1] "1" "2" "3"

Browse[1]> title
[1] "Data: 1:3"
Browse[1]>
*** stack smashing detected ***: terminated
Aborted (core dumped)




R Under development (unstable) (2024-04-24 r86483)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS

Matrix products: default
BLAS/LAPACK: 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so; 
LAPACK version 3.10.0


locale:
[1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8    LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=en_CA.UTF-8    LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8   LC_NAME=C
[9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C

time zone: America/Toronto
tzcode source: system (glibc)

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.5.0

__
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] Big speedup in install.packages() by re-using connections

[Jeroen Ooms]

I'd like to raise this again now that 4.4 is out.

Below is a more complete patch which includes a function to properly
cleanup libcurl when R quits. Implementing this is a little tricky
because libcurl is a separate "module" in R, perhaps there is a better
way, but this works:

  view: https://github.com/r-devel/r-svn/pull/166/files
  patch: https://github.com/r-devel/r-svn/pull/166.diff

The old patch is still there as well, which is meant a minimal proof
of concept to test the performance gains for reusing the connection:

  view: https://github.com/r-devel/r-svn/pull/155/files
  patch: https://github.com/r-devel/r-svn/pull/155.diff

Performance gains are greatest on high-bandwidth servers when
downloading many files from the same server (e.g. packages from a cran
mirror). In such cases, currently over 90% of the total time is spent
on initiating and tearing town a separate SSL connection for each file
download.

Thoughts?



On Sat, Mar 2, 2024 at 3:07 PM Jeroen Ooms  wrote:
>
> Currently download.file() creates and terminates a new TLS connection
> for each download. This creates a lot of overhead which is expensive
> for both client and server (in particular the TLS handshake). Modern
> internet clients (including browsers) re-use connections for many http
> requests.
>
> We can do this in R by creating a persistent libcurl "multi-handle".
> The R libcurl implementation already uses a multi-handle, however it
> destroys it after each download, which defeats the purpose. The
> purpose of the multi-handle is to keep it alive and let libcurl
> maintain a persistent connection pool. This is particularly relevant
> for install.packages() which needs to download many files from one and
> the same server.
>
> Here is a bare minimal proof of concept patch that re-uses one and the
> same multi-handle for all requests in R:
> https://github.com/r-devel/r-svn/pull/155/files
>
> Some quick benchmarking shows that this can lead to big speedups for
> download.packages() on high-bandwidth servers (such as CI). This quick
> test to download 100 packages from CRAN showed more than 10x speedup
> for me: https://github.com/r-devel/r-svn/pull/155
>
> Moreover, I think this may make install.packages() more robust. In CI
> build logs that download many packages, I often see one or two
> downloads randomly failing with a TLS-connect error. I am hopeful this
> problem will disappear when using a single connection to the CRAN
> server to download all the packages.

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Dirk Eddelbuettel]

Hi Kurt,

On 25 April 2024 at 08:07, Kurt Hornik wrote:
| > Hervé Pagès writes:
| 
| > Hi Kurt,
| > Is it intended that numeric_version() returns an error by default on
| > non-character input in R 4.4.0? 
| 
| Dear Herve, yes, that's the intention.
| 
| > It seems that I can turn this into a warning by setting
| > _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
| > seem to be able to find any of this mentioned in the NEWS file.
| 
| That's what I added for smoothing the transition: it will be removed
| from the trunk shortly.

I would actually be nice to have a more robust variant for non-CRAN
versions. For example I just had to do a local hack to be able to use what
the QuantLib 'rc' 1.34-rc reported (when I then used to R facilities to
condition code and tests on whether I was dealing with code before or after
an API transition).  So as a wishlist: could you envision an extension to
package_version() casting that, say, removes all [a-zA-Z]+ first (if opted
into) ?

Dirk

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

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

Re: [Rd] [External] View() segfaulting ...

[luke-tierney--- via R-devel]

I saw it also on some of my Ubuntu builds, but the issue went away
after a make clean/make, so maybe give that a try.

Best,

luke

On Wed, 24 Apr 2024, Ben Bolker wrote:

 I'm using bleeding-edge R-devel, so maybe my build is weird. Can anyone 
else reproduce this?


 View() seems to crash on just about anything.

View(1:3)
*** stack smashing detected ***: terminated
Aborted (core dumped)

 If I debug(View) I get to the last line of code with nothing obviously 
looking pathological:


Browse[1]>
debug: invisible(.External2(C_dataviewer, x, title))
Browse[1]> x
$x
[1] "1" "2" "3"

Browse[1]> title
[1] "Data: 1:3"
Browse[1]>
*** stack smashing detected ***: terminated
Aborted (core dumped)




R Under development (unstable) (2024-04-24 r86483)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS

Matrix products: default
BLAS/LAPACK: 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so; LAPACK 
version 3.10.0


locale:
[1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=en_CA.UTF-8LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8   LC_NAME=C
[9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C

time zone: America/Toronto
tzcode source: system (glibc)

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.5.0

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu/

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

Re: [Rd] [External] Re: Is ALTREP "non-API"?

[Ivan Krylov via R-devel]

On Wed, 24 Apr 2024 15:31:39 -0500 (CDT)
luke-tierney--- via R-devel  wrote:

> We would be better off (in my view, not necessarily shared by others
> in R-core) if we could get to a point where:
> 
>  all entry points listed in installed header files can be used in
>  packages, at least with some caveats;
> 
>  the caveats are expressed in a standard way that is searchable,
>  e.g. with a standardized comment syntax at the header file or
>  individual declaration level.

This sounds almost like Doxygen, although the exact syntax used to
denote the entry points and the necessary comments is far from the most
important detail at this point.

> There are some 500 entry points in the R shared library that are in
> the installed headers but not mentioned in WRE. These would need to
> be reviewed and adjusted.

Is there a way for outsiders to help? For example, would it help to
produce the linking graph (package P links to entry points X, Y)? I
understand that an entry point being unpopular doesn't mean it
shouldn't be public (and the other way around), but combined with a
list of entry points that are listed in WRE, such a graph could be
useful to direct effort or estimate impact from interface changes.

-- 
Best regards,
Ivan

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

Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Ulrich Bodenhofer]

No, that’s absolutely fine. I actually had forgotten that substitution matrices 
were also used in the examples of msaMuscle(). Thanks for fixing!

Cheers, Ulrich


From: Hervé Pagès  
Sent: Thursday, April 25, 2024 10:11 AM
To: ulr...@bodenhofer.com
Cc: bioc-devel@r-project.org; 'Martin Grigorov' 
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

Good. I also just pushed 2 additional small tweaks (commits 0e98500 and 
84c8ed5) right after you pushed yours. Hopefully I didn't step on your toes.
H. 
On 4/25/24 01:04, Ulrich Bodenhofer wrote:
Great, thanks, Hervé! I also made two more fixes and pushed them.
 
Cheers, Ulrich
 
From: Hervé Pagès mailto:hpages.on.git...@gmail.com 
Sent: Thursday, April 25, 2024 9:52 AM
To: mailto:ulr...@bodenhofer.com
Cc: mailto:bioc-devel@r-project.org; 'Martin Grigorov' 
mailto:martin.grigo...@gmail.com
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
 
I'm done. Please resync you GitHub repo.
Best,
H. 
On 4/25/24 00:14, Ulrich Bodenhofer wrote:
Great, thanks, Hervé, so I’ll simply wait for the update. If there is anything 
I should do, just let me know.
 
Thanks and best regards,
Ulrich
 
 
From: Hervé Pagès mailto:hpages.on.git...@gmail.com 
Sent: Thursday, April 25, 2024 9:06 AM
To: mailto:ulr...@bodenhofer.com; 'Martin Grigorov' 
mailto:martin.grigo...@gmail.com
Cc: mailto:bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
 
Hi Ulrich,
Yes the substitution matrices are now in pwalign. I'm taking care of msa. Sorry 
for that.
Best, 
H. 
On 4/24/24 23:25, Ulrich Bodenhofer wrote:
Ah, thank you very much, sorry for having overlooked this! Yes, that seems the 
source of the problem. Hervé, should I wait for your update or rather change 
the package myself? The latter won’t be a problem for me. I suppose it is just 
about adding ‘pwalign’ as an additional dependency, right?
 
Thanks and best regards,
Ulrich
 
 
From: Martin Grigorov mailto:martin.grigo...@gmail.com 
Sent: Thursday, April 25, 2024 7:52 AM
To: mailto:ulr...@bodenhofer.com
Cc: mailto:bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
 
Hi,
 
Yesterday there was another email about Biostrings - 
https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
I thought it might be related to your problem.
 
Regards,
Martin
 
On Thu, Apr 25, 2024 at 8:23 AM Ulrich Bodenhofer 
mailto:ulrich.bodenho...@gmail.com wrote:
Dear colleagues, dear BioC core team,
 
One of my packages in the devel branch, the ‘msa’ package seems broken since
yesterday. The vignette does not run anymore (therefore, the package does
not build), and the reason is that the BLOSUM62 substitution matrix cannot
be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
package. In Version 2.70.3 in the release branch, the substitution matrices
were still in the ‘data/’ directory. In the current devel version 2.71.6,
they have disappeared. I found no hint to that in the NEWS file. So, I want
to kindly ask the maintainers of the ‘Biostrings’ package to give me some
advice how to fix that on my side or, in case that this is an error in the
current devel version of the ‘Biostrings’ package, to have a look into this.
 
Thanks a lot in advance, best regards,
Ulrich
 
___
mailto:Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Hervé Pagès

Bioconductor Core Team
mailto:hpages.on.git...@gmail.com
-- 
Hervé Pagès

Bioconductor Core Team
mailto:hpages.on.git...@gmail.com
-- 
Hervé Pagès

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

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

Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Hervé Pagès]

Good. I also just pushed 2 additional small tweaks (commits 0e98500 and 
84c8ed5) right after you pushed yours. Hopefully I didn't step on your toes.

H.

On 4/25/24 01:04, Ulrich Bodenhofer wrote:
>
> Great, thanks, Hervé! I also made two more fixes and pushed them.
>
> Cheers, Ulrich
>
> *From:*Hervé Pagès 
> *Sent:* Thursday, April 25, 2024 9:52 AM
> *To:* ulr...@bodenhofer.com
> *Cc:* bioc-devel@r-project.org; 'Martin Grigorov' 
> 
> *Subject:* Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
>
> I'm done. Please resync you GitHub repo.
>
> Best,
>
> H.
>
> On 4/25/24 00:14, Ulrich Bodenhofer wrote:
>
> Great, thanks, Hervé, so I’ll simply wait for the update. If there
> is anything I should do, just let me know.
>
> Thanks and best regards,
>
> Ulrich
>
> *From:*Hervé Pagès 
> 
> *Sent:* Thursday, April 25, 2024 9:06 AM
> *To:* ulr...@bodenhofer.com; 'Martin Grigorov'
>  
> *Cc:* bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Biostrings: substitution matrices
> disappeared?
>
> Hi Ulrich,
>
> Yes the substitution matrices are now in pwalign. I'm taking care
> of msa. Sorry for that.
>
> Best,
>
> H.
>
> On 4/24/24 23:25, Ulrich Bodenhofer wrote:
>
> Ah, thank you very much, sorry for having overlooked this! Yes, that 
> seems the source of the problem. Hervé, should I wait for your update or 
> rather change the package myself? The latter won’t be a problem for me. I 
> suppose it is just about adding ‘pwalign’ as an additional dependency, right?
>
>   
>
> Thanks and best regards,
>
> Ulrich
>
>   
>
>   
>
> From: Martin Grigorov  
>   
>
> Sent: Thursday, April 25, 2024 7:52 AM
>
> To:ulr...@bodenhofer.com
>
> Cc:bioc-devel@r-project.org
>
> Subject: Re: [Bioc-devel] Biostrings: substitution matrices 
> disappeared?
>
>   
>
> Hi,
>
>   
>
> Yesterday there was another email about Biostrings 
> -https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
>
> I thought it might be related to your problem.
>
>   
>
> Regards,
>
> Martin
>
>   
>
> On Thu, Apr 25, 2024 at 8:23 AM Ulrich 
> Bodenhofer  
>   wrote:
>
> Dear colleagues, dear BioC core team,
>
>   
>
> One of my packages in the devel branch, the ‘msa’ package seems 
> broken since
>
> yesterday. The vignette does not run anymore (therefore, the package 
> does
>
> not build), and the reason is that the BLOSUM62 substitution matrix 
> cannot
>
> be loaded form the ‘Biostrings’ package anymore. I checked the 
> ‘Biostrings’
>
> package. In Version 2.70.3 in the release branch, the substitution 
> matrices
>
> were still in the ‘data/’ directory. In the current devel version 
> 2.71.6,
>
> they have disappeared. I found no hint to that in the NEWS file. So, 
> I want
>
> to kindly ask the maintainers of the ‘Biostrings’ package to give me 
> some
>
> advice how to fix that on my side or, in case that this is an error 
> in the
>
> current devel version of the ‘Biostrings’ package, to have a look 
> into this.
>
>   
>
> Thanks a lot in advance, best regards,
>
> Ulrich
>
>   
>
> ___
>
> mailto: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
>
> -- 
> Hervé Pagès
> Bioconductor Core Team
> hpages.on.git...@gmail.com

-- 
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: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Ulrich Bodenhofer]

Great, thanks, Hervé! I also made two more fixes and pushed them.

 

Cheers, Ulrich

 

From: Hervé Pagès  
Sent: Thursday, April 25, 2024 9:52 AM
To: ulr...@bodenhofer.com
Cc: bioc-devel@r-project.org; 'Martin Grigorov' 
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

 

I'm done. Please resync you GitHub repo.

Best,

H. 

On 4/25/24 00:14, Ulrich Bodenhofer wrote:

Great, thanks, Hervé, so I’ll simply wait for the update. If there is anything 
I should do, just let me know.

 

Thanks and best regards,

Ulrich

 

 

From: Hervé Pagès   
 
Sent: Thursday, April 25, 2024 9:06 AM
To: ulr...@bodenhofer.com  ; 'Martin Grigorov'  
 
Cc: bioc-devel@r-project.org  
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

 

Hi Ulrich,

Yes the substitution matrices are now in pwalign. I'm taking care of msa. Sorry 
for that.

Best, 

H. 

On 4/24/24 23:25, Ulrich Bodenhofer wrote:

Ah, thank you very much, sorry for having overlooked this! Yes, that seems the 
source of the problem. Hervé, should I wait for your update or rather change 
the package myself? The latter won’t be a problem for me. I suppose it is just 
about adding ‘pwalign’ as an additional dependency, right?
 
Thanks and best regards,
Ulrich
 
 
From: Martin Grigorov   
 
Sent: Thursday, April 25, 2024 7:52 AM
To: ulr...@bodenhofer.com  
Cc: bioc-devel@r-project.org  
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
 
Hi,
 
Yesterday there was another email about Biostrings - 
https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
I thought it might be related to your problem.
 
Regards,
Martin
 
On Thu, Apr 25, 2024 at 8:23 AM Ulrich Bodenhofer  
  wrote:
Dear colleagues, dear BioC core team,
 
One of my packages in the devel branch, the ‘msa’ package seems broken since
yesterday. The vignette does not run anymore (therefore, the package does
not build), and the reason is that the BLOSUM62 substitution matrix cannot
be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
package. In Version 2.70.3 in the release branch, the substitution matrices
were still in the ‘data/’ directory. In the current devel version 2.71.6,
they have disappeared. I found no hint to that in the NEWS file. So, I want
to kindly ask the maintainers of the ‘Biostrings’ package to give me some
advice how to fix that on my side or, in case that this is an error in the
current devel version of the ‘Biostrings’ package, to have a look into this.
 
Thanks a lot in advance, best regards,
Ulrich
 
___
mailto: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  

-- 
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: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Hervé Pagès]

I'm done. Please resync you GitHub repo.

Best,

H.

On 4/25/24 00:14, Ulrich Bodenhofer wrote:
>
> Great, thanks, Hervé, so I’ll simply wait for the update. If there is 
> anything I should do, just let me know.
>
> Thanks and best regards,
>
> Ulrich
>
> *From:*Hervé Pagès 
> *Sent:* Thursday, April 25, 2024 9:06 AM
> *To:* ulr...@bodenhofer.com; 'Martin Grigorov' 
> *Cc:* bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
>
> Hi Ulrich,
>
> Yes the substitution matrices are now in pwalign. I'm taking care of 
> msa. Sorry for that.
>
> Best,
>
> H.
>
> On 4/24/24 23:25, Ulrich Bodenhofer wrote:
>
> Ah, thank you very much, sorry for having overlooked this! Yes, that 
> seems the source of the problem. Hervé, should I wait for your update or 
> rather change the package myself? The latter won’t be a problem for me. I 
> suppose it is just about adding ‘pwalign’ as an additional dependency, right?
>
> Thanks and best regards,
>
> Ulrich
>
> From: Martin Grigorov  
>   
>
> Sent: Thursday, April 25, 2024 7:52 AM
>
> To:ulr...@bodenhofer.com
>
> Cc:bioc-devel@r-project.org
>
> Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
>
> Hi,
>
> Yesterday there was another email about Biostrings 
> -https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
>
> I thought it might be related to your problem.
>
> Regards,
>
> Martin
>
> On Thu, Apr 25, 2024 at 8:23 AM Ulrich 
> Bodenhofer  
>   wrote:
>
> Dear colleagues, dear BioC core team,
>
> One of my packages in the devel branch, the ‘msa’ package seems broken 
> since
>
> yesterday. The vignette does not run anymore (therefore, the package does
>
> not build), and the reason is that the BLOSUM62 substitution matrix cannot
>
> be loaded form the ‘Biostrings’ package anymore. I checked the 
> ‘Biostrings’
>
> package. In Version 2.70.3 in the release branch, the substitution 
> matrices
>
> were still in the ‘data/’ directory. In the current devel version 2.71.6,
>
> they have disappeared. I found no hint to that in the NEWS file. So, I 
> want
>
> to kindly ask the maintainers of the ‘Biostrings’ package to give me some
>
> advice how to fix that on my side or, in case that this is an error in the
>
> current devel version of the ‘Biostrings’ package, to have a look into 
> this.
>
> Thanks a lot in advance, best regards,
>
> Ulrich
>
> ___
>
> mailto: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

-- 
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: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Ulrich Bodenhofer]

Great, thanks, Hervé, so I’ll simply wait for the update. If there is anything 
I should do, just let me know.

 

Thanks and best regards,

Ulrich

 

 

From: Hervé Pagès  
Sent: Thursday, April 25, 2024 9:06 AM
To: ulr...@bodenhofer.com; 'Martin Grigorov' 
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

 

Hi Ulrich,

Yes the substitution matrices are now in pwalign. I'm taking care of msa. Sorry 
for that.

Best, 

H. 

On 4/24/24 23:25, Ulrich Bodenhofer wrote:

Ah, thank you very much, sorry for having overlooked this! Yes, that seems the 
source of the problem. Hervé, should I wait for your update or rather change 
the package myself? The latter won’t be a problem for me. I suppose it is just 
about adding ‘pwalign’ as an additional dependency, right?
 
Thanks and best regards,
Ulrich
 
 
From: Martin Grigorov   
 
Sent: Thursday, April 25, 2024 7:52 AM
To: ulr...@bodenhofer.com  
Cc: bioc-devel@r-project.org  
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
 
Hi,
 
Yesterday there was another email about Biostrings - 
https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
I thought it might be related to your problem.
 
Regards,
Martin
 
On Thu, Apr 25, 2024 at 8:23 AM Ulrich Bodenhofer  
  wrote:
Dear colleagues, dear BioC core team,
 
One of my packages in the devel branch, the ‘msa’ package seems broken since
yesterday. The vignette does not run anymore (therefore, the package does
not build), and the reason is that the BLOSUM62 substitution matrix cannot
be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
package. In Version 2.70.3 in the release branch, the substitution matrices
were still in the ‘data/’ directory. In the current devel version 2.71.6,
they have disappeared. I found no hint to that in the NEWS file. So, I want
to kindly ask the maintainers of the ‘Biostrings’ package to give me some
advice how to fix that on my side or, in case that this is an error in the
current devel version of the ‘Biostrings’ package, to have a look into this.
 
Thanks a lot in advance, best regards,
Ulrich
 
___
mailto: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: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Hervé Pagès]

Hi Ulrich,

Yes the substitution matrices are now in pwalign. I'm taking care of 
msa. Sorry for that.

Best,

H.

On 4/24/24 23:25, Ulrich Bodenhofer wrote:
> Ah, thank you very much, sorry for having overlooked this! Yes, that seems 
> the source of the problem. Hervé, should I wait for your update or rather 
> change the package myself? The latter won’t be a problem for me. I suppose it 
> is just about adding ‘pwalign’ as an additional dependency, right?
>
> Thanks and best regards,
> Ulrich
>
>
> From: Martin Grigorov  
> Sent: Thursday, April 25, 2024 7:52 AM
> To:ulr...@bodenhofer.com
> Cc:bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
>
> Hi,
>
> Yesterday there was another email about Biostrings 
> -https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
> I thought it might be related to your problem.
>
> Regards,
> Martin
>
> On Thu, Apr 25, 2024 at 8:23 AM Ulrich 
> Bodenhofer  wrote:
> Dear colleagues, dear BioC core team,
>
> One of my packages in the devel branch, the ‘msa’ package seems broken since
> yesterday. The vignette does not run anymore (therefore, the package does
> not build), and the reason is that the BLOSUM62 substitution matrix cannot
> be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
> package. In Version 2.70.3 in the release branch, the substitution matrices
> were still in the ‘data/’ directory. In the current devel version 2.71.6,
> they have disappeared. I found no hint to that in the NEWS file. So, I want
> to kindly ask the maintainers of the ‘Biostrings’ package to give me some
> advice how to fix that on my side or, in case that this is an error in the
> current devel version of the ‘Biostrings’ package, to have a look into this.
>
> Thanks a lot in advance, best regards,
> Ulrich
>
> ___
> mailto: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: [Rd] Question regarding .make_numeric_version with non-character input

[Hervé Pagès]

On 4/24/24 23:07, Kurt Hornik wrote:

>> Hervé Pagès writes:
>> Hi Kurt,
>> Is it intended that numeric_version() returns an error by default on
>> non-character input in R 4.4.0?
> Dear Herve, yes, that's the intention.
>
>> It seems that I can turn this into a warning by setting
>> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
>> seem to be able to find any of this mentioned in the NEWS file.
> That's what I added for smoothing the transition: it will be removed
> from the trunk shortly.

Thanks for clarifying.  Could this be documented in the NEWS file? This 
is a breaking change (it breaks a couple of Bioconductor packages) and 
people are not going to set this environment variable if they are not 
aware of it.

Thanks again,

H.

>
> Best
> -k
>
>> Thanks,
>> H.
>> On 4/1/24 05:28, Kurt Hornik wrote:
>>  Andrea Gilardi via R-devel writes:
>  
>>  Thanks: should be fixed now in the trunk.
>  
>>  Best
>>  -k
>>  Thank you very much Dirk for your kind words and for confirming the 
>> bug.
>>  Next week I will open a new issue on Bugzilla adding the related 
>> patch.
>  
>>  Kind regards
>  
>>  Andrea
>  
>>  On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>  
>>  On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>  | Dear all,
>>  |
>>  | I have a question regarding the R-devel version of 
>> .make_numeric_version() function. As far as I can understand, the current 
>> code 
>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>  runs the following steps in case of non-character input:
>>  |
>>  | 1. It creates a message named msg using gettextf.
>>  | 2. Such object is then passed to stop(msg) or warning(msg) 
>> according to the following condition
>>  |
>>  | 
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false")
>>  |
>>  | However, I don't understand the previous code since the 
>> output of Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false" is just a boolean value and tolower() will just return "true" or 
>> "false". Maybe the intended code is 
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>> "false" ? Or am I missing something?
>  
>>  Yes, agreed -- good catch.  In full, the code is (removing 
>> leading
>>  whitespace, and putting it back onto single lines)
>  
>>  msg <- gettextf("invalid non-character version specification 
>> 'x' (type: %s)", typeof(x))
>>  
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false"))
>>  stop(msg, domain = NA)
>>  else
>>  warning(msg, domain = NA, immediate. = TRUE)
>  
>>  where msg is constant (but reflecting language settings via 
>> standard i18n)
>>  and as you not the parentheses appear wrong.  What was intended 
>> is likely
>  
>>  msg <- gettextf("invalid non-character version specification 
>> 'x' (type: %s)", typeof(x))
>>  
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>> != "false")
>>  stop(msg, domain = NA)
>>  else
>>  warning(msg, domain = NA, immediate. = TRUE)
>  
>>  If you use bugzilla before and have a handle, maybe file a bug 
>> report with
>>  this as patch athttps://bugs.r-project.org/
>  
>>  Dirk
>>  __
>>  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
>  
>> -- 
>> Hervé Pagès
>> Bioconductor Core Team
>> hpages.on.git...@gmail.com

-- 
Hervé Pagès

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

[[alternative HTML version deleted]]

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

Re: [Rd] View() segfaulting ...

[Ivan Krylov via R-devel]

On Wed, 24 Apr 2024 19:35:42 -0400
Ben Bolker  wrote:

>  I'm using bleeding-edge R-devel, so maybe my build is weird. Can 
> anyone else reproduce this?
> 
>View() seems to crash on just about anything.

Not for me, sorry.

If you have a sufficiently new processor, you can use `rr` [*] to
capture the crash, set a breakpoint in in_R_X11_dataviewer and rewind,
then set a watchpoint on the stack canary and run the program forward
again:
https://www.redhat.com/en/blog/debugging-stack-protector-failures

If you can't locate the canary, try setting watchpoints on large local
variables. Without `rr`, the procedure is probably the same, but
without rewinding: set a breakpoint in in_R_X11_dataviewer, set some
watchpoints, see if they fire when they shouldn't, start from scratch
if you get past the watchpoints and the process crashes.

I think that that either an object file didn't get rebuilt when it
should have, or a shared library used by something downstream from
View() got an ABI-breaking update. If this still reproduces with a clean
rebuild of R, it's definitely worth investigating further, perhaps using
AddressSanitizer. Valgrind may be lacking the information about the
stack canary and thus failing to distinguish between overwriting the
canary and normal access to a stack variable via a pointer.

-- 
Best regards,
Ivan

[*] https://rr-project.org/
Edit distance of one from the domain name of the R project!

Use rr replay -g $EVENT_NUMBER to debug past the initial execve()
from the shell wrapper: https://github.com/rr-debugger/rr/wiki/FAQ

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

Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Ulrich Bodenhofer]

Ah, thank you very much, sorry for having overlooked this! Yes, that seems the 
source of the problem. Hervé, should I wait for your update or rather change 
the package myself? The latter won’t be a problem for me. I suppose it is just 
about adding ‘pwalign’ as an additional dependency, right?

Thanks and best regards,
Ulrich


From: Martin Grigorov  
Sent: Thursday, April 25, 2024 7:52 AM
To: ulr...@bodenhofer.com
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

Hi,

Yesterday there was another email about Biostrings - 
https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
I thought it might be related to your problem.

Regards,
Martin

On Thu, Apr 25, 2024 at 8:23 AM Ulrich Bodenhofer 
 wrote:
Dear colleagues, dear BioC core team,

One of my packages in the devel branch, the ‘msa’ package seems broken since
yesterday. The vignette does not run anymore (therefore, the package does
not build), and the reason is that the BLOSUM62 substitution matrix cannot
be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
package. In Version 2.70.3 in the release branch, the substitution matrices
were still in the ‘data/’ directory. In the current devel version 2.71.6,
they have disappeared. I found no hint to that in the NEWS file. So, I want
to kindly ask the maintainers of the ‘Biostrings’ package to give me some
advice how to fix that on my side or, in case that this is an error in the
current devel version of the ‘Biostrings’ package, to have a look into this.

Thanks a lot in advance, best regards,
Ulrich

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

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Hervé Pagès writes:

> Hi Kurt,
> Is it intended that numeric_version() returns an error by default on
> non-character input in R 4.4.0? 

Dear Herve, yes, that's the intention.

> It seems that I can turn this into a warning by setting
> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> seem to be able to find any of this mentioned in the NEWS file.

That's what I added for smoothing the transition: it will be removed
from the trunk shortly.

Best
-k

> Thanks,

> H.

> On 4/1/24 05:28, Kurt Hornik wrote:

> Andrea Gilardi via R-devel writes:

> Thanks: should be fixed now in the trunk.

> Best
> -k

> Thank you very much Dirk for your kind words and for confirming the 
> bug. 
> Next week I will open a new issue on Bugzilla adding the related 
> patch.

> Kind regards

> Andrea

> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:

> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
> | Dear all,
> |
> | I have a question regarding the R-devel version of 
> .make_numeric_version() function. As far as I can understand, the current 
> code 
> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>  runs the following steps in case of non-character input:
> |
> | 1. It creates a message named msg using gettextf.
> | 2. Such object is then passed to stop(msg) or warning(msg) 
> according to the following condition
> |
> | 
> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
> "false")
> |
> | However, I don't understand the previous code since the output 
> of Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
> is just a boolean value and tolower() will just return "true" or "false". 
> Maybe the intended code is 
> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
> "false" ? Or am I missing something?

> Yes, agreed -- good catch.  In full, the code is (removing leading
> whitespace, and putting it back onto single lines)

> msg <- gettextf("invalid non-character version specification 'x' 
> (type: %s)", typeof(x))
> 
> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
> "false"))
> stop(msg, domain = NA)
> else
> warning(msg, domain = NA, immediate. = TRUE)

> where msg is constant (but reflecting language settings via 
> standard i18n)
> and as you not the parentheses appear wrong.  What was intended 
> is likely

> msg <- gettextf("invalid non-character version specification 'x' 
> (type: %s)", typeof(x))
> 
> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
> "false")
> stop(msg, domain = NA)
> else
> warning(msg, domain = NA, immediate. = TRUE)

> If you use bugzilla before and have a handle, maybe file a bug 
> report with
> this as patch at https://bugs.r-project.org/

> Dirk

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

> -- 
> Hervé Pagès

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

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