Re: [Bioc-devel] DataFrameList to Wide Format DataFrame

2021-12-16 Thread Dario Strbenac via Bioc-devel
Hello,

Ah, yes, the sample names should of course be in the rows - Friday afternoon 
error. In the question, I specified "largely the same set of features", 
implying that the overlap is not complete. So, the example below will error.

DFL <- DataFrameList(X = DataFrame(a = 1:3, b = 3:1, row.names = LETTERS[1:3]),
 Y = DataFrame(b = 4:6, c = 6:4, row.names = 
LETTERS[20:22]))
unlist(DFL)
Error in .aggregate_and_align_all_colnames(all_colnames, strict.colnames = 
strict.colnames) : 
  the DFrame objects to combine must have the same column names

This is long but works:

allFeatures <- unique(unlist(lapply(DFL, colnames)))
DFL <- lapply(DFL, function(DF)
{
  missingFeatures <- setdiff(allFeatures, colnames(DF))
  DF[missingFeatures] <- NA
  DF
})
DFLflattened <- do.call(rbind, DFL)

Is there a one-line function for it?

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] DataFrameList to Wide Format DataFrame

2021-12-16 Thread Hervé Pagès
A metadata column on a DataFrame runs along its 2nd dimension so is not 
a good place to put the list names.


Have you tried unlist()?

  library(S4Vectors)

  DF <- DataFrame(id=letters[1:10], score=runif(10))

  f <- sample(LETTERS[1:3], 10, replace=TRUE)

  DFL <- split(DF, f)

  DFL
  # SplitDataFrameList of length 3
  # $A
  # DataFrame with 2 rows and 2 columns
  #    id score
  #    
  # 1   f  0.894709
  # 2   h  0.801125
  #
  # $B
  # DataFrame with 1 row and 2 columns
  #    id score
  #    
  # 1   d  0.538166
  #
  # $C
  # DataFrame with 7 rows and 2 columns
  #    id score
  #    
  # 1   a 0.0145477
  # 2   b 0.2507581
  # 3   c 0.4388678
  # 4   e 0.5219524
  # 5   g 0.6377634
  # 6   i 0.1892103
  # 7   j 0.1829650

  unlist(DFL)

  # DataFrame with 10 rows and 2 columns
  #    id score
  #    
  # A   f 0.8947085
  # A   h 0.8011255
  # B   d 0.5381664
  # C   a 0.0145477
  # C   b 0.2507581
  # C   c 0.4388678
  # C   e 0.5219524
  # C   g 0.6377634
  # C   i 0.1892103
  # C   j 0.1829650

BTW this is a user question so is more appropriate for the support site.

H.

On 16/12/2021 22:00, Dario Strbenac via Bioc-devel wrote:

Good day,

Is there a function in the S4Vectors API which converts a 
DataFrameList into a DataFrame, automatically putting the list names 
into one of the metadata columns, analogous to MultiAssayExperiment's 
wideFormat function? The scenario is mutliple data sets from different 
organisations measuring the largely the same set of features and 
patient outcome, but on completely different sets of patients in each 
organisation.


--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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

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


[Bioc-devel] DataFrameList to Wide Format DataFrame

2021-12-16 Thread Dario Strbenac via Bioc-devel
Good day,

Is there a function in the S4Vectors API which converts a DataFrameList into a 
DataFrame, automatically putting the list names into one of the metadata 
columns, analogous to MultiAssayExperiment's wideFormat function? The scenario 
is mutliple data sets from different organisations measuring the largely the 
same set of features and patient outcome, but on completely different sets of 
patients in each organisation.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Hiroaki Yutani
Yes, it's my fault that I didn't consider the case when no fonts are
available. I'll improve the code until the next submission to CRAN.
Thanks for your advice!

Best,
Hiroaki Yutani

2021年12月17日(金) 1:40 Tomas Kalibera :
>
>
> On 12/16/21 5:16 PM, Hiroaki Yutani wrote:
> > Thanks for the details and the suggestions. My package uses
> > systemfonts package for illustration purposes only in the examples, so
> > I'm not that desperate to find the root cause this time. I'll try
> > using winbuilder in case I need to.
>
> I see. Maybe best then making the example more robust when no fonts are
> found, on different platforms.
>
> Best
> Tomas
>
> >
> > Best,
> > Hiroaki Yutani
> >
> > 2021年12月17日(金) 0:52 Tomas Kalibera :
> >
> >>
> >> On 12/16/21 4:17 PM, Hiroaki Yutani wrote:
>  This would be an empty character vector on my Alpine Linux server as
>  well.
> >>> I see, thanks for the information. Sorry for my lack of consideration on 
> >>> this.
> >>>
>  So there are 127 *.ttf files installed, but systemfonts::system_fonts()
>  does not find any of these.
> >>> Thanks for investigating quickly! Then, it seems I should wait for the
> >>> problem to be solved on systemfonts' side. I'm curious what's the
> >>> difference between r-devel-windows-x86_64-new-TK, on which the check
> >>> doesn't fail, by the way.
> >> It is also Windows Server 2022 with GUI, a quite fresh installation. The
> >> checks run in a docker container (also WS2022,
> >> mcr.microsoft.com/windows/server:ltsc2022, without any manually
> >> installed fonts).
> >>
> >> Actually there is no manually installed software there, all that is
> >> installed is (in this order):
> >>
> >> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1
> >> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1
> >> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1
> >>
> >> plus R and R packages.
> >>
> >> I assume you can reproduce on Winbuilder, and so perhaps you could
> >> create a version of your package with a lot of instrumentation/print
> >> messages and submit there to find the cause? Possibly also an
> >> instrumented variant of systemfonts.
> >>
> >> Best
> >> Tomas
> >>
> >>> Best,
> >>> Hiroaki Yutani
> >>>
> >>> 2021年12月16日(木) 23:57 Uwe Ligges :
> 
>  On 16.12.2021 15:34, Sebastian Meyer wrote:
> > Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:
> >> Hi,
> >>
> >> My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.
> >>
> >> https://cran.r-project.org/web/checks/check_results_string2path.html
> >>
> >> It seems the problem is that there is no available font that meets the
> >> condition in the following code. Is it irrational to assume at least
> >> one TrueType or OpenType font is installed in the system?
> >>
> >>available_fonts <- systemfonts::system_fonts()$path
> >>
> >># string2path supports only TrueType or OpenType formats
> >>ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$",
> >> available_fonts)]
> >>
>  The machine that is running " r-devel-windows-x86_64-new-UL" is a
>  freshly installed Windows Server 2022 with GUI. The standard fonts are
>  available, but no extra fonts isntalled.
> 
>  To confirm:
> 
> > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))
> 
>  dat fon ini ttc ttf xml
>   1 192   1  16 127   1
> 
> 
>  So there are 127 *.ttf files installed, but systemfonts::system_fonts()
>  does not find any of these.
> 
>  Best,
>  Uwe Ligges
> 
> 
> 
> 
> 
> > This would be an empty character vector on my Alpine Linux server as
> > well. The system_fonts() there only contain ".pcf.gz" files from
> > "/usr/share/fonts/misc/".
> >
> > Note that the "systemfonts" package on which you rely currently also
> > fails on that CRAN check flavour for a similar reason
> > (https://cran.r-project.org/web/checks/check_results_systemfonts.html).
> > On my Alpine Linux system, from example("register_font",
> > package="systemfonts"):
> >
> > fonts <- system_fonts()
> > plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
> > bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
> > italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
> > ## Error in sample.int(length(x), size, replace, prob) :
> > ##   invalid first argument
> >
> > (as there are no italic fonts).
> >
> > HTH,
> >
> >Sebastian Meyer
> >
> >> I'm wondering if I need to release a new version to avoid this test
> >> failure. Note that, the other Windows r-devel machine
> >> (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
> >> that something is wrong with 

Re: [R-pkg-devel] pandoc missing on r-{release,oldrel}-macos-x86_64

2021-12-16 Thread Dirk Eddelbuettel


On 17 December 2021 at 09:51, Simon Urbanek wrote:
| Sure, installed pandoc 2.16.2.

Perfect, thank you!

Dirk

| Cheers,
| Simon
| 
| 
| > On Dec 17, 2021, at 9:21 AM, Dirk Eddelbuettel  wrote:
| > 
| > 
| > CRAN results flag NOTEs on the two platforms
| >   r-release-macos-x86_64
| >   r-oldrel-macos-x86_64
| > because `pandoc` is apparently missing.  These platforms being somewhat
| > common, could pandoc be installed?  Or are they running such a jurassic
| > version that no premade pandoc is available _anywhere_ ?
| > 
| > Simon, can you advise?
| > 
| > Thanks,  Dirk
| > 
| > -- 
| > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > 
| 

-- 
https://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: [R-pkg-devel] pandoc missing on r-{release,oldrel}-macos-x86_64

2021-12-16 Thread Simon Urbanek
Sure, installed pandoc 2.16.2.

Cheers,
Simon


> On Dec 17, 2021, at 9:21 AM, Dirk Eddelbuettel  wrote:
> 
> 
> CRAN results flag NOTEs on the two platforms
>   r-release-macos-x86_64
>   r-oldrel-macos-x86_64
> because `pandoc` is apparently missing.  These platforms being somewhat
> common, could pandoc be installed?  Or are they running such a jurassic
> version that no premade pandoc is available _anywhere_ ?
> 
> Simon, can you advise?
> 
> Thanks,  Dirk
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

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


[R-pkg-devel] pandoc missing on r-{release,oldrel}-macos-x86_64

2021-12-16 Thread Dirk Eddelbuettel


CRAN results flag NOTEs on the two platforms
   r-release-macos-x86_64
   r-oldrel-macos-x86_64
because `pandoc` is apparently missing.  These platforms being somewhat
common, could pandoc be installed?  Or are they running such a jurassic
version that no premade pandoc is available _anywhere_ ?

Simon, can you advise?

Thanks,  Dirk

-- 
https://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: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Hiroaki Yutani
Thanks for the details and the suggestions. My package uses
systemfonts package for illustration purposes only in the examples, so
I'm not that desperate to find the root cause this time. I'll try
using winbuilder in case I need to.

Best,
Hiroaki Yutani

2021年12月17日(金) 0:52 Tomas Kalibera :

>
>
> On 12/16/21 4:17 PM, Hiroaki Yutani wrote:
> >> This would be an empty character vector on my Alpine Linux server as
> >> well.
> > I see, thanks for the information. Sorry for my lack of consideration on 
> > this.
> >
> >> So there are 127 *.ttf files installed, but systemfonts::system_fonts()
> >> does not find any of these.
> > Thanks for investigating quickly! Then, it seems I should wait for the
> > problem to be solved on systemfonts' side. I'm curious what's the
> > difference between r-devel-windows-x86_64-new-TK, on which the check
> > doesn't fail, by the way.
>
> It is also Windows Server 2022 with GUI, a quite fresh installation. The
> checks run in a docker container (also WS2022,
> mcr.microsoft.com/windows/server:ltsc2022, without any manually
> installed fonts).
>
> Actually there is no manually installed software there, all that is
> installed is (in this order):
>
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1
>
> plus R and R packages.
>
> I assume you can reproduce on Winbuilder, and so perhaps you could
> create a version of your package with a lot of instrumentation/print
> messages and submit there to find the cause? Possibly also an
> instrumented variant of systemfonts.
>
> Best
> Tomas
>
> >
> > Best,
> > Hiroaki Yutani
> >
> > 2021年12月16日(木) 23:57 Uwe Ligges :
> >>
> >>
> >> On 16.12.2021 15:34, Sebastian Meyer wrote:
> >>> Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:
>  Hi,
> 
>  My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.
> 
>  https://cran.r-project.org/web/checks/check_results_string2path.html
> 
>  It seems the problem is that there is no available font that meets the
>  condition in the following code. Is it irrational to assume at least
>  one TrueType or OpenType font is installed in the system?
> 
>    available_fonts <- systemfonts::system_fonts()$path
> 
>    # string2path supports only TrueType or OpenType formats
>    ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$",
>  available_fonts)]
> 
> >> The machine that is running " r-devel-windows-x86_64-new-UL" is a
> >> freshly installed Windows Server 2022 with GUI. The standard fonts are
> >> available, but no extra fonts isntalled.
> >>
> >> To confirm:
> >>
> >>   > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))
> >>
> >> dat fon ini ttc ttf xml
> >> 1 192   1  16 127   1
> >>
> >>
> >> So there are 127 *.ttf files installed, but systemfonts::system_fonts()
> >> does not find any of these.
> >>
> >> Best,
> >> Uwe Ligges
> >>
> >>
> >>
> >>
> >>
> >>> This would be an empty character vector on my Alpine Linux server as
> >>> well. The system_fonts() there only contain ".pcf.gz" files from
> >>> "/usr/share/fonts/misc/".
> >>>
> >>> Note that the "systemfonts" package on which you rely currently also
> >>> fails on that CRAN check flavour for a similar reason
> >>> (https://cran.r-project.org/web/checks/check_results_systemfonts.html).
> >>> On my Alpine Linux system, from example("register_font",
> >>> package="systemfonts"):
> >>>
> >>> fonts <- system_fonts()
> >>> plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
> >>> bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
> >>> italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
> >>> ## Error in sample.int(length(x), size, replace, prob) :
> >>> ##   invalid first argument
> >>>
> >>> (as there are no italic fonts).
> >>>
> >>> HTH,
> >>>
> >>>   Sebastian Meyer
> >>>
>  I'm wondering if I need to release a new version to avoid this test
>  failure. Note that, the other Windows r-devel machine
>  (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
>  that something is wrong with r-devel-windows-x86_64-new-UL.
> 
>  Any suggestions?
> 
>  Best,
>  Hiroaki Yutani
> 
>  __
>  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-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel

__

Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Tomas Kalibera



On 12/16/21 4:17 PM, Hiroaki Yutani wrote:

This would be an empty character vector on my Alpine Linux server as
well.

I see, thanks for the information. Sorry for my lack of consideration on this.


So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of these.

Thanks for investigating quickly! Then, it seems I should wait for the
problem to be solved on systemfonts' side. I'm curious what's the
difference between r-devel-windows-x86_64-new-TK, on which the check
doesn't fail, by the way.


It is also Windows Server 2022 with GUI, a quite fresh installation. The 
checks run in a docker container (also WS2022, 
mcr.microsoft.com/windows/server:ltsc2022, without any manually 
installed fonts).


Actually there is no manually installed software there, all that is 
installed is (in this order):


https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1

plus R and R packages.

I assume you can reproduce on Winbuilder, and so perhaps you could 
create a version of your package with a lot of instrumentation/print 
messages and submit there to find the cause? Possibly also an 
instrumented variant of systemfonts.


Best
Tomas



Best,
Hiroaki Yutani

2021年12月16日(木) 23:57 Uwe Ligges :



On 16.12.2021 15:34, Sebastian Meyer wrote:

Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:

Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

https://cran.r-project.org/web/checks/check_results_string2path.html

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

  available_fonts <- systemfonts::system_fonts()$path

  # string2path supports only TrueType or OpenType formats
  ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$",
available_fonts)]


The machine that is running " r-devel-windows-x86_64-new-UL" is a
freshly installed Windows Server 2022 with GUI. The standard fonts are
available, but no extra fonts isntalled.

To confirm:

  > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))

dat fon ini ttc ttf xml
1 192   1  16 127   1


So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of these.

Best,
Uwe Ligges






This would be an empty character vector on my Alpine Linux server as
well. The system_fonts() there only contain ".pcf.gz" files from
"/usr/share/fonts/misc/".

Note that the "systemfonts" package on which you rely currently also
fails on that CRAN check flavour for a similar reason
(https://cran.r-project.org/web/checks/check_results_systemfonts.html).
On my Alpine Linux system, from example("register_font",
package="systemfonts"):

fonts <- system_fonts()
plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
##   invalid first argument

(as there are no italic fonts).

HTH,

  Sebastian Meyer


I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

__
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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


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


Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Hiroaki Yutani
> This would be an empty character vector on my Alpine Linux server as
> well.

I see, thanks for the information. Sorry for my lack of consideration on this.

> So there are 127 *.ttf files installed, but systemfonts::system_fonts()
> does not find any of these.

Thanks for investigating quickly! Then, it seems I should wait for the
problem to be solved on systemfonts' side. I'm curious what's the
difference between r-devel-windows-x86_64-new-TK, on which the check
doesn't fail, by the way.

Best,
Hiroaki Yutani

2021年12月16日(木) 23:57 Uwe Ligges :
>
>
>
> On 16.12.2021 15:34, Sebastian Meyer wrote:
> > Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:
> >> Hi,
> >>
> >> My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.
> >>
> >> https://cran.r-project.org/web/checks/check_results_string2path.html
> >>
> >> It seems the problem is that there is no available font that meets the
> >> condition in the following code. Is it irrational to assume at least
> >> one TrueType or OpenType font is installed in the system?
> >>
> >>  available_fonts <- systemfonts::system_fonts()$path
> >>
> >>  # string2path supports only TrueType or OpenType formats
> >>  ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$",
> >> available_fonts)]
> >>
>
> The machine that is running " r-devel-windows-x86_64-new-UL" is a
> freshly installed Windows Server 2022 with GUI. The standard fonts are
> available, but no extra fonts isntalled.
>
> To confirm:
>
>  > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))
>
> dat fon ini ttc ttf xml
>1 192   1  16 127   1
>
>
> So there are 127 *.ttf files installed, but systemfonts::system_fonts()
> does not find any of these.
>
> Best,
> Uwe Ligges
>
>
>
>
>
> > This would be an empty character vector on my Alpine Linux server as
> > well. The system_fonts() there only contain ".pcf.gz" files from
> > "/usr/share/fonts/misc/".
> >
> > Note that the "systemfonts" package on which you rely currently also
> > fails on that CRAN check flavour for a similar reason
> > (https://cran.r-project.org/web/checks/check_results_systemfonts.html).
> > On my Alpine Linux system, from example("register_font",
> > package="systemfonts"):
> >
> > fonts <- system_fonts()
> > plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
> > bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
> > italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
> > ## Error in sample.int(length(x), size, replace, prob) :
> > ##   invalid first argument
> >
> > (as there are no italic fonts).
> >
> > HTH,
> >
> >  Sebastian Meyer
> >
> >> I'm wondering if I need to release a new version to avoid this test
> >> failure. Note that, the other Windows r-devel machine
> >> (r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
> >> that something is wrong with r-devel-windows-x86_64-new-UL.
> >>
> >> Any suggestions?
> >>
> >> Best,
> >> Hiroaki Yutani
> >>
> >> __
> >> 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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Uwe Ligges




On 16.12.2021 15:34, Sebastian Meyer wrote:

Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:

Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

https://cran.r-project.org/web/checks/check_results_string2path.html

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

 available_fonts <- systemfonts::system_fonts()$path

 # string2path supports only TrueType or OpenType formats
 ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", 
available_fonts)]




The machine that is running " r-devel-windows-x86_64-new-UL" is a 
freshly installed Windows Server 2022 with GUI. The standard fonts are 
available, but no extra fonts isntalled.


To confirm:

> table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))

dat fon ini ttc ttf xml
  1 192   1  16 127   1


So there are 127 *.ttf files installed, but systemfonts::system_fonts() 
does not find any of these.


Best,
Uwe Ligges





This would be an empty character vector on my Alpine Linux server as 
well. The system_fonts() there only contain ".pcf.gz" files from 
"/usr/share/fonts/misc/".


Note that the "systemfonts" package on which you rely currently also 
fails on that CRAN check flavour for a similar reason 
(https://cran.r-project.org/web/checks/check_results_systemfonts.html).
On my Alpine Linux system, from example("register_font", 
package="systemfonts"):


fonts <- system_fonts()
plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
##   invalid first argument

(as there are no italic fonts).

HTH,

 Sebastian Meyer


I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

__
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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Sebastian Meyer

Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:

Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

https://cran.r-project.org/web/checks/check_results_string2path.html

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

 available_fonts <- systemfonts::system_fonts()$path

 # string2path supports only TrueType or OpenType formats
 ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)]



This would be an empty character vector on my Alpine Linux server as 
well. The system_fonts() there only contain ".pcf.gz" files from 
"/usr/share/fonts/misc/".


Note that the "systemfonts" package on which you rely currently also 
fails on that CRAN check flavour for a similar reason 
(https://cran.r-project.org/web/checks/check_results_systemfonts.html).
On my Alpine Linux system, from example("register_font", 
package="systemfonts"):


fonts <- system_fonts()
plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
##   invalid first argument

(as there are no italic fonts).

HTH,

Sebastian Meyer


I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

__
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] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

2021-12-16 Thread Hiroaki Yutani
Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

https://cran.r-project.org/web/checks/check_results_string2path.html

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

available_fonts <- systemfonts::system_fonts()$path

# string2path supports only TrueType or OpenType formats
ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)]

I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

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


Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'

2021-12-16 Thread Stephen Berman
On Thu, 16 Dec 2021 09:57:40 + Prof Brian Ripley  
wrote:

> On 16/12/2021 09:13, Stephen Berman wrote:
>> I just did `svn up' on the R development sources, switched to the build
>> directory (I build R out of tree), ran make, and got this:
>
> Precisely which version of R-devel updating from which version? -- this is an
> area that has changed frequently in the last several days.

Yes, it's been more than a month since my last build: I updated from

r81161 | maechler | 2021-11-08 14:30:50 +0100 (Mon, 08 Nov 2021) | 1 line

to

r81384 | pd | 2021-12-16 01:20:16 +0100 (Thu, 16 Dec 2021) | 1 line

> I suspect 'make clean' is not enough -- use 'make distclean' for an ab initio
> build.

That certainly gave me a clean slate -- and the build then succeeded.
Thanks.

On Thu, 16 Dec 2021 12:58:55 +0300 Ivan Krylov  wrote:

> On Thu, 16 Dec 2021 10:13:11 +0100
> Stephen Berman  wrote:
>
>> Is this a known issue and is there a fix?
>
> For me, the fix was to remove the already-installed
> $SVNROOT/library/utils (which didn't yet contain hashtab) and re-run
> make, letting the R build process re-install it from scratch.

I guess that would have been $BUILD/library/utils for me?  Perhaps that
would have shortened the build time, but I had already done `make
distclean' and a complete rebuild was quick enough.  But thanks for the
reply.

Steve Berman

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


Re: [Bioc-devel] BioC2022 Seattle July 27-29 hybrid conference organizing committee

2021-12-16 Thread Levi Waldron
Correction, I'd like to invite any interested members of the **community**
to get involved! Feel free to get in touch with me with any questions. This
is a great way to get to know other passionate Bioconductor users and
developers while providing a great service to the community.

On Thu, Dec 16, 2021 at 1:53 PM Levi Waldron 
wrote:

> I'd like to invite any interested members of the committee to get involved
> in organizing BioC2022, planned to be in a hybrid format in Seattle
> July 27-29, 2022. There is lots to be done, including sponsorship and
> funding, outreach, website, workshop technical organization, program
> development, code of conduct communication and enforcement, and local
> organization.  Please fill out this form if you'd like to get involved:
> https://forms.gle/cbjHww7uHJFRzwVx5
>
>

[[alternative HTML version deleted]]

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


[Bioc-devel] BioC2022 Seattle July 27-29 hybrid conference organizing committee

2021-12-16 Thread Levi Waldron
I'd like to invite any interested members of the committee to get involved
in organizing BioC2022, planned to be in a hybrid format in Seattle
July 27-29, 2022. There is lots to be done, including sponsorship and
funding, outreach, website, workshop technical organization, program
development, code of conduct communication and enforcement, and local
organization.  Please fill out this form if you'd like to get involved:
https://forms.gle/cbjHww7uHJFRzwVx5

[[alternative HTML version deleted]]

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


Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'

2021-12-16 Thread Prof Brian Ripley

On 16/12/2021 09:13, Stephen Berman wrote:

I just did `svn up' on the R development sources, switched to the build
directory (I build R out of tree), ran make, and got this:


Precisely which version of R-devel updating from which version? -- this 
is an area that has changed frequently in the last several days.


I suspect 'make clean' is not enough -- use 'make distclean' for an ab 
initio build.




make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src'
../../../../library/tools/libs/tools.so is unchanged
make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src'
make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src'
make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools'
installing 'sysdata.rda'
Error: 'hashtab' is not an exported object from 'namespace:utils'
Execution halted
make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] 
Error 1
make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[3]: *** [Makefile:36: all] Error 2
make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[2]: *** [Makefile:37: R] Error 1
make[2]: Leaving directory '/home/steve/build/r-devel/src/library'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/home/steve/build/r-devel/src'
make: *** [Makefile:61: R] Error 1

I then did `make clean', ran configure and make again, and got the same
failure.  Is this a known issue and is there a fix?

Steve Berman

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



--
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] build failure: 'hashtab' is not an exported object from 'namespace:utils'

2021-12-16 Thread Ivan Krylov
On Thu, 16 Dec 2021 10:13:11 +0100
Stephen Berman  wrote:

> Is this a known issue and is there a fix?

For me, the fix was to remove the already-installed
$SVNROOT/library/utils (which didn't yet contain hashtab) and re-run
make, letting the R build process re-install it from scratch.

-- 
Best regards,
Ivan

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


[Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'

2021-12-16 Thread Stephen Berman
I just did `svn up' on the R development sources, switched to the build
directory (I build R out of tree), ran make, and got this:

make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src'
../../../../library/tools/libs/tools.so is unchanged
make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src'
make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src'
make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools'
installing 'sysdata.rda'
Error: 'hashtab' is not an exported object from 'namespace:utils'
Execution halted
make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] 
Error 1
make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[3]: *** [Makefile:36: all] Error 2
make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[2]: *** [Makefile:37: R] Error 1
make[2]: Leaving directory '/home/steve/build/r-devel/src/library'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/home/steve/build/r-devel/src'
make: *** [Makefile:61: R] Error 1

I then did `make clean', ran configure and make again, and got the same
failure.  Is this a known issue and is there a fix?

Steve Berman

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


Re: [Rd] Feature request: Change default library path on Windows

2021-12-16 Thread Steve Haroz
Thank you for the update. Really helpful!
Between this and the unicode changes, the next version will have a very
positive impact on Windows users.

Best,
Steve

On Mon, Dec 13, 2021 at 1:02 PM Tomas Kalibera 
wrote:

> The default was now changed in R-devel to the local application data
> (e.g. C:\Users\username\AppData\Local), which should solve the issues
> with synchronization/backup/etc services and seems to be more in line
> with conventions for the OS. It is a hidden folder, to open in Windows
> explorer one can use e.g. shell.exec() from R.
>
> Best
> Tomas
>
> On 7/27/21 1:12 PM, Tomas Kalibera wrote:
> > On 7/26/21 1:44 AM, Steve Haroz wrote:
> >> Thanks Ben. I just sent a request for a bugzilla login.
> >> Jeroen chimed in earlier in support.
> >
> > Please note this has been reported, discussed and considered already,
> > last time in PR#17842 (though proposing a different replacement for
> > the default).
> >
> > I think changing the default from user documents to something else
> > would make sense to consider together with some other breaking change
> > for users, not in isolation, if at all. While the change may help
> > users with a quota on the documents directory (e.g. shared on a cloud,
> > backup, etc), it will make it harder to find the library for others,
> > who would not notice the change to the documented behavior, and I
> > assume that would still be a much larger group.
> >
> > Of course it does not help that it is not clear what the correct
> > location should be now, and certainly there is little hope it won't
> > change again, soon. My understanding is that the choice was originally
> > correct when made, following the Microsoft guidelines.
> >
> > As discussed here as well, users may choose their own library path
> > (?.libPaths).
> >
> > The installation location for R itself can be changed e.g. via /DIR
> > option of the installer (see /?). This is useful e.g. when installing
> > R only for the current user (/CURRENTUSER) and it impacts also the
> > location of the library - it is then inside the given tree.
> >
> > Best
> > Tomas
> >
> >
> >
> >>
> >> Cheers,
> >> Steve
> >>
> >> __
> >> 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] MS Windows: R does not escape quotes in CLI options the same way as Rterm and Rscript

2021-12-16 Thread Tomas Kalibera



On 12/15/21 10:48 PM, Henrik Bengtsson wrote:

On MS Windows 10, the following works:


Rscript --vanilla -e "\"abc\""

[1] "abc"

and also:


Rterm --vanilla --no-echo -e "\"abc.txt\""

[1] "abc.txt"

whereas attempting the same with 'R' fails;


R --vanilla --no-echo -e "\"abc.txt\""

Error: object 'abc' not found
Execution halted

I get this with R 4.1.2 and R Under development (unstable) (2021-12-14
r81376 ucrt).

Is this a bug?


Yes, R.exe does not properly handle quotes (and backslashes preceding a 
quote, and trailing backslashes). This is the same as PR#18139 for 
shQuote(). I will put that on my list


Best
Tomas



/Henrik

__
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] meaning of browser(skipCalls=) [and multiple mouse buttons]

2021-12-16 Thread Martin Maechler
> Frederick Eaton 
> on Wed, 15 Dec 2021 20:09:46 -0800 writes:

> Just following up to check if anyone has had time to look over these 
patches.
> Frederick

I strongly guess that nobody has.

Let me give you my perception of what you have tried to
propose/use,  and why I hadn't thought I should put in time for it:

You had started the thread by proposing "to override stopifnot()",
something which I (even though principal author of the function)
don't find a good idea at all:

stopifnot() is just one important utility function that will
call stop() under some circumstances.
If you want to tweak  error handling / debugging / browser, ..
you need to work on the level of error conditions, their
handlers, etc. 

Secondly, you've mixed this up with mouse button
action/interrupt/.. handling  which may be a cool and nice idea,
but then your  `xbindkey`-etc code is, I think, only/entirely
for X11-based R interfaces, and I think this would only be a
Linux console, possibly one from using ESS (Emacs Speaks Statistics),
but most probably (but I'm guessing here) not even relevant when
using Rstudio on Linux, and even less relevant for any of the
other ways R is used interactively on non-Linux platforms. Maybe
it would also apply to *some* uses of R on the Mac, but not even
the default R-Mac GUI..

Sorry that this not as much encouraging as it probably should
be, but I though you'd rather want *some* feedback than none...

Best,
Martin



> On Wed, Dec 08, 2021 at 12:24:47AM -0800, Frederick Eaton wrote:
>> Dear R Core Team,
>> 
>> I'm attaching a proposed patch to hopefully address my confusions 
regarding the documentation of browser(). I'm not sure if all the material I 
added is correct, but I made experiments to confirm that the behavior is at 
least roughly as described.
>> 
>> patch ./src/library/base/man/browser.Rd < browser.patch
>> 
>> Also, here is a patch to support multiple mouse buttons in 
getGraphicsEvent(). This must be edited before it can be applied, I decided to 
keep the old code in an 'if(0)' to help make it clearer that my code is 
essentially doing the same thing.
>> 
>> 
https://github.com/navarum/tweaks/blob/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
>> wget -O - 
https://raw.githubusercontent.com/navarum/tweaks/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
 | patch -p1
>> 
>> It would be useful to have support in R for more than three mouse 
buttons because this enables the use of the mouse wheel (buttons 4 and 5), 
which can provide a more convenient interface when adjusting numbers and 
graphics and so on. I also have shift+wheel bound to buttons 6 and 7 via 
xbindkeys and xte, which I use for horizontal scrolling, via a trick from the 
web somewhere:
>> 
>> $ cat .xbindkeysrc.scm | grep xte
>> (xbindkey '(shift "b:4") "xte 'mouseclick 6'")
>> (xbindkey '(shift "b:5") "xte 'mouseclick 7'")
>> 
>> I hope that these contributions can be found acceptable.
>> 
>> Thank you in advance,
>> 
>> Frederick
>> 
>> 
>> 
>> On Mon, Nov 22, 2021 at 09:13:58AM -0800, Frederick Eaton wrote:
>>> Dear R Devel,
>>> 
>>> I have been advised to use "options(error=recover)" to enable
>>> debugging on errors. But sometimes it would seem more convenient to
>>> override "stopifnot", for example:
>>> 
>>> stopifnot = function(b) { if(!b) { browser(skipCalls=1); } }
>>> 
>>> However, this doesn't do what I expected. On looking closer I find
>>> that the "skipCalls" argument seems to be ignored except when printing
>>> the "Called from: " message; it does not affect the evaluation context
>>> or the output of 'where':
>>> 
>>> > var=2; f=function(){var=1; browser(skipCalls=0)}; f()
>>> Called from: f()
>>> Browse[1]> var
>>> [1] 1
>>> Browse[1]> where
>>> where 1: f()
>>> 
>>> Browse[1]> Q
>>> > var=2; f=function(){var=1; browser(skipCalls=1)}; f()
>>> Called from: top level Browse[1]> var
>>> [1] 1
>>> Browse[1]> where
>>> where 1: f()
>>> 
>>> Browse[1]> Q
>>> > var=2; f=function(){var=1; browser(skipCalls=2)}; f()
>>> Called from: top level Browse[1]> var
>>> [1] 1
>>> Browse[1]> where
>>> where 1: f()
>>> 
>>> Browse[1]> Q
>>> 
>>> So it appears that the "browser()" API does not actually make it
>>> possible to call this built-in function from within another R function
>>> and thereby emulate the same behavior as calling browser() directly.
>>> 
>>> If this is the case, it might be good to have it fixed or documented.
>>> I am aware of "browser(expr=)", but this requires editing the
>>> particular call that failed. The documentation for "browser()" led me
>>> to hope that my use case would be supported, if only because it admits
>>> that users might want to