Re: [R-pkg-devel] Help Debugging Debian Error

[Paul Hibbing]

Thanks for the tips. It appears the error is indeed related to the
matchingMarkets package, but specifically an issue with rJava
configuration. Now I get the following (see
https://artifacts.r-hub.io/PAutilities_1.0.0.tar.gz-54a555386e924de6a53385479a1e199f/PAutilities.Rcheck/00check.log
):

VALIDATE...PREFS...MATCHES [*ignore this -- these are updates I printed
myself to pinpoint matchingMarkets as the culprit*]
WARNING: Initial Java 12 release has broken JNI support and does NOT work.
Use stable Java 11 (or watch for 12u if avaiable).
ERROR: Java exception occurred during rJava bootstrap - see stderr for Java
stack trace. Exception in thread "main"

* Is there a specification I can provide to get around this?

* Since the current CRAN version of my package depends on a recently
orphaned package, I am due to provide a new release by the 17th (per an
email from Prof. Brian Ripley). Is this a hard deadline, or can/should I
notify someone and/or request an extension? To complicate matters, I have a
publication coming out imminently, in which my package plays a central
role. So it's important that I avoid any lapse in its availability.

Paul

On Fri, May 15, 2020 at 5:06 AM Gábor Csárdi  wrote:

> You don't need to move the files around, though, just use a more
> verbose testthat reporter, e.g. in testthat.R use
>
> test_check("PAutilities", reporter = "summary")
>
> and then at least you'll know where it crashes. But to fix this,
> you'll probably need to debug it locally. You can do that in Docker if
> you don't have a local Linux machine.
>
> Gabor
>
> On Fri, May 15, 2020 at 10:00 AM Ivan Krylov 
> wrote:
> >
> > On Fri, 15 May 2020 03:50:12 -0400
> > Paul Hibbing  wrote:
> >
> > > Complete output:
> > >   > library(testthat)
> > >   > library(PAutilities)
> > >   >
> > >   > test_check("PAutilities")
> >
> > It seems to me that the R process crashes while running your tests, but
> > since testthat::test_check captures everything to summarise it later,
> > you don't get to know where the crash occurs.
> >
> > Perhaps if you (temporarily) move your tests out of testthat/
> > subdirectory and remove the context() and testthat::test_that("...",
> > { ... }) calls, you would be able to see the exact location of the
> > crash in the *.Rout files?
> >
> > That said, it's probably one of your dependencies that's responsible
> > for the crash, not your package, since there is no compiled code.
> >
> > --
> > Best regards,
> > Ivan
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] [External] Re: Testing before release (was: edit() doubles backslashes when keep.source=TRUE)

[luke-tierney]

On Fri, 15 May 2020, Abby Spurdle wrote:


This perhaps diverges from the intent of the thread, but...

I wanted to say I'm extremely grateful to the people who go the
through the bug reports.
It's an extremely important job (in the long run, particularly), but
perhaps not quite as "sexy"-sounding as other roles, and probably
under-valued.

So, thank you to the bug-fixers...


Yes: Thank You!!

Best,

luke



:)

On Sat, May 16, 2020 at 2:54 AM Duncan Murdoch  wrote:


On 15/05/2020 9:41 a.m., Martin Maechler wrote:
[ deletions ]



 Why does nobody anymore  help R development by working with
 "R-devel", or at least then the alpha, beta and the "RC"
 (Release Candidate) versions that we release daily for about one
 month before the final release?

 Notably a highly staffed enterprise such as Rstudio (viz the bug
 report 17800 above), but also others could really help by
 starting to use the "next version" of R on a routine basis ...


I understand the whining, bugs that get released are embarrassing.  But
when I read the NEWS, I can see that both the NEW FEATURES and BUG FIXES
sections of x.y.0 releases tend to be much longer than the BUG FIXES
sections in patch releases.  That seems to indicate that things are
working reasonably well.

For a really rough measure, just counting bullet points:

R 4.0.0:  65 new features, 55 bug fixes

R 3.6.3:  1 new feature, 7 bug fixes

R 3.6.2:  2 new features, 21 bug fixes

R 3.6.1:  0 new features, 16 bug fixes

R 3.6.0:  72 new features, 62 bug fixes

You can get these numbers programmatically:

R4 <- news()
table(R4$Category)

R3 <- news(package = "R-3")
table(R3$Version, R3$Category)

Duncan Murdoch

__
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



--
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] Testing before release (was: edit() doubles backslashes when keep.source=TRUE)

[Abby Spurdle]

This perhaps diverges from the intent of the thread, but...

I wanted to say I'm extremely grateful to the people who go the
through the bug reports.
It's an extremely important job (in the long run, particularly), but
perhaps not quite as "sexy"-sounding as other roles, and probably
under-valued.

So, thank you to the bug-fixers...

:)

On Sat, May 16, 2020 at 2:54 AM Duncan Murdoch  wrote:
>
> On 15/05/2020 9:41 a.m., Martin Maechler wrote:
> [ deletions ]
> > 
> >
> >  Why does nobody anymore  help R development by working with
> >  "R-devel", or at least then the alpha, beta and the "RC"
> >  (Release Candidate) versions that we release daily for about one
> >  month before the final release?
> >
> >  Notably a highly staffed enterprise such as Rstudio (viz the bug
> >  report 17800 above), but also others could really help by
> >  starting to use the "next version" of R on a routine basis ...
> >
> >  I understand the whining, bugs that get released are embarrassing.  But
> when I read the NEWS, I can see that both the NEW FEATURES and BUG FIXES
> sections of x.y.0 releases tend to be much longer than the BUG FIXES
> sections in patch releases.  That seems to indicate that things are
> working reasonably well.
>
> For a really rough measure, just counting bullet points:
>
> R 4.0.0:  65 new features, 55 bug fixes
>
> R 3.6.3:  1 new feature, 7 bug fixes
>
> R 3.6.2:  2 new features, 21 bug fixes
>
> R 3.6.1:  0 new features, 16 bug fixes
>
> R 3.6.0:  72 new features, 62 bug fixes
>
> You can get these numbers programmatically:
>
> R4 <- news()
> table(R4$Category)
>
> R3 <- news(package = "R-3")
> table(R3$Version, R3$Category)
>
> Duncan Murdoch
>
> __
> 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: [R-pkg-devel] Package submission failed with two warnings

[Gábor Csárdi]

The reason is that CRAN does not have an R-devel binary for
data.table, and because of this install.packages() decides not to
install it. Here is a workaround:
https://github.com/r-hub/rhub/issues/367#issuecomment-621757715

Gabor

On Fri, May 15, 2020 at 10:50 PM Max Turgeon  wrote:
>
> Hi Farshad,
>
>
> The error you get when compiling your vignette gives us a hint:
>
> Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
> package or namespace load failed for 'ggpubr' in loadNamespace(j <- i[[1L]], 
> c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
>  there is no package called 'data.table'
>
> There is a long chain of dependencies here: if I write A -> B to say that 
> package A lists package B as an Import (and therefore package B is loaded 
> when package A is attached), we have
>
>
> ggpubr -> rstatix -> car -> rio -> data.table.
>
>
> I think the issue is that, since you list ggpubr in "Suggests", there's never 
> a check that all its dependencies (and their dependencies etc) are installed, 
> and therefore data.table was not installed before checking your package. (But 
> I'm not sure exactly why ggpubr is installed but not all the dependencies.)
>
>
> A solution would be to make your whole vignette fail "gracefully" when ggpubr 
> isn't attached properly. Which is good practice anyway.
>
>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
> 
> From: R-package-devel  on behalf of 
> FARSHAD TABASINEJAD 
> Sent: May 15, 2020 4:11:36 PM
> To: Duncan Murdoch; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Package submission failed with two warnings
>
> 
> Caution: This message was sent from outside the University of Manitoba.
> 
>
> Hi Duncan,
>
> I changed the version, recreated the package, and then tested it with the 
> rhub::check_for_cran(). The function failed to create a summary for all the 
> platform results together, however individual results are available in the 
> following links.
>
>
> https://builder.r-hub.io/status/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3
> https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3/
> https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-2ee682316e0f4bc7b09faf7a9e46b670/
> https://builder.r-hub.io/status/original/Rpvt_0.1.1.tar.gz-08fc2dbd591f4d80b2e0049a7c8db8b8
>
> you can also find the source code in the following link:
> https://github.com/susaenergy/Rpvt
>
> Thank you for the help!
>
> Farshad
>
>
> From: Duncan Murdoch
> Sent: Friday, May 15, 2020 9:28 AM
> To: FARSHAD TABASINEJAD; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Package submission failed with two warnings
>
> For your first warning, see the CRAN policy:  "Updates to
> previously-published packages must have an increased version. Increasing
> the version number at each submission reduces confusion so is preferred
> even when a previous submission was not accepted."
>
> For the second, it's hard to say what's happening.  Is your package
> online somewhere so we could try it on different machines?
>
> Duncan Murdoch
>
> On 15/05/2020 12:46 a.m., FARSHAD TABASINEJAD wrote:
> > Dear R-package-devel experts,
> >
> > This is the first time I’m writing to this platform about a package I 
> > recently submitted to CRAN (my first package).
> > While the package is already available on CRAN, I still must fix a few 
> > warnings and one error as reported on the CRAN package check results page:
> > https://cran.r-project.org/web/checks/check_results_Rpvt.html
> >
> > I recently resubmitted a modified version of the package to CRAN, however, 
> > it didn’t pass the automatic incoming checks.
> >
> > Windows:  
> > https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
> > Status: 1 WARNING
> >
> > Debian:  
> > https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
> > Status: 2 WARNINGs
> >
> >
> > 1) The first warning that appears on both Windows and Debian results is 
> > “Insufficient package version (submitted: 0.1.0, existing: 0.1.0)”.
> >
> > Since the package is conditionally available on CRAN, do I need to modify 
> > the package version to 0.1.1 to get rid of this warning?
> > Is there any way to fix this problem with the current version of the 
> > package(0.1.0)?
> >
> > 2) The second problem appears on the Debian test results:
> >
> >  * checking re-building of vignette outputs ... [8s/8s] WARNING
> >
> >  Error(s) in re-building vignettes:
> >  ...
> >  --- re-building ‘Rpvt.Rmd’ using rmarkdown
> >
> >  pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
> > [1,20] but attempted to decode with [1,17,5,4].
> >
> >  CallStack (from HasCallStack):
> 

Re: [R-pkg-devel] Package submission failed with two warnings

[Max Turgeon]

Hi Farshad,


The error you get when compiling your vignette gives us a hint:

Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
package or namespace load failed for 'ggpubr' in loadNamespace(j <- i[[1L]], 
c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
 there is no package called 'data.table'

There is a long chain of dependencies here: if I write A -> B to say that 
package A lists package B as an Import (and therefore package B is loaded when 
package A is attached), we have


ggpubr -> rstatix -> car -> rio -> data.table.


I think the issue is that, since you list ggpubr in "Suggests", there's never a 
check that all its dependencies (and their dependencies etc) are installed, and 
therefore data.table was not installed before checking your package. (But I'm 
not sure exactly why ggpubr is installed but not all the dependencies.)


A solution would be to make your whole vignette fail "gracefully" when ggpubr 
isn't attached properly. Which is good practice anyway.


Max Turgeon
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca



From: R-package-devel  on behalf of 
FARSHAD TABASINEJAD 
Sent: May 15, 2020 4:11:36 PM
To: Duncan Murdoch; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Package submission failed with two warnings


Caution: This message was sent from outside the University of Manitoba.


Hi Duncan,

I changed the version, recreated the package, and then tested it with the 
rhub::check_for_cran(). The function failed to create a summary for all the 
platform results together, however individual results are available in the 
following links.


https://builder.r-hub.io/status/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3
https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3/
https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-2ee682316e0f4bc7b09faf7a9e46b670/
https://builder.r-hub.io/status/original/Rpvt_0.1.1.tar.gz-08fc2dbd591f4d80b2e0049a7c8db8b8

you can also find the source code in the following link:
https://github.com/susaenergy/Rpvt

Thank you for the help!

Farshad


From: Duncan Murdoch
Sent: Friday, May 15, 2020 9:28 AM
To: FARSHAD TABASINEJAD; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Package submission failed with two warnings

For your first warning, see the CRAN policy:  "Updates to
previously-published packages must have an increased version. Increasing
the version number at each submission reduces confusion so is preferred
even when a previous submission was not accepted."

For the second, it's hard to say what's happening.  Is your package
online somewhere so we could try it on different machines?

Duncan Murdoch

On 15/05/2020 12:46 a.m., FARSHAD TABASINEJAD wrote:
> Dear R-package-devel experts,
>
> This is the first time I�m writing to this platform about a package I 
> recently submitted to CRAN (my first package).
> While the package is already available on CRAN, I still must fix a few 
> warnings and one error as reported on the CRAN package check results page:
> https://cran.r-project.org/web/checks/check_results_Rpvt.html
>
> I recently resubmitted a modified version of the package to CRAN, however, it 
> didn�t pass the automatic incoming checks.
>
> Windows:  
> https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
> Status: 1 WARNING
>
> Debian:  
> https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
> Status: 2 WARNINGs
>
>
> 1) The first warning that appears on both Windows and Debian results is 
> �Insufficient package version (submitted: 0.1.0, existing: 0.1.0)�.
>
> Since the package is conditionally available on CRAN, do I need to modify the 
> package version to 0.1.1 to get rid of this warning?
> Is there any way to fix this problem with the current version of the 
> package(0.1.0)?
>
> 2) The second problem appears on the Debian test results:
>
>  * checking re-building of vignette outputs ... [8s/8s] WARNING
>
>  Error(s) in re-building vignettes:
>  ...
>  --- re-building �Rpvt.Rmd� using rmarkdown
>
>  pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
> [1,20] but attempted to decode with [1,17,5,4].
>
>  CallStack (from HasCallStack):
>  error, called at ./Text/Pandoc/JSON.hs:111:48 in pandoc-types-1.17.5.4 
> 5tHZ3B61A58JaKOMxwGQR4:Text.Pandoc.JSON
>
>  Error running filter /usr/bin/pandoc-citeproc:
>
>  Filter returned error status 1
>  Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
>  pandoc document conversion failed with error 83 ---
>  failed re-building �Rpvt.Rmd�
>
>  SUMMARY: processing the following file failed:
>  �Rpvt.Rmd�
>
>  Error: Vignette re-building failed.
>  

Re: [R-pkg-devel] Package submission failed with two warnings

[FARSHAD TABASINEJAD]

Hi Duncan,

I changed the version, recreated the package, and then tested it with the 
rhub::check_for_cran(). The function failed to create a summary for all the 
platform results together, however individual results are available in the 
following links.


https://builder.r-hub.io/status/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3
https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3/
https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-2ee682316e0f4bc7b09faf7a9e46b670/
https://builder.r-hub.io/status/original/Rpvt_0.1.1.tar.gz-08fc2dbd591f4d80b2e0049a7c8db8b8

you can also find the source code in the following link:
https://github.com/susaenergy/Rpvt

Thank you for the help!

Farshad


From: Duncan Murdoch
Sent: Friday, May 15, 2020 9:28 AM
To: FARSHAD TABASINEJAD; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Package submission failed with two warnings

For your first warning, see the CRAN policy:  "Updates to 
previously-published packages must have an increased version. Increasing 
the version number at each submission reduces confusion so is preferred 
even when a previous submission was not accepted."

For the second, it's hard to say what's happening.  Is your package 
online somewhere so we could try it on different machines?

Duncan Murdoch

On 15/05/2020 12:46 a.m., FARSHAD TABASINEJAD wrote:
> Dear R-package-devel experts,
> 
> This is the first time I’m writing to this platform about a package I 
> recently submitted to CRAN (my first package).
> While the package is already available on CRAN, I still must fix a few 
> warnings and one error as reported on the CRAN package check results page:
> https://cran.r-project.org/web/checks/check_results_Rpvt.html
> 
> I recently resubmitted a modified version of the package to CRAN, however, it 
> didn’t pass the automatic incoming checks.
> 
> Windows:  
> https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
> Status: 1 WARNING
> 
> Debian:  
> https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
> Status: 2 WARNINGs
> 
> 
> 1) The first warning that appears on both Windows and Debian results is 
> “Insufficient package version (submitted: 0.1.0, existing: 0.1.0)”.
> 
> Since the package is conditionally available on CRAN, do I need to modify the 
> package version to 0.1.1 to get rid of this warning?
> Is there any way to fix this problem with the current version of the 
> package(0.1.0)?
> 
> 2) The second problem appears on the Debian test results:
>  
>  * checking re-building of vignette outputs ... [8s/8s] WARNING
>  
>  Error(s) in re-building vignettes:
>  ...
>  --- re-building ‘Rpvt.Rmd’ using rmarkdown
>  
>  pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
> [1,20] but attempted to decode with [1,17,5,4].
>  
>  CallStack (from HasCallStack):
>  error, called at ./Text/Pandoc/JSON.hs:111:48 in pandoc-types-1.17.5.4 
> 5tHZ3B61A58JaKOMxwGQR4:Text.Pandoc.JSON
>  
>  Error running filter /usr/bin/pandoc-citeproc:
>  
>  Filter returned error status 1
>  Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
>  pandoc document conversion failed with error 83 ---
>  failed re-building ‘Rpvt.Rmd’
>  
>  SUMMARY: processing the following file failed:
>  ‘Rpvt.Rmd’
>  
>  Error: Vignette re-building failed.
>  Execution halted
> 
> I’ve created this package on a Windows operating system with no problem in 
> creating the ‘Rpvt.Rmd’ file as is the case with the CRAN tests on 
> x86_64-w64-mingw32 (64-bit).
> Why does it fail to create the “Rpvt.Rmd” file on x86_64-pc-linux-gnu 
> (Debian)? Is this something related to the citation style of the library.bib 
> file that I’ve used in my vignettes folder? It is the “apa-6th-edition.csl” 
> file downloaded from 
> https://raw.githubusercontent.com/citation-style-language/styles/master/apa-6th-edition.csl
> 
> Thank you in advance!
> 
> Regards,
> Farshad
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 



[[alternative HTML version deleted]]

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

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

[Hervé Pagès]

There is still the situation where **both** 'sep' and 'collapse' are 
specified:


  > paste(integer(0), "nth", sep="", collapse=",")
  [1] "nth"

In that case 'recycle0' should **not** be ignored i.e.

  paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)

should return the empty string (and not character(0) like it does at the 
moment).


In other words, 'recycle0' should only control the first operation (the 
operation controlled by 'sep'). Which makes plenty of sense: the 1st 
operation is binary (or n-ary) while the collapse operation is unary. 
There is no concept of recycling in the context of unary operations.


H.

On 5/15/20 11:25, Gabriel Becker wrote:

Hi all,

This makes sense to me, but I would think that recycle0 and collapse 
should actually be incompatible and paste should throw an error if 
recycle0 were TRUE and collapse were declared in the same call. I don't 
think the value of recycle0 should be silently ignored if it is actively 
specified.


~G

On Fri, May 15, 2020 at 11:05 AM Hervé Pagès > wrote:


Totally agree with that.

H.

On 5/15/20 10:34, William Dunlap via R-devel wrote:
 > I agree: paste(collapse="something", ...) should always return a
single
 > character string, regardless of the value of recycle0.  This would be
 > similar to when there are no non-NULL arguments to paste;
collapse="."
 > gives a single empty string and collapse=NULL gives a zero long
character
 > vector.
 >> paste()
 > character(0)
 >> paste(collapse=", ")
 > [1] ""
 >
 > Bill Dunlap
 > TIBCO Software
 > wdunlap tibco.com


 >
 >
 > On Thu, Apr 30, 2020 at 9:56 PM suharto_anggono--- via R-devel <
 > r-devel@r-project.org > wrote:
 >
 >> Without 'collapse', 'paste' pastes (concatenates) its arguments
 >> elementwise (separated by 'sep', " " by default). New in R devel
and R
 >> patched, specifying recycle0 = FALSE makes mixing zero-length and
 >> nonzero-length arguments results in length zero. The result of
paste(n,
 >> "th", sep = "", recycle0 = FALSE) always have the same length as
'n'.
 >> Previously, the result is still as long as the longest argument,
with the
 >> zero-length argument like "". If all og the arguments have
length zero,
 >> 'recycle0' doesn't matter.
 >>
 >> As far as I understand, 'paste' with 'collapse' as a character
string is
 >> supposed to put together elements of a vector into a single
character
 >> string. I think 'recycle0' shouldn't change it.
 >>
 >> In current R devel and R patched, paste(character(0), collapse = "",
 >> recycle0 = FALSE) is character(0). I think it should be "", like
 >> paste(character(0), collapse="").
 >>
 >> paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 =
FALSE)
 >> is
 >> "4th, 5th".
 >> paste(c("4"     ), "th", sep = "", collapse = ", ", recycle0 =
FALSE)
 >> is
 >> "4th".
 >> I think
 >> paste(c(        ), "th", sep = "", collapse = ", ", recycle0 =
FALSE)
 >> should be
 >> "",
 >> not character(0).
 >>
 >> __
 >> R-devel@r-project.org  mailing list
 >>

https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
 >>
 >
 >       [[alternative HTML version deleted]]
 >
 > __
 > R-devel@r-project.org  mailing list
 >

https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
 >

-- 
Hervé Pagès


Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org 
Phone:  (206) 667-5791
Fax:    (206) 667-1319

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

Re: [Bioc-devel] Vignette Building Latex Errors on Windows Release Branch

[Sergio Picart Armada]

Dear bioc devel,

We are having the same problem with our package FELLA.
Any help is appreciated!

Best,
Sergi

Missatge de petr smirnov  del dia dv., 15 de maig
2020 a les 19:42:

> I am having trouble reproducing some vignette build errors for our
> PharmacoGx package on Windows (tokay2).
>
> The error is a Latex error:
> LaTeX Error: Environment cslreferences undefined.
>
> It seems likely to be due to a missing dependency for the style file
> we are using, however, I do not understand why it works on all other
> build machines. tokay1 does not have the same error, and is building
> the same vignette. Likewise, none of the other OS machines are missing
> this dependency.
>
> I also tried to reproduce in a newly reinstalled Windows environment.
> After installing R 4.0, Rtools, all the package dependencies, and:
> knitr, knitcitations, rmarkdown, pander, and tinytex, the package
> builds on the machine. As far as I can tell, all these packages are
> also installed on tokay2.
>
> Does tokay2 use a different Latex distribution from what is installed
> by tinytex ?
>
> --
> Petr Smirnov
>
> psmirnov2...@gmail.com
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

[Gabriel Becker]

Hi all,

This makes sense to me, but I would think that recycle0 and collapse should
actually be incompatible and paste should throw an error if recycle0 were
TRUE and collapse were declared in the same call. I don't think the value
of recycle0 should be silently ignored if it is actively specified.

~G

On Fri, May 15, 2020 at 11:05 AM Hervé Pagès  wrote:

> Totally agree with that.
>
> H.
>
> On 5/15/20 10:34, William Dunlap via R-devel wrote:
> > I agree: paste(collapse="something", ...) should always return a single
> > character string, regardless of the value of recycle0.  This would be
> > similar to when there are no non-NULL arguments to paste; collapse="."
> > gives a single empty string and collapse=NULL gives a zero long character
> > vector.
> >> paste()
> > character(0)
> >> paste(collapse=", ")
> > [1] ""
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> >
> > On Thu, Apr 30, 2020 at 9:56 PM suharto_anggono--- via R-devel <
> > r-devel@r-project.org> wrote:
> >
> >> Without 'collapse', 'paste' pastes (concatenates) its arguments
> >> elementwise (separated by 'sep', " " by default). New in R devel and R
> >> patched, specifying recycle0 = FALSE makes mixing zero-length and
> >> nonzero-length arguments results in length zero. The result of paste(n,
> >> "th", sep = "", recycle0 = FALSE) always have the same length as 'n'.
> >> Previously, the result is still as long as the longest argument, with
> the
> >> zero-length argument like "". If all og the arguments have length zero,
> >> 'recycle0' doesn't matter.
> >>
> >> As far as I understand, 'paste' with 'collapse' as a character string is
> >> supposed to put together elements of a vector into a single character
> >> string. I think 'recycle0' shouldn't change it.
> >>
> >> In current R devel and R patched, paste(character(0), collapse = "",
> >> recycle0 = FALSE) is character(0). I think it should be "", like
> >> paste(character(0), collapse="").
> >>
> >> paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> >> is
> >> "4th, 5th".
> >> paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> >> is
> >> "4th".
> >> I think
> >> paste(c(), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> >> should be
> >> "",
> >> not character(0).
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
> >
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>
> __
> 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] paste(character(0), collapse="", recycle0=FALSE) should be ""

[Hervé Pagès]

Totally agree with that.

H.

On 5/15/20 10:34, William Dunlap via R-devel wrote:

I agree: paste(collapse="something", ...) should always return a single
character string, regardless of the value of recycle0.  This would be
similar to when there are no non-NULL arguments to paste; collapse="."
gives a single empty string and collapse=NULL gives a zero long character
vector.

paste()

character(0)

paste(collapse=", ")

[1] ""

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Apr 30, 2020 at 9:56 PM suharto_anggono--- via R-devel <
r-devel@r-project.org> wrote:


Without 'collapse', 'paste' pastes (concatenates) its arguments
elementwise (separated by 'sep', " " by default). New in R devel and R
patched, specifying recycle0 = FALSE makes mixing zero-length and
nonzero-length arguments results in length zero. The result of paste(n,
"th", sep = "", recycle0 = FALSE) always have the same length as 'n'.
Previously, the result is still as long as the longest argument, with the
zero-length argument like "". If all og the arguments have length zero,
'recycle0' doesn't matter.

As far as I understand, 'paste' with 'collapse' as a character string is
supposed to put together elements of a vector into a single character
string. I think 'recycle0' shouldn't change it.

In current R devel and R patched, paste(character(0), collapse = "",
recycle0 = FALSE) is character(0). I think it should be "", like
paste(character(0), collapse="").

paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE)
is
"4th, 5th".
paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
is
"4th".
I think
paste(c(), "th", sep = "", collapse = ", ", recycle0 = FALSE)
should be
"",
not character(0).

__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Bioc-devel] Vignette Building Latex Errors on Windows Release Branch

[petr smirnov]

I am having trouble reproducing some vignette build errors for our
PharmacoGx package on Windows (tokay2).

The error is a Latex error:
LaTeX Error: Environment cslreferences undefined.

It seems likely to be due to a missing dependency for the style file
we are using, however, I do not understand why it works on all other
build machines. tokay1 does not have the same error, and is building
the same vignette. Likewise, none of the other OS machines are missing
this dependency.

I also tried to reproduce in a newly reinstalled Windows environment.
After installing R 4.0, Rtools, all the package dependencies, and:
knitr, knitcitations, rmarkdown, pander, and tinytex, the package
builds on the machine. As far as I can tell, all these packages are
also installed on tokay2.

Does tokay2 use a different Latex distribution from what is installed
by tinytex ?

-- 
Petr Smirnov

psmirnov2...@gmail.com

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

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

[William Dunlap via R-devel]

I agree: paste(collapse="something", ...) should always return a single
character string, regardless of the value of recycle0.  This would be
similar to when there are no non-NULL arguments to paste; collapse="."
gives a single empty string and collapse=NULL gives a zero long character
vector.
> paste()
character(0)
> paste(collapse=", ")
[1] ""

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Apr 30, 2020 at 9:56 PM suharto_anggono--- via R-devel <
r-devel@r-project.org> wrote:

> Without 'collapse', 'paste' pastes (concatenates) its arguments
> elementwise (separated by 'sep', " " by default). New in R devel and R
> patched, specifying recycle0 = FALSE makes mixing zero-length and
> nonzero-length arguments results in length zero. The result of paste(n,
> "th", sep = "", recycle0 = FALSE) always have the same length as 'n'.
> Previously, the result is still as long as the longest argument, with the
> zero-length argument like "". If all og the arguments have length zero,
> 'recycle0' doesn't matter.
>
> As far as I understand, 'paste' with 'collapse' as a character string is
> supposed to put together elements of a vector into a single character
> string. I think 'recycle0' shouldn't change it.
>
> In current R devel and R patched, paste(character(0), collapse = "",
> recycle0 = FALSE) is character(0). I think it should be "", like
> paste(character(0), collapse="").
>
> paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> is
> "4th, 5th".
> paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> is
> "4th".
> I think
> paste(c(), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> should be
> "",
> not character(0).
>
> __
> 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] edit() doubles backslashes when keep.source=TRUE

[peter dalgaard]

To discuss this further, we should probably move over to R-sig-mac and change 
the subject header.

-pd

> On 15 May 2020, at 19:26 , peter dalgaard  wrote:
> 
> Actually, it's not that hard to set up for a source compile for MacOS.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[peter dalgaard]

Actually, it's not that hard to set up for a source compile for MacOS. The hard 
part is to do it precisely like the CRAN binaries so that you can run binary 
packages off CRAN, but in other setups you can just build packages from source. 

A stone in the shoe has been that the documentation on mac.r-project.org was 
littered with out-of-date information, but it seems that Simon has now cleaned 
this up considerably. It should now be possible simply to follow instructions 
on http://mac.r-project.org/tools/. I'm sure Simon will be receptive to 
information if something doesn't quite work.

-pd

> On 15 May 2020, at 18:48 , brodie gaslam via R-devel  
> wrote:
> 
>> 
>> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel 
>>  wrote:
>> On 15 May 2020 at 15:41, Martin Maechler wrote:
>> | 
>> |
>> |Why does nobody anymore  help R development by working with
>> |"R-devel", or at least then the alpha, beta and the "RC"
>> |(Release Candidate) versions that we release daily for about one
>> |month before the final release?
>> |
>> |Notably a highly staffed enterprise such as Rstudio (viz the bug
>> |report 17800 above), but also others could really help by
>> |starting to use the "next version" of R on a routine basis ...
>> |
>> | 
>> 
>> Seconded. Without testing we can never know. R Core does their part.
>> 
>> I provided weekly Debian binaries. One each for the two alphas releases, for
>> the beta release, for the release candidate.  It is easy to use these, for
>> example in a Docker container.
>> 
>> It is also easy to use this on a normal machine as they are standard (Debian)
>> packages: install, try some tests, uninstall, revert to previous version by
>> installing that.
>> 
>> Dirk
> 
> This is a very reasonably request, and all useRs who benefit from the
> tireless work of R-core should consider doing it.  I have considered
> it, but compiling R from sources on OS X has been my stumbling block.
> At least last time I tried I got stuck at the  Fortran step. It doesn't
> help I have very limited experience compiling  software of the complexity 
> of R.  Really, I've only done it within the warm welcoming confines of the
> vagrant image Tomas Kalibera set up for `rchk`.
> 
> I also use r-devel on docker, but that isn't very practical for
> day-to-day usage, which is what I think we need.
> 
> What would it take to generate pre-release binaries for OS X (and Windows)?  I
> imagine if such were available the volume of testers would increase
> dramatically (at least, I haven't seen them if they exist).  
> Maybe something the R Consortium would consider funding?
> 
> Best,
> 
> B.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Avraham Adler]

I build windows binaries from source. As of now, the only choice is R-revel
unless I want to monkey around more with Jeroens’s PKGBUILD script (which
is On my to-do list).

It’s pretty straightforward, although I’m seeing a lot of issues with
packages which had explicit calls to LOCALSOFT in configure.win as that
doesn’t exist anymore.

The binaries have passed make check, though. Would it help if I built some
and forwarded it somewhere?

Avi

On Fri, May 15, 2020 at 12:48 PM brodie gaslam via R-devel <
r-devel@r-project.org> wrote:

>
> > On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel <
> e...@debian.org> wrote:
> > On 15 May 2020 at 15:41, Martin Maechler wrote:
> > | 
> > |
> > |Why does nobody anymore  help R development by working with
> > |"R-devel", or at least then the alpha, beta and the "RC"
> > |(Release Candidate) versions that we release daily for about one
> > |month before the final release?
> > |
> > |Notably a highly staffed enterprise such as Rstudio (viz the bug
> > |report 17800 above), but also others could really help by
> > |starting to use the "next version" of R on a routine basis ...
> > |
> > | 
> >
> > Seconded. Without testing we can never know. R Core does their part.
> >
> > I provided weekly Debian binaries. One each for the two alphas releases,
> for
> > the beta release, for the release candidate.  It is easy to use these,
> for
> > example in a Docker container.
> >
> > It is also easy to use this on a normal machine as they are standard
> (Debian)
> > packages: install, try some tests, uninstall, revert to previous version
> by
> > installing that.
> >
> > Dirk
>
> This is a very reasonably request, and all useRs who benefit from the
> tireless work of R-core should consider doing it.  I have considered
> it, but compiling R from sources on OS X has been my stumbling block.
> At least last time I tried I got stuck at the  Fortran step. It doesn't
>  help I have very limited experience compiling  software of the complexity
> of R.  Really, I've only done it within the warm welcoming confines of the
>  vagrant image Tomas Kalibera set up for `rchk`.
>
> I also use r-devel on docker, but that isn't very practical for
> day-to-day usage, which is what I think we need.
>
> What would it take to generate pre-release binaries for OS X (and
> Windows)?  I
> imagine if such were available the volume of testers would increase
> dramatically (at least, I haven't seen them if they exist).
> Maybe something the R Consortium would consider funding?
>
> Best,
>
> B.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Bemis, Kylie]

Nightly binary builds of R-devel for macOS are available: 
http://mac.r-project.org

~~~
Kylie Ariel Bemis (she/her)
Khoury College of Computer Sciences
Northeastern University
kuwisdelu.github.io










On May 15, 2020, at 12:48 PM, brodie gaslam via R-devel 
mailto:r-devel@r-project.org>> wrote:


On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel 
mailto:e...@debian.org>> wrote:
On 15 May 2020 at 15:41, Martin Maechler wrote:
| 
|
|Why does nobody anymore  help R development by working with
|"R-devel", or at least then the alpha, beta and the "RC"
|(Release Candidate) versions that we release daily for about one
|month before the final release?
|
|Notably a highly staffed enterprise such as Rstudio (viz the bug
|report 17800 above), but also others could really help by
|starting to use the "next version" of R on a routine basis ...
|
| 

Seconded. Without testing we can never know. R Core does their part.

I provided weekly Debian binaries. One each for the two alphas releases, for
the beta release, for the release candidate.  It is easy to use these, for
example in a Docker container.

It is also easy to use this on a normal machine as they are standard (Debian)
packages: install, try some tests, uninstall, revert to previous version by
installing that.

Dirk

This is a very reasonably request, and all useRs who benefit from the
tireless work of R-core should consider doing it.  I have considered
it, but compiling R from sources on OS X has been my stumbling block.
At least last time I tried I got stuck at the  Fortran step. It doesn't
help I have very limited experience compiling  software of the complexity
of R.  Really, I've only done it within the warm welcoming confines of the
vagrant image Tomas Kalibera set up for `rchk`.

I also use r-devel on docker, but that isn't very practical for
day-to-day usage, which is what I think we need.

What would it take to generate pre-release binaries for OS X (and Windows)?  I
imagine if such were available the volume of testers would increase
dramatically (at least, I haven't seen them if they exist).
Maybe something the R Consortium would consider funding?

Best,

B.

__
R-devel@r-project.org mailing list
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-develdata=02%7C01%7Ck.bemis%40northeastern.edu%7C66883f8d39094f87847608d7f8efd23e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637251581223782724sdata=cVYbvv%2B2fqwKpMUCM6iBGu4wLOLQvQUwv4SOapZf5mM%3Dreserved=0


[[alternative HTML version deleted]]

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[brodie gaslam via R-devel]

> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel  
> wrote:
> On 15 May 2020 at 15:41, Martin Maechler wrote:
> | 
> |
> |    Why does nobody anymore  help R development by working with
> |    "R-devel", or at least then the alpha, beta and the "RC"
> |    (Release Candidate) versions that we release daily for about one
> |    month before the final release?
> |
> |    Notably a highly staffed enterprise such as Rstudio (viz the bug
> |    report 17800 above), but also others could really help by
> |    starting to use the "next version" of R on a routine basis ...
> |
> | 
>
> Seconded. Without testing we can never know. R Core does their part.
>
> I provided weekly Debian binaries. One each for the two alphas releases, for
> the beta release, for the release candidate.  It is easy to use these, for
> example in a Docker container.
>
> It is also easy to use this on a normal machine as they are standard (Debian)
> packages: install, try some tests, uninstall, revert to previous version by
> installing that.
>
> Dirk

This is a very reasonably request, and all useRs who benefit from the
tireless work of R-core should consider doing it.  I have considered
it, but compiling R from sources on OS X has been my stumbling block.
At least last time I tried I got stuck at the  Fortran step. It doesn't
 help I have very limited experience compiling  software of the complexity 
of R.  Really, I've only done it within the warm welcoming confines of the
 vagrant image Tomas Kalibera set up for `rchk`.

I also use r-devel on docker, but that isn't very practical for
day-to-day usage, which is what I think we need.

What would it take to generate pre-release binaries for OS X (and Windows)?  I
imagine if such were available the volume of testers would increase
dramatically (at least, I haven't seen them if they exist).  
Maybe something the R Consortium would consider funding?

Best,

B.

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

[Rd] ftable <-> data.frame etc {was "justify hard coded in format.ftable"}

[Martin Maechler]

> Gabor Grothendieck 
> on Thu, 14 May 2020 06:56:06 -0400 writes:

> If you are looking at ftable could you also consider adding
> a way to convert an ftable into a usable data.frame such as
> the ftable2df function defined here:

> https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126

> and there is an example of using it here:

> https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756

> Being able to move back and forth between various base class representations
> seems like something that would be natural to provide.

Sure!

But there is already an  as.data.frame() method for "ftable",
{and I would not want theif(! .. ftable)  ftable(x)  part anyway.

What I think many useRs / programmeRs  very often forget about
is more-than-2-dimensional arrays {which *are* at the beginning
of that SO question} and that these are often by far the most
efficient data structure (rather than the corresponding data frames).  

and even less people forget that a "table" in base R is just a
special case of a 1-D, 2-D, 3-D,  array.
(Semantically a special case: "array" with non-negative integer content 

I'd claim that everything you here ("move back and forth between
...") is already there in the "ftable" implementation in stats,
notably in the source file  src/library/stats/R/ftable.R
 -> https://svn.r-project.org/R/trunk/src/library/stats/R/ftable.R

The problem may be in

1) too sparse documentation about the close relations
   "ftable" <-> "array" <-> "table" <-> "data.frame" 

2) people not thinking often enough about more-than-2D-arrays and the
  special corresponding class "table" in R.

To start with one:

> str(UCBAdmissions)
 'table' num [1:2, 1:2, 1:6] 512 313 89 19 353 207 17 8 120 205 ...
 - attr(*, "dimnames")=List of 3
  ..$ Admit : chr [1:2] "Admitted" "Rejected"
  ..$ Gender: chr [1:2] "Male" "Female"
  ..$ Dept  : chr [1:6] "A" "B" "C" "D" ...
>

and look at the *examples* in the help files and the S3 methods

methods(class = "ftable")
[1] as.data.frame as.matrix as.table  formathead  print 
   
[7] tail 
see '?methods' for accessing help and source code
> methods(class = "table")
 [1] [ aperm as.data.frame Axis  coerce
initialize   
 [7] lines plot  pointsprint show  
slotsFromS3  
[13] summary   tail 
see '?methods' for accessing help and source code
> 

... need to close now, there's more to be said ...



> On Thu, May 14, 2020 at 5:32 AM Martin Maechler
>  wrote:
>> 
>> > SOEIRO Thomas
>> > on Wed, 13 May 2020 20:27:15 + writes:
>> 
>> > Dear all,
>> > I haven't received any feedback so far on my proposal to make 
"justify" argument available in stats:::format.ftable
>> 
>> > Is this list the appropriate place for this kind of proposal?
>> 
>> Yes, it is.. Actually such a post is even a "role model" post
>> for R-devel.
>> 
>> > I hope this follow-up to my message won't be taken as rude. Of course 
it's not meant to be, but I'm not used to the R mailing lists...
>> 
>> well, there could be said much, and many stories told here ... ;-)
>> 
>> > Thank you in advance for your comments,
>> 
>> > Best,
>> > Thomas
>> 
>> The main reasons for "no reaction" (for such nice post) probably
>> are combination of the following
>> 
>> - we are busy
>> - if we have time, we think other things are more exciting
>> - we have not used ftable much/at all and are not interested.
>> 
>> Even though the first 2 apply to me, I'll have a 2nd look into
>> your post now, and may end up well agreeing with your proposal.
>> 
>> Martin Maechler
>> ETH Zurich  and  R Core team
>> 
>> 
>> 
>> 
>> >> Dear all,
>> >>
>> >> justify argument is hard coded in format.ftable:
>> >>
>> >> cbind(apply(LABS, 2L, format, justify = "left"),
>> >> apply(DATA, 2L, format, justify = "right"))
>> >>
>> >> It would be useful to have the possibility to modify the argument 
between c("left", "right", "centre", "none") as in format.default.
>> >>
>> >> The lines could be changed to:
>> >>
>> >> if(length(justify) != 2)
>> >> stop("justify must be length 2")
>> >> cbind(apply(LABS, 2L, format, justify = justify[1]),
>> >> apply(DATA, 2L, format, justify = justify[2]))
>> >>
>> >> The argument justify could defaults to c("left", "right") for 
backward compatibility.
>> >>
>> >> It could then allow:
>> >> ftab <- ftable(wool + tension ~ breaks, warpbreaks)
>> >> format.ftable(ftab, justify = c("none", "none"))
>> >>
>> >> Best regards,
>> >>
>> >> Thomas


> -- 
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Dirk Eddelbuettel]

On 15 May 2020 at 15:41, Martin Maechler wrote:
| 
| 
| Why does nobody anymore  help R development by working with
| "R-devel", or at least then the alpha, beta and the "RC"
| (Release Candidate) versions that we release daily for about one
| month before the final release?
| 
| Notably a highly staffed enterprise such as Rstudio (viz the bug
| report 17800 above), but also others could really help by
| starting to use the "next version" of R on a routine basis ...
| 
| 

Seconded. Without testing we can never know. R Core does their part.

I provided weekly Debian binaries. One each for the two alphas releases, for
the beta release, for the release candidate.  It is easy to use these, for
example in a Docker container.

It is also easy to use this on a normal machine as they are standard (Debian)
packages: install, try some tests, uninstall, revert to previous version by
installing that.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Daily News about R-devel/NEWS is not updating

[Jennifer Lyon]

Thank you!

Jen

On Fri, May 15, 2020 at 9:02 AM Duncan Murdoch 
wrote:

> On 15/05/2020 10:39 a.m., Jennifer Lyon wrote:
> > Hi:
> >
> > The "Daily News about R-devel/NEWS" webpage at
> > http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be
> > updating. As of today, the latest entry is Tue, 14 Apr 2020.
> >
> > Thanks.
> >
>
> Thanks for noticing that.  It's now fixed.  (The issue was that R-devel
> on the news machine didn't have rJava installed; the highlighting of
> differences is done by some old Java code.)
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Package submission failed with two warnings

[Duncan Murdoch]

For your first warning, see the CRAN policy:  "Updates to 
previously-published packages must have an increased version. Increasing 
the version number at each submission reduces confusion so is preferred 
even when a previous submission was not accepted."


For the second, it's hard to say what's happening.  Is your package 
online somewhere so we could try it on different machines?


Duncan Murdoch

On 15/05/2020 12:46 a.m., FARSHAD TABASINEJAD wrote:

Dear R-package-devel experts,

This is the first time I’m writing to this platform about a package I recently 
submitted to CRAN (my first package).
While the package is already available on CRAN, I still must fix a few warnings 
and one error as reported on the CRAN package check results page:
https://cran.r-project.org/web/checks/check_results_Rpvt.html

I recently resubmitted a modified version of the package to CRAN, however, it 
didn’t pass the automatic incoming checks.

Windows:  
https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
Status: 1 WARNING

Debian:  
https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
Status: 2 WARNINGs


1) The first warning that appears on both Windows and Debian results is 
“Insufficient package version (submitted: 0.1.0, existing: 0.1.0)”.

Since the package is conditionally available on CRAN, do I need to modify the 
package version to 0.1.1 to get rid of this warning?
Is there any way to fix this problem with the current version of the 
package(0.1.0)?

2) The second problem appears on the Debian test results:
 
 * checking re-building of vignette outputs ... [8s/8s] WARNING
 
 Error(s) in re-building vignettes:

 ...
 --- re-building ‘Rpvt.Rmd’ using rmarkdown
 
 pandoc-citeproc: Error in $: Incompatible API versions: encoded with [1,20] but attempted to decode with [1,17,5,4].
 
 CallStack (from HasCallStack):

 error, called at ./Text/Pandoc/JSON.hs:111:48 in pandoc-types-1.17.5.4 
5tHZ3B61A58JaKOMxwGQR4:Text.Pandoc.JSON
 
 Error running filter /usr/bin/pandoc-citeproc:
 
 Filter returned error status 1

 Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
 pandoc document conversion failed with error 83 ---
 failed re-building ‘Rpvt.Rmd’
 
 SUMMARY: processing the following file failed:

 ‘Rpvt.Rmd’
 
 Error: Vignette re-building failed.

 Execution halted

I’ve created this package on a Windows operating system with no problem in 
creating the ‘Rpvt.Rmd’ file as is the case with the CRAN tests on 
x86_64-w64-mingw32 (64-bit).
Why does it fail to create the “Rpvt.Rmd” file on x86_64-pc-linux-gnu (Debian)? 
Is this something related to the citation style of the library.bib file that 
I’ve used in my vignettes folder? It is the “apa-6th-edition.csl” file 
downloaded from 
https://raw.githubusercontent.com/citation-style-language/styles/master/apa-6th-edition.csl

Thank you in advance!

Regards,
Farshad


[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] Package submission failed with two warnings

[Mauricio Zambrano-Bigiarini]

On Fri, 15 May 2020 at 10:34, FARSHAD TABASINEJAD
 wrote:
>
> Dear R-package-devel experts,
>
> This is the first time I’m writing to this platform about a package I 
> recently submitted to CRAN (my first package).
> While the package is already available on CRAN, I still must fix a few 
> warnings and one error as reported on the CRAN package check results page:
> https://cran.r-project.org/web/checks/check_results_Rpvt.html
>
> I recently resubmitted a modified version of the package to CRAN, however, it 
> didn’t pass the automatic incoming checks.
>
> Windows:  
> https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
> Status: 1 WARNING
>
> Debian:  
> https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
> Status: 2 WARNINGs
>
>
> 1) The first warning that appears on both Windows and Debian results is 
> “Insufficient package version (submitted: 0.1.0, existing: 0.1.0)”.
>
> Since the package is conditionally available on CRAN, do I need to modify the 
> package version to 0.1.1 to get rid of this warning?
> Is there any way to fix this problem with the current version of the 
> package(0.1.0)?

>From https://cran.r-project.org/web/packages/policies.html:

"Updates to previously-published packages must have an increased
version. Increasing the version number at each submission reduces
confusion so is preferred even when a previous submission was not
accepted."


>
> 2) The second problem appears on the Debian test results:
>
> * checking re-building of vignette outputs ... [8s/8s] WARNING
>
> Error(s) in re-building vignettes:
> ...
> --- re-building ‘Rpvt.Rmd’ using rmarkdown
>
> pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
> [1,20] but attempted to decode with [1,17,5,4].
>
> CallStack (from HasCallStack):
> error, called at ./Text/Pandoc/JSON.hs:111:48 in pandoc-types-1.17.5.4 
> 5tHZ3B61A58JaKOMxwGQR4:Text.Pandoc.JSON
>
> Error running filter /usr/bin/pandoc-citeproc:
>
> Filter returned error status 1
> Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
> pandoc document conversion failed with error 83 ---
> failed re-building ‘Rpvt.Rmd’
>
> SUMMARY: processing the following file failed:
> ‘Rpvt.Rmd’
>
> Error: Vignette re-building failed.
> Execution halted
>
> I’ve created this package on a Windows operating system with no problem in 
> creating the ‘Rpvt.Rmd’ file as is the case with the CRAN tests on 
> x86_64-w64-mingw32 (64-bit).
> Why does it fail to create the “Rpvt.Rmd” file on x86_64-pc-linux-gnu 
> (Debian)? Is this something related to the citation style of the library.bib 
> file that I’ve used in my vignettes folder? It is the “apa-6th-edition.csl” 
> file downloaded from 
> https://raw.githubusercontent.com/citation-style-language/styles/master/apa-6th-edition.csl
>
>From https://cran.r-project.org/submit.html

"Package authors should make all reasonable efforts to provide
cross-platform portable code. Packages will not normally be accepted
that do not run on at least two of the major R platforms. Cases for
Windows-only packages will be considered, but CRAN may not be the most
appropriate place to host them.""

You might want to use win-builder (https://win-builder.r-project.org/)
to test your package on other platforms.

All the best,

Mauricio

=
Department of Civil Engineering
Faculty of Engineering and Sciences
Universidad de La Frontera, Temuco, Chile
http://hzambran.github.io/
=
mailto : mauricio.zambr...@ufrontera.cl
work-phone : +56 45 259 2812
=
"Life goes by so fast, that if you don't stop
and look around, you might miss it"
(from the film Ferris Bueller's Day Off)
=
Linux user #454569 -- Linux Mint user

-- 
La información contenida en este correo electrónico y cualquier anexo o 
respuesta relacionada, puede contener datos e información confidencial y no 
puede ser usada o difundida por personas distintas a su(s) destinatario(s). 
Si usted no es el destinatario de esta comunicación, le informamos que 
cualquier divulgación, distribución o copia de esta información constituye 
un delito conforme a la ley chilena. Si lo ha recibido por error, por favor 
borre el mensaje y todos sus anexos y notifique al remitente.

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

Re: [Rd] Daily News about R-devel/NEWS is not updating

[Duncan Murdoch]

On 15/05/2020 10:39 a.m., Jennifer Lyon wrote:

Hi:

The "Daily News about R-devel/NEWS" webpage at
http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be
updating. As of today, the latest entry is Tue, 14 Apr 2020.

Thanks.



Thanks for noticing that.  It's now fixed.  (The issue was that R-devel 
on the news machine didn't have rJava installed; the highlighting of 
differences is done by some old Java code.)


Duncan Murdoch

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

[Rd] Testing before release (was: edit() doubles backslashes when keep.source=TRUE)

[Duncan Murdoch]

On 15/05/2020 9:41 a.m., Martin Maechler wrote:
[ deletions ]



 Why does nobody anymore  help R development by working with
 "R-devel", or at least then the alpha, beta and the "RC"
 (Release Candidate) versions that we release daily for about one
 month before the final release?

 Notably a highly staffed enterprise such as Rstudio (viz the bug
 report 17800 above), but also others could really help by
 starting to use the "next version" of R on a routine basis ...

I understand the whining, bugs that get released are embarrassing.  But 
when I read the NEWS, I can see that both the NEW FEATURES and BUG FIXES 
sections of x.y.0 releases tend to be much longer than the BUG FIXES 
sections in patch releases.  That seems to indicate that things are 
working reasonably well.


For a really rough measure, just counting bullet points:

R 4.0.0:  65 new features, 55 bug fixes

R 3.6.3:  1 new feature, 7 bug fixes

R 3.6.2:  2 new features, 21 bug fixes

R 3.6.1:  0 new features, 16 bug fixes

R 3.6.0:  72 new features, 62 bug fixes

You can get these numbers programmatically:

R4 <- news()
table(R4$Category)

R3 <- news(package = "R-3")
table(R3$Version, R3$Category)

Duncan Murdoch

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

[Rd] Daily News about R-devel/NEWS is not updating

[Jennifer Lyon]

Hi:

The "Daily News about R-devel/NEWS" webpage at
http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be
updating. As of today, the latest entry is Tue, 14 Apr 2020.

Thanks.

Jen

[[alternative HTML version deleted]]

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

[R-pkg-devel] Package submission failed with two warnings

[FARSHAD TABASINEJAD]

Dear R-package-devel experts,

This is the first time I’m writing to this platform about a package I recently 
submitted to CRAN (my first package).
While the package is already available on CRAN, I still must fix a few warnings 
and one error as reported on the CRAN package check results page:
https://cran.r-project.org/web/checks/check_results_Rpvt.html

I recently resubmitted a modified version of the package to CRAN, however, it 
didn’t pass the automatic incoming checks. 

Windows:  
https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
Status: 1 WARNING

Debian:  
https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
Status: 2 WARNINGs


1) The first warning that appears on both Windows and Debian results is 
“Insufficient package version (submitted: 0.1.0, existing: 0.1.0)”.

Since the package is conditionally available on CRAN, do I need to modify the 
package version to 0.1.1 to get rid of this warning?
Is there any way to fix this problem with the current version of the 
package(0.1.0)?

2) The second problem appears on the Debian test results:

* checking re-building of vignette outputs ... [8s/8s] WARNING 

Error(s) in re-building vignettes: 
... 
--- re-building ‘Rpvt.Rmd’ using rmarkdown 

pandoc-citeproc: Error in $: Incompatible API versions: encoded with [1,20] 
but attempted to decode with [1,17,5,4].

CallStack (from HasCallStack): 
error, called at ./Text/Pandoc/JSON.hs:111:48 in pandoc-types-1.17.5.4 
5tHZ3B61A58JaKOMxwGQR4:Text.Pandoc.JSON 

Error running filter /usr/bin/pandoc-citeproc: 

Filter returned error status 1 
Error: processing vignette 'Rpvt.Rmd' failed with diagnostics: 
pandoc document conversion failed with error 83 --- 
failed re-building ‘Rpvt.Rmd’ 

SUMMARY: processing the following file failed: 
‘Rpvt.Rmd’ 

Error: Vignette re-building failed. 
Execution halted

I’ve created this package on a Windows operating system with no problem in 
creating the ‘Rpvt.Rmd’ file as is the case with the CRAN tests on 
x86_64-w64-mingw32 (64-bit).
Why does it fail to create the “Rpvt.Rmd” file on x86_64-pc-linux-gnu (Debian)? 
Is this something related to the citation style of the library.bib file that 
I’ve used in my vignettes folder? It is the “apa-6th-edition.csl” file 
downloaded from 
https://raw.githubusercontent.com/citation-style-language/styles/master/apa-6th-edition.csl

Thank you in advance!

Regards,
Farshad 


[[alternative HTML version deleted]]

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Martin Maechler]

> Sebastian Meyer 
> on Fri, 15 May 2020 10:47:55 +0200 writes:

> I can confirm this changed behaviour. I just compared R-3.6.3 with
> yesterday's R-devel. Using R-devel, the tempfile opened by the editor
> (Emacs for me, but shouldn't matter) contains doubled backslashes.

> This could be related to

> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17800

Yes, indeed, I'm sure this is the same; an inadvertent bug indeed.

> Best regards,
> Sebastian

... and  "just the usual"



Why does nobody anymore  help R development by working with
"R-devel", or at least then the alpha, beta and the "RC"
(Release Candidate) versions that we release daily for about one
month before the final release?

Notably a highly staffed enterprise such as Rstudio (viz the bug
report 17800 above), but also others could really help by
starting to use the "next version" of R on a routine basis ...



Still: Thank you, of course,
 Bill Dunlap, and Sebastian and Jonathan (PR 17800)

Martin

> Am 15.05.20 um 03:50 schrieb William Dunlap via R-devel:
>> Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
>> double all the backslashes when options(keep.source=TRUE)?  E.g.,
>> 
>>> options(keep.source=TRUE)
>>> f <- function(x) { cat("\t", x, "\n", sep="") }
>>> edit(f) # exit the editor without making any changes
>> The editor (vi or notepad) shows doubled backslashes
>> function(x) { cat("\\t", x, "\\n", sep="") }
>> as does the return value of edit().
>> 
>> If I set options(keep.source=FALSE) before defining 'f' or remove t's
>> 'srcref' attribute then the backslashes are left alone.
>> 
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com

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

Re: [Rd] justify hard coded in format.ftable

[SOEIRO Thomas]

Thanks for the links. I agree that such a feature would be a nice addition, and 
could make ftable even more useful.

In the same spirit, I think it could be useful to mention the undocumented 
base::as.data.frame.matrix function in documentation of table and xtabs (in 
addition to the already mentioned base::as.data.frame.table). The conversion 
from ftable/table/xtabs to data.frame is a common task that some users seem to 
struggle with 
(https://stackoverflow.com/questions/10758961/how-to-convert-a-table-to-a-data-frame).

tab <- table(warpbreaks$wool, warpbreaks$tension)
as.data.frame(tab) # reshaped table
as.data.frame.matrix(tab) # non-reshaped table

To sum up, for the sake of clarity, these proposals address two different 
topics:
- The justify argument would reduce the need to reformat the exported ftable
- An ftable2df-like function (and the mention of as.data.frame.matrix in the 
documentation) would facilitate the reuse of ftable results for further 
analysis.

Thank you very much,

Thomas

> If you are looking at ftable could you also consider adding a way to convert 
> an ftable into a usable data.frame such as the ftable2df function defined 
> here:
> 
> https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126
> 
> and there is an example of using it here:
> 
> https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756
> 
> Being able to move back and forth between various base class representations 
> seems like something that would be natural to provide.
> 
> Thanks.
> 
> On Thu, May 14, 2020 at 5:32 AM Martin Maechler  
> wrote:
>>
>>> SOEIRO Thomas
>>> on Wed, 13 May 2020 20:27:15 + writes:
>>
>>> Dear all,
>>> I haven't received any feedback so far on my proposal to make 
>> "justify" argument available in stats:::format.ftable
>>
>>> Is this list the appropriate place for this kind of proposal?
>>
>> Yes, it is.. Actually such a post is even a "role model" post for 
>> R-devel.
>>
>>> I hope this follow-up to my message won't be taken as rude. Of course it's 
>>> not meant to be, but I'm not used to the R mailing lists...
>>
>> well, there could be said much, and many stories told here ... ;-)
>>
>>> Thank you in advance for your comments,
>>
>>> Best,
>>> Thomas
>>
>> The main reasons for "no reaction" (for such nice post) probably are 
>> combination of the following
>>
>> - we are busy
>> - if we have time, we think other things are more exciting
>> - we have not used ftable much/at all and are not interested.
>>
>> Even though the first 2 apply to me, I'll have a 2nd look into your 
>> post now, and may end up well agreeing with your proposal.
>>
>> Martin Maechler
>> ETH Zurich  and  R Core team
>>
>>
>>
>>
 Dear all,

 justify argument is hard coded in format.ftable:

 cbind(apply(LABS, 2L, format, justify = "left"),
 apply(DATA, 2L, format, justify = "right"))

 It would be useful to have the possibility to modify the argument between 
 c("left", "right", "centre", "none") as in format.default.

 The lines could be changed to:

 if(length(justify) != 2)
 stop("justify must be length 2")
 cbind(apply(LABS, 2L, format, justify = justify[1]),
 apply(DATA, 2L, format, justify = justify[2]))

 The argument justify could defaults to c("left", "right") for backward 
 compatibility.

 It could then allow:
 ftab <- ftable(wool + tension ~ breaks, warpbreaks)
 format.ftable(ftab, justify = c("none", "none"))

 Best regards,

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

Re: [Rd] justify hard coded in format.ftable

[Gabor Grothendieck]

If you are looking at ftable could you also consider adding
a way to convert an ftable into a usable data.frame such as
the ftable2df function defined here:

https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126

and there is an example of using it here:

https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756

Being able to move back and forth between various base class representations
seems like something that would be natural to provide.

Thanks.

On Thu, May 14, 2020 at 5:32 AM Martin Maechler
 wrote:
>
> > SOEIRO Thomas
> > on Wed, 13 May 2020 20:27:15 + writes:
>
> > Dear all,
> > I haven't received any feedback so far on my proposal to make "justify" 
> argument available in stats:::format.ftable
>
> > Is this list the appropriate place for this kind of proposal?
>
> Yes, it is.. Actually such a post is even a "role model" post
> for R-devel.
>
> > I hope this follow-up to my message won't be taken as rude. Of course 
> it's not meant to be, but I'm not used to the R mailing lists...
>
> well, there could be said much, and many stories told here ... ;-)
>
> > Thank you in advance for your comments,
>
> > Best,
> > Thomas
>
> The main reasons for "no reaction" (for such nice post) probably
> are combination of the following
>
> - we are busy
> - if we have time, we think other things are more exciting
> - we have not used ftable much/at all and are not interested.
>
> Even though the first 2 apply to me, I'll have a 2nd look into
> your post now, and may end up well agreeing with your proposal.
>
> Martin Maechler
> ETH Zurich  and  R Core team
>
>
>
>
> >> Dear all,
> >>
> >> justify argument is hard coded in format.ftable:
> >>
> >> cbind(apply(LABS, 2L, format, justify = "left"),
> >> apply(DATA, 2L, format, justify = "right"))
> >>
> >> It would be useful to have the possibility to modify the argument 
> between c("left", "right", "centre", "none") as in format.default.
> >>
> >> The lines could be changed to:
> >>
> >> if(length(justify) != 2)
> >> stop("justify must be length 2")
> >> cbind(apply(LABS, 2L, format, justify = justify[1]),
> >> apply(DATA, 2L, format, justify = justify[2]))
> >>
> >> The argument justify could defaults to c("left", "right") for backward 
> compatibility.
> >>
> >> It could then allow:
> >> ftab <- ftable(wool + tension ~ breaks, warpbreaks)
> >> format.ftable(ftab, justify = c("none", "none"))
> >>
> >> Best regards,
> >>
> >> Thomas
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] justify hard coded in format.ftable

[Gabor Grothendieck]

One can use as.data.frame(as.matrix(tab)) to avoid calling
as.data.frame.matrix directly
(although I find I do use as.data.frame.matrix anyways sometimes even
though it is generally
better to call the generic.).

Also note that the various as.data.frame methods do not address the examples
in the SO links I posted which is why I mentioned it.

On Thu, May 14, 2020 at 9:22 AM SOEIRO Thomas  wrote:
>
> Thanks for the links. I agree that such a feature would be a nice addition, 
> and could make ftable even more useful.
>
> In the same spirit, I think it could be useful to mention the undocumented 
> base::as.data.frame.matrix function in documentation of table and xtabs (in 
> addition to the already mentioned base::as.data.frame.table). The conversion 
> from ftable/table/xtabs to data.frame is a common task that some users seem 
> to struggle with 
> (https://stackoverflow.com/questions/10758961/how-to-convert-a-table-to-a-data-frame).
>
> tab <- table(warpbreaks$wool, warpbreaks$tension)
> as.data.frame(tab) # reshaped table
> as.data.frame.matrix(tab) # non-reshaped table
>
> To sum up, for the sake of clarity, these proposals address two different 
> topics:
> - The justify argument would reduce the need to reformat the exported ftable
> - An ftable2df-like function (and the mention of as.data.frame.matrix in the 
> documentation) would facilitate the reuse of ftable results for further 
> analysis.
>
> Thank you very much,
>
> Thomas
>
> > If you are looking at ftable could you also consider adding a way to 
> > convert an ftable into a usable data.frame such as the ftable2df function 
> > defined here:
> >
> > https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126
> >
> > and there is an example of using it here:
> >
> > https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756
> >
> > Being able to move back and forth between various base class 
> > representations seems like something that would be natural to provide.
> >
> > Thanks.
> >
> > On Thu, May 14, 2020 at 5:32 AM Martin Maechler 
> >  wrote:
> >>
> >>> SOEIRO Thomas
> >>> on Wed, 13 May 2020 20:27:15 + writes:
> >>
> >>> Dear all,
> >>> I haven't received any feedback so far on my proposal to make
> >> "justify" argument available in stats:::format.ftable
> >>
> >>> Is this list the appropriate place for this kind of proposal?
> >>
> >> Yes, it is.. Actually such a post is even a "role model" post for
> >> R-devel.
> >>
> >>> I hope this follow-up to my message won't be taken as rude. Of course 
> >>> it's not meant to be, but I'm not used to the R mailing lists...
> >>
> >> well, there could be said much, and many stories told here ... ;-)
> >>
> >>> Thank you in advance for your comments,
> >>
> >>> Best,
> >>> Thomas
> >>
> >> The main reasons for "no reaction" (for such nice post) probably are
> >> combination of the following
> >>
> >> - we are busy
> >> - if we have time, we think other things are more exciting
> >> - we have not used ftable much/at all and are not interested.
> >>
> >> Even though the first 2 apply to me, I'll have a 2nd look into your
> >> post now, and may end up well agreeing with your proposal.
> >>
> >> Martin Maechler
> >> ETH Zurich  and  R Core team
> >>
> >>
> >>
> >>
>  Dear all,
> 
>  justify argument is hard coded in format.ftable:
> 
>  cbind(apply(LABS, 2L, format, justify = "left"),
>  apply(DATA, 2L, format, justify = "right"))
> 
>  It would be useful to have the possibility to modify the argument 
>  between c("left", "right", "centre", "none") as in format.default.
> 
>  The lines could be changed to:
> 
>  if(length(justify) != 2)
>  stop("justify must be length 2")
>  cbind(apply(LABS, 2L, format, justify = justify[1]),
>  apply(DATA, 2L, format, justify = justify[2]))
> 
>  The argument justify could defaults to c("left", "right") for backward 
>  compatibility.
> 
>  It could then allow:
>  ftab <- ftable(wool + tension ~ breaks, warpbreaks)
>  format.ftable(ftab, justify = c("none", "none"))
> 
>  Best regards,
> 
>  Thomas



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [R-pkg-devel] Help Debugging Debian Error

[Gábor Csárdi]

You don't need to move the files around, though, just use a more
verbose testthat reporter, e.g. in testthat.R use

test_check("PAutilities", reporter = "summary")

and then at least you'll know where it crashes. But to fix this,
you'll probably need to debug it locally. You can do that in Docker if
you don't have a local Linux machine.

Gabor

On Fri, May 15, 2020 at 10:00 AM Ivan Krylov  wrote:
>
> On Fri, 15 May 2020 03:50:12 -0400
> Paul Hibbing  wrote:
>
> > Complete output:
> >   > library(testthat)
> >   > library(PAutilities)
> >   >
> >   > test_check("PAutilities")
>
> It seems to me that the R process crashes while running your tests, but
> since testthat::test_check captures everything to summarise it later,
> you don't get to know where the crash occurs.
>
> Perhaps if you (temporarily) move your tests out of testthat/
> subdirectory and remove the context() and testthat::test_that("...",
> { ... }) calls, you would be able to see the exact location of the
> crash in the *.Rout files?
>
> That said, it's probably one of your dependencies that's responsible
> for the crash, not your package, since there is no compiled code.
>
> --
> Best regards,
> Ivan
>
> __
> 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] Help Debugging Debian Error

[Ivan Krylov]

On Fri, 15 May 2020 03:50:12 -0400
Paul Hibbing  wrote:

> Complete output:
>   > library(testthat)
>   > library(PAutilities)
>   >
>   > test_check("PAutilities")  

It seems to me that the R process crashes while running your tests, but
since testthat::test_check captures everything to summarise it later,
you don't get to know where the crash occurs.

Perhaps if you (temporarily) move your tests out of testthat/
subdirectory and remove the context() and testthat::test_that("...",
{ ... }) calls, you would be able to see the exact location of the
crash in the *.Rout files?

That said, it's probably one of your dependencies that's responsible
for the crash, not your package, since there is no compiled code.

-- 
Best regards,
Ivan

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Sebastian Meyer]

I can confirm this changed behaviour. I just compared R-3.6.3 with
yesterday's R-devel. Using R-devel, the tempfile opened by the editor
(Emacs for me, but shouldn't matter) contains doubled backslashes.

This could be related to

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17800

Best regards,

Sebastian


Am 15.05.20 um 03:50 schrieb William Dunlap via R-devel:
> Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
> double all the backslashes when options(keep.source=TRUE)?  E.g.,
> 
>> options(keep.source=TRUE)
>> f <- function(x) { cat("\t", x, "\n", sep="") }
>> edit(f) # exit the editor without making any changes
> The editor (vi or notepad) shows doubled backslashes
> function(x) { cat("\\t", x, "\\n", sep="") }
> as does the return value of edit().
> 
> If I set options(keep.source=FALSE) before defining 'f' or remove t's
> 'srcref' attribute then the backslashes are left alone.
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.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: [R-pkg-devel] Help Debugging Debian Error

[Paul Hibbing]

Removing the startup message did not resolve the issue. Now I have just:

* checking tests ...
  Running ‘testthat.R’
 ERROR
Running the tests in ‘tests/testthat.R’ failed.
Complete output:
  > library(testthat)
  > library(PAutilities)
  >
  > test_check("PAutilities")

See 
https://artifacts.r-hub.io/PAutilities_1.0.0.tar.gz-6f71309b168b4e65a685775a20764c70/PAutilities.Rcheck/00check.log

Paul


On Fri, May 15, 2020 at 2:34 AM Dirk Eddelbuettel  wrote:
>
>
> On 15 May 2020 at 02:30, Gábor Csárdi wrote:
> | It is unlikely that this is an R-hub issue because the first link is
> | CRAN's machine, and the same error happens there.
>
> My bad, sorry -- I read the original email(s) wrong.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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