Re: [Rd] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)

[Hervé Pagès]

Hi Martin, Henrik,

I actually like this change.

Makes a lot of sense IMO that dim(x) <- dim(x) be a no-op, or, more 
generally, that foo(x) <- foo(x) be a no-op for any setter/getter combo.

FWIW S4Arrays::set_dim() does that too. It also preserves the dimnames 
if the right value is only adding or dropping outermost (ineffective) 
dimensions:

     > x <- array(1:6, dim=c(2,3,1), dimnames=list(c("A", "B"), 
c("x","y", "z"), "T"))
     > S4Arrays:::set_dim(x, 2:3)
       x y z
     A 1 3 5
     B 2 4 6

Note that this is consistent with drop().

Best,

H.

On 10/30/23 03:53, Martin Maechler wrote:
>> Henrik Bengtsson
>>  on Sun, 29 Oct 2023 10:42:19 -0700 writes:
>  > Hello,
>
>  > the fix of PR18612
>  > (https://bugs.r-project.org/show_bug.cgi?id=18612) in
>  > r85380
>  > 
> (https://github.com/wch/r-source/commit/2653cc6203fce4c48874111c75bbccac3ac4e803)
>  > caused a change in `dim<-()`.  Specifically, in the past,
>  > any `dim<-()` assignment would _always_ remove "dimnames"
>  > and "names" attributes per help("dim"):
>
>
>  > The replacement method changes the "dim" attribute
>  > (provided the new value is compatible) and removes any
>  > "dimnames" and "names" attributes.
>
>  > In the new version, assigning the same "dim" as before
>  > will no longer remove "dimnames".  I'm reporting here to
>  > check whether this change was intended, or if it was an
>  > unintended side effect of the bug fix.
>
>  > For example, in R Under development (unstable) (2023-10-21
>  > r85379), we would get:
>
>  >> x <- array(1:2, dim=c(1,2), dimnames=list("A",
>  >> c("a","b"))) str(dimnames(x))
>  > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
>  >> dim(x) <- dim(x) ## Removes "dimnames" no matter what
>  >> str(dimnames(x))
>  >  NULL
>
>
>  > whereas in R Under development (unstable) (2023-10-21
>  > r85380) and beyond, we now get:
>
>  >> x <- array(1:2, dim=c(1,2), dimnames=list("A",
>  >> c("a","b"))) str(dimnames(x))
>  > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
>  >> dim(x) <- dim(x) ## No longer removes "dimnames"
>  >> str(dimnames(x))
>  > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
>  >> dim(x) <- rev(dim(x)) ## Still removes "dimnames"
>  >> str(dimnames(x))
>  >  NULL
>
>  > /Henrik
>
> Thank you, Henrik.
>
> This is "funny" (in an unusal sense):
> indeed, the change was *in*advertent, by me (svn rev 85380).
>
> I had experimentally {i.e., only in my own private version of R-devel!}
> modified the behavior of `dim<-` somewhat
> such it does *not* unnecessarily drop dimnames,
> e.g., in your   `dim(x) <- dim(x)` case above,
> one could really argue that it's a "true loss" if x loses
> dimnames "unnecessarily" ...
>
> OTOH, I knew in the mean time that  `dim<-` has always been
> documented to drop dimnames in all cases,  and even more
> importantly, I got a strong recommendation to *not* go further
> with this idea -- not only for back compatibility reasons, but
> also for internal logical consistency.
>
> Most probably, we will just revert this inadvertent change,
> but before that ... since it has been out in the wild anyway,
> we could quickly consider if it *did* break code.
>
> I assume it did, or you would not have noticed ?
>
> Martin
>
> __
> 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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Matrix and Mac OS

[Simon Urbanek]

Paul,

can you give us a bit more detail? Which package, which build and where you got 
the errors? Older builds may not have the latest Matrix.

Cheers,
Simon


> On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel 
>  wrote:
> 
> Hi,
> 
> I'm the maintainer for a few packages, one of which is currently failing CRAN 
> checks on Mac OS because Matrix is not available in my required version (the 
> latest). I had to fix a few things due to changes in the latest Matrix 
> package because of how qr works and I thought, given the apparent API change, 
> I should then require the latest version. My error is, "Package required and 
> available but unsuitable version: 'Matrix'"
> 
> When I look at the NEWS in Matrix there is no mention of Mac OS issues, what 
> the latest stable version of Matrix is, nor when a fix is expected. What 
> version do MacOS version test Matrix with by default? Where is this 
> documented? I assumes it always tested with the latest version on CRAN, so 
> I'm a bit surprised. Or will this be resolved soon and I shouldn't bother 
> CRAN maintainers with a new version of my package?
> 
> Best,
> Paul
> 
>   [[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] Matrix and Mac OS

[Bailey, Paul via R-package-devel]

Hi,

I'm the maintainer for a few packages, one of which is currently failing CRAN 
checks on Mac OS because Matrix is not available in my required version (the 
latest). I had to fix a few things due to changes in the latest Matrix package 
because of how qr works and I thought, given the apparent API change, I should 
then require the latest version. My error is, "Package required and available 
but unsuitable version: 'Matrix'"

When I look at the NEWS in Matrix there is no mention of Mac OS issues, what 
the latest stable version of Matrix is, nor when a fix is expected. What 
version do MacOS version test Matrix with by default? Where is this documented? 
I assumes it always tested with the latest version on CRAN, so I'm a bit 
surprised. Or will this be resolved soon and I shouldn't bother CRAN 
maintainers with a new version of my package?

Best,
Paul

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

[Markus Jochim]

Thank you, Deepayan. Commit r85440 appears to solve the problem in emuR.

Markus

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

I have read about "system() not using a shell on Windows" on the help
page many times before but never understood what it means technically.
Please forgive my ignorance. I still do not understand it, but thanks
a lot for the explanation anyway! I'm just curious if the full path
would work in system() today. If it still would not work because
today's Windows is still like Windows 95 in this aspect, please ignore
my question and I will ask Microsoft for a refund.

Regards,
Yihui



On Mon, Oct 30, 2023 at 3:03 PM Prof Brian Ripley  wrote:
>
> On 30/10/2023 16:18, Yihui Xie wrote:
> > Hi,
> >
> > It may have been so for 20+ years but I just discovered today that system()
> > would always try to use the short path of a command on Windows:
> > https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
> > that's true, I wonder if it could provide an option to disable this
> > behavior, because we recently ran into a case in which short paths wouldn't
> > work. I wonder what the original motivation of using short paths was. If it
> > was to avoid spaces in paths, wouldn't shQuote() work? Thanks!
>
> No: system on Windows does not use a shell.
>
> The 'original motivation' was to work reliably!  Back in the days of
> Windows 95 when many parts of Windows only supported 8+3 names.
>
> >
> > Regards,
> > Yihui
> >
> >   [[alternative HTML version deleted]]
>
> Please do re-read the posting guide.  It has ' been so for 20+ years '.

My apologies! Sometimes I forget to switch to the plain-text mode when
writing to R mailing lists.

> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Prof Brian Ripley]

On 30/10/2023 16:18, Yihui Xie wrote:

Hi,

It may have been so for 20+ years but I just discovered today that system()
would always try to use the short path of a command on Windows:
https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
that's true, I wonder if it could provide an option to disable this
behavior, because we recently ran into a case in which short paths wouldn't
work. I wonder what the original motivation of using short paths was. If it
was to avoid spaces in paths, wouldn't shQuote() work? Thanks!


No: system on Windows does not use a shell.

The 'original motivation' was to work reliably!  Back in the days of 
Windows 95 when many parts of Windows only supported 8+3 names.




Regards,
Yihui

[[alternative HTML version deleted]]


Please do re-read the posting guide.  It has ' been so for 20+ years '.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

[Deepayan Sarkar]

On Mon, 30 Oct 2023 at 12:48, Markus Jochim
 wrote:
>
> Hi R people,
>
> I am the maintainer of the emuR package and I am having a problem with
> recent versions of R CMD check.
>
> CRAN‘s r-devel test suites [1] have started to emit a NOTE about the
> HTML version of the manual:
>
> > Version: 2.4.1
> > Check: HTML version of manual
> > Result: NOTE
> > Found the following HTML validation problems:
> > query.html:50:9 (query.Rd:22): Warning:  anchor "query"
> > already defined
> > Flavors: r-devel-linux-x86_64-debian-clang,
> > r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang,
> > r-devel-linux-x86_64-fedora-gcc, r-devel-windows-x86_64
> >
> This is caused by one of my package’s functions that is named query and
> also has a parameter named query.
>
> I think I have tracked this down to SVN revision r85407 of R. With
> earlier versions:
>
> R CMD Rdconv -t html query.Rd
>
> would output (line 50, as referenced by the NOTE):
>
> query
>
> But newer versions output:
>
> query

Yes, sorry, my bad.

r85440 (just committed) should have a temporary fix by omitting the id
from the  title. Please let me know if problems still persist.

Best,
-Deepayan

> Notice the difference in id. The id "query" appears both here and
> further up in the file, specifically in the h2 heading. This triggers
> the HTML validation problem. I suppose this is a bug in the experimental
> table of contents feature? As such, should I rather post this to R-devel?
>
> Unfortunately, this also prevents me from uploading a new version of my
> package, since it does not get past CRAN’s automatic pretest. Can I
> resubmit my new version and simply state in the comments that I cannot
> fix the NOTE from r-devel at this point? Or should I rather wait until
> this is changed upstream? (the described NOTE is the only complaint from
> the pretest). Changing the function or parameter name is not an option,
> they have been used in this package ever since it was released a couple
> of years ago.
>
> This NOTE can also be reproduced with a minimal R package that has
> nothing but a hello function with a parameter named hello.
>
> Thanks for reading this. I appreciate any help.
>
> Markus
>
>
> Institute for Phonetics and Speech Processing
>
> Ludwig-Maximilians-Universität München
>
> https://www.phonetik.uni-muenchen.de
>
>
> [1] https://cran.rstudio.com//web/checks/check_results_emuR.html
>
> __
> 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: [Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

Sure. I'm not sure if it's possible to make it easier to reproduce, but for
now the example would require installing TinyTeX (via
tinytex::install_tinytex(), which can be later uninstalled cleanly via
tinytex::uninstall_tinytex() after you finish the investigation). Then run:

  system2('fmtutil-sys', '--all')
  # or tinytex:::fmtutil() if fmtutil-sys.exe is not on PATH

and TeX Live would throw an error like this:

  ...\username\AppData\Roaming\TinyTeX\bin\windows\runscript.tlu:864: no
appropriate script or program found: fmtuti~1

The command "fmtutil-sys" is longer than 8 characters and hence shortened
to "fmtutil~1". Yes, in principle, TeX Live should work with short path
names, but it doesn't at the moment. I haven't figured out if it was a
recent breakage in TeX Live or not (I've tried to contact TeX Live
developers).

BTW, shell('fmtutil-sys --all') works fine.

Regards,
Yihui
--
https://yihui.org


On Mon, Oct 30, 2023 at 12:34 PM Tomas Kalibera 
wrote:

>
> On 10/30/23 17:18, Yihui Xie wrote:
> > Hi,
> >
> > It may have been so for 20+ years but I just discovered today that
> system()
> > would always try to use the short path of a command on Windows:
> > https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
> > that's true, I wonder if it could provide an option to disable this
> > behavior, because we recently ran into a case in which short paths
> wouldn't
> > work. I wonder what the original motivation of using short paths was. If
> it
> > was to avoid spaces in paths, wouldn't shQuote() work? Thanks!
>
> Could you please file a minimal reproducible example that exhibits the
> problem caused by an attempt to translate to short path names (note
> there is a fallback to long path names)? In principle, short path names
> should work when they are returned by Windows, this should not be
> causing any trouble.
>
> Thanks
> Tomas
>
> >
> > Regards,
> > Yihui
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Tomas Kalibera]

On 10/30/23 17:18, Yihui Xie wrote:

Hi,

It may have been so for 20+ years but I just discovered today that system()
would always try to use the short path of a command on Windows:
https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
that's true, I wonder if it could provide an option to disable this
behavior, because we recently ran into a case in which short paths wouldn't
work. I wonder what the original motivation of using short paths was. If it
was to avoid spaces in paths, wouldn't shQuote() work? Thanks!


Could you please file a minimal reproducible example that exhibits the 
problem caused by an attempt to translate to short path names (note 
there is a fallback to long path names)? In principle, short path names 
should work when they are returned by Windows, this should not be 
causing any trouble.


Thanks
Tomas



Regards,
Yihui

[[alternative HTML version deleted]]

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


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

[R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

[Markus Jochim]

Hi R people,

I am the maintainer of the emuR package and I am having a problem with 
recent versions of R CMD check.


CRAN‘s r-devel test suites [1] have started to emit a NOTE about the 
HTML version of the manual:



Version: 2.4.1
Check: HTML version of manual
Result: NOTE
    Found the following HTML validation problems:
    query.html:50:9 (query.Rd:22): Warning:  anchor "query" 
already defined
Flavors: r-devel-linux-x86_64-debian-clang, 
r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang, 
r-devel-linux-x86_64-fedora-gcc, r-devel-windows-x86_64


This is caused by one of my package’s functions that is named query and 
also has a parameter named query.


I think I have tracked this down to SVN revision r85407 of R. With 
earlier versions:


R CMD Rdconv -t html query.Rd

would output (line 50, as referenced by the NOTE):

query

But newer versions output:

query

Notice the difference in id. The id "query" appears both here and 
further up in the file, specifically in the h2 heading. This triggers 
the HTML validation problem. I suppose this is a bug in the experimental 
table of contents feature? As such, should I rather post this to R-devel?


Unfortunately, this also prevents me from uploading a new version of my 
package, since it does not get past CRAN’s automatic pretest. Can I 
resubmit my new version and simply state in the comments that I cannot 
fix the NOTE from r-devel at this point? Or should I rather wait until 
this is changed upstream? (the described NOTE is the only complaint from 
the pretest). Changing the function or parameter name is not an option, 
they have been used in this package ever since it was released a couple 
of years ago.


This NOTE can also be reproduced with a minimal R package that has 
nothing but a hello function with a parameter named hello.


Thanks for reading this. I appreciate any help.

Markus


Institute for Phonetics and Speech Processing

Ludwig-Maximilians-Universität München

https://www.phonetik.uni-muenchen.de


[1] https://cran.rstudio.com//web/checks/check_results_emuR.html

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

[Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

Hi,

It may have been so for 20+ years but I just discovered today that system()
would always try to use the short path of a command on Windows:
https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
that's true, I wonder if it could provide an option to disable this
behavior, because we recently ran into a case in which short paths wouldn't
work. I wonder what the original motivation of using short paths was. If it
was to avoid spaces in paths, wouldn't shQuote() work? Thanks!

Regards,
Yihui

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Issue with R Package on CRAN - OpenMP and clang17

[Ivan Krylov]

В Mon, 30 Oct 2023 15:58:31 +0100 (CET)
Romain Pierlot  пишет:

> I'm sorry to disturb, I hope I send a mail at the right place. 

This is exactly the right place to ask. Welcome to R-package-devel!

> It appears that I have addressed the Fortran issues, but upon
> resubmission to CRAN, the package was not accepted, and the following
> error was returned : 
> 
> 
> ''With clang17 it still fails to install: 
> 
> error:
> loc("/data/gannet/ripley/R/packages/incoming/frailtypack.Rcheck/00_pkg_src/frailtypack/src/Integrale_mult_scl.f90":1811:17):
> 'omp.reduction' op must be used within an operation supporting
> reduction clause interface error: verification of lowering to FIR
> failed 
> 
> LLVM trunk gives the same error. 
> '' 

I'm not 100% sure, but I currently think that this is a compiler bug.

You have a variable, ss, declared inside a function.

If nb_procs==1, you start an OpenMP parallel region with a reduction on
that variable. The OpenMP parallel region starts and ends inside that
if clause. Outside the parallel region, in another branch, you add to
it as usual.

Flang-new complains about your use of the 'ss' variable outside the
parallel region, alleging that it's not valid for an OpenMP reduction.
There is no OpenMP reduction in sight where the error is reported. I
think that Flang-new is wrong to signal an error here.

Unfortunately, proving that this is a compiler bug might be hard. I'll
try to reproduce your problem, starting by downloading and compiling
flang from https://github.com/llvm/llvm-project.git commit
092b6c5ee3707ea10b9f10d0a674e8d12395369b (as stated at
). I hope
it will be possible to simplify Integrale_mult_scl.f90 until it looks
manageable for their bug tracker.

> Moreover, I don't know if it is normal or not, but when I check my
> package with R CMD chech --as-cran, I don't have any error or note
> message. But when I submit the package to the CRAN, they return
> errors and notes. 

These errors only happen with the "flang-new" Fortran compiler that's
part of the LLVM compiler infrastructure. You're probably using
gfortran or some other, more well-polished Fortran compiler.

-- 
Best regards,
Ivan

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

Re: [Bioc-devel] No cairo device on merida1

[Jennifer Wokaty]

This is a known issue that Cairo isn't enabled for the R 4.4 macos binaries 
that are installed on the macOS devel builders. Unfortunately this impacts a 
lot of packages. No action is needed. We appreciate your patience while waiting 
for the issue to be resolved upstream or until a suitable workaround is found.

Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPH
Bioconductor Core Team

From: Bioc-devel  on behalf of Oleksii 
Nikolaienko 
Sent: Saturday, October 28, 2023 1:08 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] No cairo device on merida1

* This email originates from a sender outside of CUNY. Verify the sender before 
replying or clicking on links and attachments. *

Dear Bioc team,
my package is failing

on
merida1 with the message "svg: Cairo-based devices are not available for
this platform". I didn't find relevant issues at
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2FBioconductor%2FBBS__%3B!!PxiZbSOawA!NZKQ_KQo8YYPfqPKmCWa79KTkqyge6ChWZj8Ync1tf45q4xfNzVNUtZr5mFgCSDfck20dmexXoSAkilrIWEJT3qh86IdWGyDIie-rA%24=05%7C01%7Cjennifer.wokaty%40sph.cuny.edu%7C1a6db7e8bb474531948108dbd7d8be27%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638341098138703864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=6TvbZYIm5IxmRK0QmzvnrBKQ7Q5bQah85YnsLGyBnb0%3D=0
 , therefore asking here - is there
something missing at merida1 or I shouldn't include SVG in my vignettes?

Best,
Oleksii

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel__%3B!!PxiZbSOawA!NZKQ_KQo8YYPfqPKmCWa79KTkqyge6ChWZj8Ync1tf45q4xfNzVNUtZr5mFgCSDfck20dmexXoSAkilrIWEJT3qh86IdWGySMhZu7w%24=05%7C01%7Cjennifer.wokaty%40sph.cuny.edu%7C1a6db7e8bb474531948108dbd7d8be27%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638341098138703864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=g9PbGAFReAKilvaXu9Q5cwhAqXegKC0rdfsUzNBAMfM%3D=0

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)

[Dirk Eddelbuettel]

I have some better news.  While we established that 'in theory' setting the
environment variable OMP_NUM_THREADS would help (and I maintain that it is a
great PITA that CRAN does not do so as a general fix for this issue) it does
*not help* once R is started.  OpenMP only considers the variable once at
startup and does not re-read it.  So we cannot set from R once R has started.

But OpenMP offers a setter (and a getter) for the thread count value.

And using it addresses the issue.  I created a demo package [1] which, when
running on a system with both OpenMP and 'enough cores' (any modern machine
will do) exhibits the warning from R CMD check --as-cran with timing enabled
(i.e. env vars set).  When an additional environment variable 'SHOWME' is set
to 'yes', it successfully throttles via the exposed OpenMP setter.  In our
example, Armadillo uses it to calibrate its thread use, a lower setting is
followed, and the warning is gone.

I will add more convenient wrappers to RcppArmadillo itself. These are
currently in a branch [2] and their use is illustrated in the help page and
example of fastLm demo function [3].  I plan to make a new RcppArmadillo
release with this change in the coming days, the setter and re-setter will
work for any OpenMP threading changes. So if you use RcppArmadillo, this
should help. (And of course there always was RhpcBLASctl doing this too.)

Dirk

[1] https://github.com/eddelbuettel/rcpparmadilloopenmpex
[2] https://github.com/RcppCore/RcppArmadillo/tree/feature/thread_throttle\
[3] 
https://github.com/RcppCore/RcppArmadillo/blob/a8db424bd6aaeda2ceb897142d3c366d9c6591c7/man/fastLm.Rd#L72-L98
[4] https://cran.r-project.org/package=RhpcBLASctl

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

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

Re: [Rd] Wayland Display Support in R Plot

[Iñaki Ucar]

El lun., 30 oct. 2023 12:26, Roger Bivand  escribió:

> I also noticed this:
>
> https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/
>
> which is concerning. Until now, I've retained X11 on Fedora because of
> difficulties in screen sharing via zoom in Wayland sessions.
>

KDE Plasma user here. FWIW, I've been using Wayland for a year and a half
now with no issues, including screen sharing, etc.

Iñaki


> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Wayland Display Support in R Plot

[Dirk Eddelbuettel]

On 30 October 2023 at 13:17, Willem Ligtenberg via R-devel wrote:
| I just tried it on Ubuntu 23.10. It seems to just work.
| See screenshot here: https://nextcloud.wligtenberg.nl/s/jnbDT4ZiHw2JQ8H
| I should be using wayland, and as far as I know I haven't done anything 
| special to make this work. But there might be some compatibility layer 
| that is active by default.

Same here under trusted 22.04 LTS on that older / not quite healthy laptop.
All it took was to set WaylandEnable=true in /etc/gdm3/custom.conf and a
systemctl call to restart gdm3.

R plots fine in the x11() default device via plot(cumsum(rnorm(100)), type="l").

Like Roger, I had issues with some third-party apps (obs to record lectures
comes to mind, maybe also zoom ?) so "we'll see".

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] Wayland Display Support in R Plot

[Willem Ligtenberg via R-devel]

On 29-10-2023 22:29, Dirk Eddelbuettel wrote:
> On 30 October 2023 at 09:20, Simon Urbanek wrote:
> | > On 30/10/2023, at 8:38 AM, Dirk Eddelbuettel  wrote:
> | > On 30 October 2023 at 07:54, Paul Murrell wrote:
> | > | I am unaware of any Wayland display support.
> | > |
> | > | One useful way forward would be an R package that provides such a device
> | > | (along the lines of 'Cairo', 'tikzDevice', et al)
> | >
> | > As I understand it, it is a protocol, and not a device.
> | >
> |
> | Well, X11 is a protocol, not a device, either.
>
> Point taken.
>
> | > I think I needed to fall back to X11 for a particular applications (likely
> | > OBS) so my session tells me (under Settings -> About -> Windowing System) 
> I
> | > am still running X11. I'll check again once I upgrade from Ubuntu 23.04 to
> | > Ubuntu 23.10
>
> Booted an older laptop using 22.04, selected 'not X11' in the gdm dialog but
> the same Gnome Menu still says Windowing System: X11.  So I am no longer sure
> how I would convince myself if I am under Wayland there or not.  The answers
> inhttps://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used
> suggest I still run X11 too.  So I got nuttin' here.
>
> In any event, I read OP as asking 'do we need a new device' and I still think
> that the answer to that still is 'likely not' as the X11 compatibility layer
> should cover this.
>
> Dirk
>
I just tried it on Ubuntu 23.10. It seems to just work.
See screenshot here: https://nextcloud.wligtenberg.nl/s/jnbDT4ZiHw2JQ8H
I should be using wayland, and as far as I know I haven't done anything 
special to make this work. But there might be some compatibility layer 
that is active by default.
If it helps, I could try again using distrobox.

Kind regards,

Willem

[[alternative HTML version deleted]]

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

Re: [Rd] Wayland Display Support in R Plot

[Roger Bivand]

I also noticed this:

https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/

which is concerning. Until now, I've retained X11 on Fedora because of 
difficulties in screen sharing via zoom in Wayland sessions.

Roger

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] [ext] Re: RCAS build error on Nebbiolo2 - Missing BiocManager

[Kern, Lori via Bioc-devel]

Yes adding BiocManager to the suggest field of your DESCRIPTION will likely 
correct the ERROR


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of 
bora.u...@mdc-berlin.de 
Sent: Monday, October 30, 2023 7:01 AM
To: Herv� Pag�s ; bioc-devel@r-project.org 
; Kasper Daniel Hansen 
Subject: Re: [Bioc-devel] [ext] Re: RCAS build error on Nebbiolo2 - Missing 
BiocManager

Dear Herve & Kasper,

Thank you very much for your responses.


The checkSeqDb(�hg19�) function calls the BSgenome::available.genomes function 
which in turn calls 
�get_data_annotation_contrib_url�.

The method tries to access `BiocManager::repositories` function to find a 
certain url. So, it basically fails because BiocManager is not seen, not 
because it is used to install a dependency here.

In this case, it would be okay  add BiocManager to the suggests field of my 
package, is that right?



Best,

Bora

From: Herv� Pag�s 
Date: Friday, 27. October 2023 at 17:57
To: "Uyar, Bora" , "bioc-devel@r-project.org" 

Subject: [ext] Re: [Bioc-devel] RCAS build error on Nebbiolo2 - Missing 
BiocManager


Hi Bora,

BiocManager is installed on the machine but 'R CMD check' does not "see" it 
because you don't have it listed in Suggests. This 'R CMD check' behavior is 
controlled by the _R_CHECK_SUGGESTS_ONLY_ behavior and is only enabled on our 
Linux builders for now.

However, please note that the code in your examples, vignettes or unit tests 
should NOT install packages. I don't know what package exactly 
checkSeqDb('hg19') is trying to install but that is what should be listed in 
Suggests instead of BiocManager. That way it won't be reinstalled over and over 
again by  'R CMD check'.

Best,

H.
On 10/27/23 05:56, bora.u...@mdc-berlin.de 
wrote:

Hi Bioc-Devel Team,



My package RCAS has been getting build errors on Nebbiolo2. It fails to run the 
tests/examples/vignettes all due to a missing dependency, which can�t be 
installed because BiocManager is not available.



Here is the build report:

https://secure-web.cisco.com/1oc6eAjZ-FE8AObjfGH03qE9a1hOsiCxwHEaWQ-JVoXYs0UcJT25xFT64UwaVhGp5rAqFSt8WYTYvfa-OBhEqJMA5VtX-aGdpBu73H3Sr9H1Eici0Om_Y0Qm9isMcqJEA4iWwvxOnVpkX0_0dPV1PBCJEL9enWks0R6cOW_61R_-np4RpsVWEsfsvT8XIItL5ytDO6mphyIsl7Yo4qBZ2PxWqUVbmtvRx-VGstVKQ1NB9j6RINF91QrgFdolsHWGZQA8dXvGmRJVZlkzpHy1iZZIda8sAk0n6Otz6jSGm4MfME-tlgeMbqFyssvkK_rOj/https%3A%2F%2Fbioconductor.org%2FcheckResults%2Frelease%2Fbioc-LATEST%2FRCAS%2Fnebbiolo2-checksrc.html



The relevant error is :



Error in get_data_annotation_contrib_url(type) :

  Install 'BiocManager' from CRAN to get 'BioCann' contrib.url



Error: processing vignette 'RCAS.vignette.Rmd' failed with diagnostics:

Install 'BiocManager' from CRAN to get 'BioCann' contrib.url



The other machines all build it properly.



Best,

Bora



---

Dr. Bora Uyar

Bioinformatics Scientist

Bioinformatics and Omics Data Science Platform

Max Delbrueck Center (MDC) for Molecular Medicine

The Berlin Institute for Medical Systems Biology

Hannoversche Str. 28, 10115 Berlin







  [[alternative HTML version deleted]]



___

Bioc-devel@r-project.org mailing list

https://secure-web.cisco.com/1ys404GvGqDvctdVGqC6rbba7cu4ndBj7rX8GOxBdEWCDj9GJFZJX1r6UXp9wvI3FwqSAJgqs3zJK1_Q5WeTGBnUAoseKncxC9KUmUdgVLnVA--evyOyEOEjUZj_Bae5ef04klmu9Kc3mg6IdwDfyBIFsUaPx2N4-0G92lknbxcmaw5tNm-bVredR-k3q-fdXKE7eIxa2mLHozJbecGCksie0WRbeNalSPrzqTQSq2A44xne7XrjY8eg9M0DlovlfQrqkrpaffTyRwFem5LZDNc3k5xyUjb16j4avDDH_6R_tUyTuKKFUEwRhiAt4mHUH/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel

--

Herv� Pag�s



Bioconductor Core Team

hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1ys404GvGqDvctdVGqC6rbba7cu4ndBj7rX8GOxBdEWCDj9GJFZJX1r6UXp9wvI3FwqSAJgqs3zJK1_Q5WeTGBnUAoseKncxC9KUmUdgVLnVA--evyOyEOEjUZj_Bae5ef04klmu9Kc3mg6IdwDfyBIFsUaPx2N4-0G92lknbxcmaw5tNm-bVredR-k3q-fdXKE7eIxa2mLHozJbecGCksie0WRbeNalSPrzqTQSq2A44xne7XrjY8eg9M0DlovlfQrqkrpaffTyRwFem5LZDNc3k5xyUjb16j4avDDH_6R_tUyTuKKFUEwRhiAt4mHUH/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you 

Re: [Bioc-devel] Change package name

[Kern, Lori via Bioc-devel]

This is not an easy process and will involve manual intervention from the team.
What is the package name?  Is it already accepted into Bioconductor or is in 
still in the submission process?



Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Anna Pa��nkov� 

Sent: Saturday, October 28, 2023 1:10 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Change package name

Hello bioconductor community,

I need to change the name of my R package because of the conflict with
registered trademark of some company. Could you please give me a hint how
to do that?

Best wishes,
Anna Pacinkova

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1z7O5GXatYrYNV1HS18ggwvbPDn8c5tFWRcetxL8Fay9xn0K2oJ7mZvl-uLqo-GKEupSU2vBGkrRB6W6iT9qrwpMPLgLDKWxcg81n_WxJHE9FKtmJYKHAPQBTF26D47GBIKl8TtxEa06VJEtizdcmJCOyf-kQYrryKElDkzcfZl13CLrYMNkUP6YV9idg1VLTHnjgZrBlRxuN3oq2eBFzBFc4QNsXRWm3OrqLgppGve5LP-8Mp0K7yQRVhZ1wTewrov_KX-6SMoxlQxqZugxNjOdhyskII9L8WPXmxW9_o-bwEZI5umm9bKuxRn3q-kzF/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Maximum allowed cores on Bioconductor Build System?

[Kern, Lori via Bioc-devel]

I believe the recommendation is not to use more than 2 cores.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Richard Heery 

Sent: Monday, October 30, 2023 5:35 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Maximum allowed cores on Bioconductor Build System?

Hi all,

I am wondering if there is a maximum allowed number of cores that can be
used when building a vignette on the Bioconductor Build System? I make use
of parallel computing in one of my vignettes, but if I don't use enough
cores, it takes too long to build the vignette and I get a timeout error.
Currently, I am just using BiocParallel::bpparam() to automatically choose
the parallel backend in the vignette.

Cheers,

Richard

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/14y8ljrHSZkuW0Bhe_slEmQEuQL0530xm7WIZYF5I0yWiJRcwfC-AnI4opgjjg0t8of7SNtq9OLVOFajVtvtV3cvlpoUp-pxjIBqHKDUtWKVsNYXyqmWmDyVsmdcwBMuESl0_0Gs87k3QXhfXCWLGI8CcYar0IqIXkNEC8Z_2ZCQqX82l7HwPFrG3WaaMIOYxH1srQty_RE0dGWcgLgqWfRpAl01KMwJlJAzpyExWHhEanhiXf8-7ItK5BfAUefEndGQDQ9AWW0z0j-3NlvT04C2RgYNEeQqhzSL1mM83bqRDG0F0qJk37LLoN91GAXT2/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] [ext] Re: RCAS build error on Nebbiolo2 - Missing BiocManager

[bora.u...@mdc-berlin.de]

Dear Herve & Kasper,

Thank you very much for your responses.


The checkSeqDb(‘hg19’) function calls the BSgenome::available.genomes function 
which in turn calls 
“get_data_annotation_contrib_url“.

The method tries to access `BiocManager::repositories` function to find a 
certain url. So, it basically fails because BiocManager is not seen, not 
because it is used to install a dependency here.

In this case, it would be okay  add BiocManager to the suggests field of my 
package, is that right?



Best,

Bora

From: Hervé Pagès 
Date: Friday, 27. October 2023 at 17:57
To: "Uyar, Bora" , "bioc-devel@r-project.org" 

Subject: [ext] Re: [Bioc-devel] RCAS build error on Nebbiolo2 - Missing 
BiocManager


Hi Bora,

BiocManager is installed on the machine but 'R CMD check' does not "see" it 
because you don't have it listed in Suggests. This 'R CMD check' behavior is 
controlled by the _R_CHECK_SUGGESTS_ONLY_ behavior and is only enabled on our 
Linux builders for now.

However, please note that the code in your examples, vignettes or unit tests 
should NOT install packages. I don't know what package exactly 
checkSeqDb('hg19') is trying to install but that is what should be listed in 
Suggests instead of BiocManager. That way it won't be reinstalled over and over 
again by  'R CMD check'.

Best,

H.
On 10/27/23 05:56, bora.u...@mdc-berlin.de 
wrote:

Hi Bioc-Devel Team,



My package RCAS has been getting build errors on Nebbiolo2. It fails to run the 
tests/examples/vignettes all due to a missing dependency, which can’t be 
installed because BiocManager is not available.



Here is the build report:

https://bioconductor.org/checkResults/release/bioc-LATEST/RCAS/nebbiolo2-checksrc.html



The relevant error is :



Error in get_data_annotation_contrib_url(type) :

  Install 'BiocManager' from CRAN to get 'BioCann' contrib.url



Error: processing vignette 'RCAS.vignette.Rmd' failed with diagnostics:

Install 'BiocManager' from CRAN to get 'BioCann' contrib.url



The other machines all build it properly.



Best,

Bora



---

Dr. Bora Uyar

Bioinformatics Scientist

Bioinformatics and Omics Data Science Platform

Max Delbrueck Center (MDC) for Molecular Medicine

The Berlin Institute for Medical Systems Biology

Hannoversche Str. 28, 10115 Berlin







  [[alternative HTML version deleted]]



___

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] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)

[Martin Maechler]

> Henrik Bengtsson 
> on Sun, 29 Oct 2023 10:42:19 -0700 writes:

> Hello,

> the fix of PR18612
> (https://bugs.r-project.org/show_bug.cgi?id=18612) in
> r85380
> 
(https://github.com/wch/r-source/commit/2653cc6203fce4c48874111c75bbccac3ac4e803)
> caused a change in `dim<-()`.  Specifically, in the past,
> any `dim<-()` assignment would _always_ remove "dimnames"
> and "names" attributes per help("dim"):


> The replacement method changes the "dim" attribute
> (provided the new value is compatible) and removes any
> "dimnames" and "names" attributes.

> In the new version, assigning the same "dim" as before
> will no longer remove "dimnames".  I'm reporting here to
> check whether this change was intended, or if it was an
> unintended side effect of the bug fix.

> For example, in R Under development (unstable) (2023-10-21
> r85379), we would get:

>> x <- array(1:2, dim=c(1,2), dimnames=list("A",
>> c("a","b"))) str(dimnames(x))
> List of 2 $ : chr "A" $ : chr [1:2] "a" "b"

>> dim(x) <- dim(x) ## Removes "dimnames" no matter what
>> str(dimnames(x))
>  NULL


> whereas in R Under development (unstable) (2023-10-21
> r85380) and beyond, we now get:

>> x <- array(1:2, dim=c(1,2), dimnames=list("A",
>> c("a","b"))) str(dimnames(x))
> List of 2 $ : chr "A" $ : chr [1:2] "a" "b"

>> dim(x) <- dim(x) ## No longer removes "dimnames"
>> str(dimnames(x))
> List of 2 $ : chr "A" $ : chr [1:2] "a" "b"

>> dim(x) <- rev(dim(x)) ## Still removes "dimnames"
>> str(dimnames(x))
>  NULL

> /Henrik

Thank you, Henrik.

This is "funny" (in an unusal sense):
indeed, the change was *in*advertent, by me (svn rev 85380).

I had experimentally {i.e., only in my own private version of R-devel!}
modified the behavior of `dim<-` somewhat 
such it does *not* unnecessarily drop dimnames,
e.g., in your   `dim(x) <- dim(x)` case above,
one could really argue that it's a "true loss" if x loses
dimnames "unnecessarily" ... 

OTOH, I knew in the mean time that  `dim<-` has always been
documented to drop dimnames in all cases,  and even more
importantly, I got a strong recommendation to *not* go further
with this idea -- not only for back compatibility reasons, but
also for internal logical consistency.

Most probably, we will just revert this inadvertent change,
but before that ... since it has been out in the wild anyway,
we could quickly consider if it *did* break code.

I assume it did, or you would not have noticed ?

Martin

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

[Bioc-devel] Maximum allowed cores on Bioconductor Build System?

[Richard Heery]

Hi all,

I am wondering if there is a maximum allowed number of cores that can be
used when building a vignette on the Bioconductor Build System? I make use
of parallel computing in one of my vignettes, but if I don't use enough
cores, it takes too long to build the vignette and I get a timeout error.
Currently, I am just using BiocParallel::bpparam() to automatically choose
the parallel backend in the vignette.

Cheers,

Richard

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)

[Helske, Jouni]

Hi Dirk,

Looking more closely earlier failures, vignettes have always worked fine but 
the note on tests said that the CPU time was only 2.7 times over elapsed time, 
so maybe I was just lucky this time and got under 2.5. ;) Or testthat does 
something special...

Jouni

From: Dirk Eddelbuettel 
Sent: Friday, October 27, 2023 16:28
To: Helske, Jouni 
Cc: Dirk Eddelbuettel ; Ivan Krylov ; 
r-package-devel@r-project.org ; Conrad Sanderson 

Subject: Re: [R-pkg-devel] Too many cores used in examples (not caused by 
data.table)


Hi Jouni,

On 27 October 2023 at 13:02, Helske, Jouni wrote:
| Actually, the OMP_NUM_THREADS worked for vignettes and testthat tests, but
| didn't help with the examples. However, I just wrapped the problematic example

Now I am confused.

What is your understanding of why it helps in one place and not the other?

| with \donttest as for some reason this issue only happened with a single
| seemingly simple example (hence the "weird" in the earlier NEWS due to
| frustration, I changed this to the CRAN version).
|
| Thanks for reminding me about the resetting the number of cores, will fix that
| to the next version.

I have an idea for a RcppArmadillo-based helper function. We can save the
initial values of the environment variable in .onLoad and cache it. A simple
helper function pair can then dial the environment variable down and reset it
to the cached value.

Dirk

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

[[alternative HTML version deleted]]

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