Re: [R-pkg-devel] Options "reset" when options(opts)

[David Hugh-Jones]

This surprised me, even though it shouldn’t have done. (My false internal
model of the world was that oo <- options(); … options(oo) would overwrite
the entire options list with the old values.) I wonder if it would be worth
pointing out explicitly in ?options.

Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Thu, 11 Jul 2024 at 08:03, Greg Jefferis  wrote:

> Dear John,
>
> You need to collect the return value when setting options. This will
> include an explicit NULL value for an option that was previously NULL.
>
> Best,
>
> Greg Jefferis.
>
> options(digits.secs = NULL)
>
> noset2 = function() {
>   opts <- options(digits.secs = 3)
>   on.exit(options(opts))
>   print(opts)
> }
>
> > getOption("digits.secs")
> NULL
>
> > noset2()
> $digits.secs
> NULL
>
> > getOption("digits.secs")
> NULL
>
> Gregory Jefferis
> Division of Neurobiology
> MRC Laboratory of Molecular Biology
> Francis Crick Avenue
> Cambridge Biomedical Campus
> Cambridge, CB2 OQH, UK
>
> http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
> http://jefferislab.org
> https://www.zoo.cam.ac.uk/research/groups/connectomics
>
>
> > On 11 Jul 2024, at 06:08, John Muschelli  wrote:
> >
> > When setting options in a function, I have always used the following:
> >  opts <- options()
> >  on.exit(options(opts), add = TRUE)
> > and assumed it "reset" options to what they were prior to running the
> > function.  But for some options that are set to NULL, it does not seem to
> > reset them.  Specifically, I have found digits.secs to be set after this
> > simple example below.  Is this expected behavior/documented?  Overall,
> this
> > specific example (the one I encountered in the wild) is not that harmful,
> > but I wanted to ask before I set a fix for this in our work
> >
> > noset = function() {
> >  opts = options()
> >  print(opts$digits.secs)
> >  on.exit(options(opts))
> >  options(digits.secs = 3)
> > }
> > getOption("digits.secs")
> > #> NULL
> > noset()
> > #> NULL
> > getOption("digits.secs")
> > #> [1] 3
> >
> >
> > John Muschelli, PhD
> > Associate Research Professor
> > Department of Biostatistics
> > Johns Hopkins Bloomberg School of Public Health
> >
> > [[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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Package failing reverse dependency checks

[David Hugh-Jones]

Thanks for this tip. Out of interest, is there a way to make win/Mac
builder run revdep checks?

Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Thu, 8 Feb 2024 at 10:26, Lluís Revilla  wrote:

> Hi David,
>
> If you didn't increase the version number it could happen that the old
> version of the package was used (as CRAN might not be aware that there is a
> new version).
> The CRAN repository policy says: "Increasing the version number at each
> submission reduces confusion so is preferred even when a previous
> submission was not accepted".
> In addition, it is easier to track how smooth the submission process is
> for maintainers/developers.
>
> I would recommend submitting again, changing the version number of the
> package.
> Checking on  win builders and macos builders CRAN provides is the closest
> one, other approaches include rhub2.
>
> Best,
>
> Lluís
>
>
>
> On Thu, 8 Feb 2024 at 10:24, David Hugh-Jones 
> wrote:
>
>> Hi all,
>>
>> I'm trying to upload a new version of my "huxtable" package. It is
>> currently failing reverse dependency checks for two packages (homnormal
>> and
>> RSStest). The relevant failures are below.
>>
>> I got this failure one time, and fixed the problem, which relates to
>> mistakenly relying on the Suggested: knitr package (see here for the
>> commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
>> commit, reverse dependency checks for homnormal and RSStest pass on my
>> machine, when testing either with revdepcheck::revdep_check or
>> tools::check_packages_in_dir, and even when knitr is not installed. But,
>> after I uploaded the new package to CRAN, the same failure recurred.
>>
>> My new release candidate had the same version number as the previous one
>> (which had failed the revdep check, and therefore not been published on
>> CRAN). Is it possible that CRAN just tested the old version again?
>>
>> If not, then can anyone suggest the best way to debug a revdep check on as
>> close a setup to the CRAN machines as possible?
>>
>> Cheers,
>> David
>>
>> Git tag for the last CRAN submission:
>> https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
>>
>> Info from the CRAN email:
>> --
>> Debian: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
>> >
>> RSStest, homnormal
>>
>> Log dir: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
>> >
>> The files will be removed after roughly 7 days.
>>
>> Pretests:
>> Windows: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
>> >
>> Debian: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
>> >
>> --
>> Changes to worse in reverse depends:
>>
>> Package: homnormal
>> Check: examples
>> New result: ERROR
>>   Running examples in ‘homnormal-Ex.R’ failed
>>   The error most likely occurred in:
>>
>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>   > ### Name: Brown_Forsythe
>>   > ### Title: Brown-Forsythe Test for Homogeniety
>>   > ### Aliases: Brown_Forsythe
>>   >
>>   > ### ** Examples
>>   >
>>   > data(FH_data)
>>   >x1=FH_data$SurvivalTime
>>   >x2=FH_data$HospitalNo
>>   >Brown_Forsythe(x1,x2)
>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>   Calls: Brown_Forsythe ... loadNamespace -> withRestarts ->
>> withOneRestart
>> -> doWithOneRestart
>>   Execution halted
>>
>> Package: RSStest
>> Check: examples
>> New result: ERROR
>>   Running examples in ‘RSStest-Ex.R’ failed
>>   The error most likely occurred in:
>>
>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>   > ### Name: teststat_MRSS
>>   > ### Title: Median Ranked Set Sampling Test
>>   > ### Aliases: teststat_MRSS
>>   >
>>   > ### ** Examples
>>   >
>>   > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
>>   > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
>>   > teststat_MRSS(x1,x2,tn=1000)
>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>   Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
>> -> doWithOneRestart
>>   Execution halted
>>
>> [[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

[R-pkg-devel] Package failing reverse dependency checks

[David Hugh-Jones]

Hi all,

I'm trying to upload a new version of my "huxtable" package. It is
currently failing reverse dependency checks for two packages (homnormal and
RSStest). The relevant failures are below.

I got this failure one time, and fixed the problem, which relates to
mistakenly relying on the Suggested: knitr package (see here for the
commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
commit, reverse dependency checks for homnormal and RSStest pass on my
machine, when testing either with revdepcheck::revdep_check or
tools::check_packages_in_dir, and even when knitr is not installed. But,
after I uploaded the new package to CRAN, the same failure recurred.

My new release candidate had the same version number as the previous one
(which had failed the revdep check, and therefore not been published on
CRAN). Is it possible that CRAN just tested the old version again?

If not, then can anyone suggest the best way to debug a revdep check on as
close a setup to the CRAN machines as possible?

Cheers,
David

Git tag for the last CRAN submission:
https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3

Info from the CRAN email:
--
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
>
RSStest, homnormal

Log dir: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
>
The files will be removed after roughly 7 days.

Pretests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
>
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
>
--
Changes to worse in reverse depends:

Package: homnormal
Check: examples
New result: ERROR
  Running examples in ‘homnormal-Ex.R’ failed
  The error most likely occurred in:

  > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
  > ### Name: Brown_Forsythe
  > ### Title: Brown-Forsythe Test for Homogeniety
  > ### Aliases: Brown_Forsythe
  >
  > ### ** Examples
  >
  > data(FH_data)
  >x1=FH_data$SurvivalTime
  >x2=FH_data$HospitalNo
  >Brown_Forsythe(x1,x2)
  Error in loadNamespace(x) : there is no package called ‘knitr’
  Calls: Brown_Forsythe ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
  Execution halted

Package: RSStest
Check: examples
New result: ERROR
  Running examples in ‘RSStest-Ex.R’ failed
  The error most likely occurred in:

  > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
  > ### Name: teststat_MRSS
  > ### Title: Median Ranked Set Sampling Test
  > ### Aliases: teststat_MRSS
  >
  > ### ** Examples
  >
  > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
  > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
  > teststat_MRSS(x1,x2,tn=1000)
  Error in loadNamespace(x) : there is no package called ‘knitr’
  Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
  Execution halted

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Inquiry Regarding Package Organization in CRAN

[David Hugh-Jones]

Hi Andriy

Renaming the packages seems quite drastic. It’ll break existing code and
the packages’ dependencies, and any existing name recognition will be lost.
I’m also a bit sceptical that it will greatly affect discoverability: I
don’t think most users find packages by scrolling through the big
alphabetical list.

Here are some less drastic alternatives :

* Post about new versions of the packages to r-pkgs mailing list.
* Write announcements, articles and/or blog posts for rweekly.org.
* if it’s appropriate, suggest the packages for one or more CRAN task
views.
* make sure you’ve got friendly online documentation. The pkgdown package
is pretty good for this, and many people host documentation on GitHub pages.

Best,
David

Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Fri, 19 Jan 2024 at 19:41, Protsak Andriy via R-package-devel <
r-package-devel@r-project.org> wrote:

> Hi all!
>
>
>
> My name is Andriy, and I’m a student at University of Alcalá, currently
> working on my final year project.
>
>
>
> I’m tasked with organizing the R packages developed by our university that
> are currently available on CRAN. The goal is to enhance their
> discoverability, to achieve this the initial focus is on exploring the
> possibility of renaming the packages so that they share a common prefix,
> making it easier for uses to locate them in the package list.
>
> If you believe there are alternative strategies to achieve a similar
> result, please feel free to share your perspective.
>
>
>
> Additionally, I’m looking into the prospect of merging two packages that
> contain similar functionalities. The aim is to create a more comprehensive
> package by incorporation additional features and ensuring seamless
> compatibility.
>
>
>
> Your assistance is key to the successful completion of my final year
> project, and I would be immensely grateful for any insights you can
> provide. Thank you for your time and consideration.
>
>
>
> Best regards,
>
>
>
> Andriy
>
> [[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: [R-pkg-devel] checking CRAN incoming feasibility

[David Hugh-Jones]

If I understand correctly, the current procedure is that the client
downloads every package name from CRAN, and then checks its name is
unique. Wouldn’t
it be faster (for both parties) to check name uniqueness directly on the
server?


Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Tue, 16 Jan 2024 at 05:25, Hugh Parsonage 
wrote:

> >  Surely the software just has to check
> that there is web connection to a CRAN mirror.
>
> Nope! The full code is in tools:::.check_package_CRAN_incoming  (the
> body of which filled up my entire console), but to name a few checks
> it has to do: check that the name of the package is not the same as
> any other, including archived packages (which means that it has to
> download the package metadata), make sure the licence is ok, see if
> the version number is ok. 10 minutes is quite a lot though. I suspect
> the initial connection may have been faulty.
>
> On Tue, 16 Jan 2024 at 16:15, Rolf Turner  wrote:
> >
> >
> > This post essentially amounts to idle curiosity.  I don't really expect
> > that anything can be done about the problem that I perceive.
> >
> > When I check a package using --as-cran, the code spits out a line
> >
> > checking CRAN incoming feasibility ...
> >
> > and then disappears into a black hole for what seems an eternity (5 or
> > 10 minutes).
> >
> > Why does this step take so long?  Surely the software just has to check
> > that there is web connection to a CRAN mirror.  I would have thought
> > that this would be executed virtually instantaneously.
> >
> > cheers,
> >
> > Rolf Turner
> >
> > --
> > Honorary Research Fellow
> > Department of Statistics
> > University of Auckland
> > Stats. Dep't. (secretaries) phone:
> >  +64-9-373-7599 ext. 89622
> > Home phone: +64-9-480-4619
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

[Rd] The case for a pipe assignment operator + database of R code

[David Hugh-Jones]

Hi all,

I wrote up the case for having a pipe assignment operator in R here:
https://hughjonesd.github.io/case-for-pipe-assignment.html

A pipe assignment operator would expand e.g.

obj <|> do_something()

to

obj <- obj |> do_something()

and therefore to

obj <- do_something(obj)

Just for fun, I made a patch to the R source at
https://hughjonesd.github.io/pipe-assignment.patch. It is highly imperfect,
and made against github rather than svn, so it is just a proof of concept.

Maybe more interesting to list readers is the dataset of R code I created
to learn how people use assignments in real world code. It has about 26000
code snippets, from github, Stackoverflow questions, and R package
examples. It might be useful if you are researching real world usage
patterns in R. I didn't know of any existing resources:

https://github.com/hughjonesd/codesamples

Happy new year!

David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[David Hugh-Jones]

Guys,

Martin, I am very sorry you spent all that time. I am sceptical that this
is a correct interpretation of the law, given what I see on Twitter daily,
and I would not take a university as an authority on this. But that is
neither here nor there – if I made you waste your time, that's my bad and
I'm sorry.

More generally, I have absolutely no wish to spend time beating up on any
individual – and people have kindly sent comments off-list that gave me
context about the specific case. But persistent rudeness is harmful, and
there ought to be a way to address it. Many projects use codes of conduct
for this purpose.

David


On Fri, 3 Nov 2023 at 11:15, Martin Maechler 
wrote:

> Dear R-package-devel readers *and* notably writers,
>
> In Europe there are (diverse) laws about privacy etc, and those,
> (and/or some politeness) do not allow
> free citing of private e-mail communications in public
> nor ad hominem remarks in such public communication.
>
> For this reason, I (as mailing list co-maintainer, and notably
> responsible for the lawfulness of the public mailing list archives on
> our web server) now spent about 2 hours  to carefully obey such
> privacy requirements (carefully editing + recreating all the html
> archives).
> {In another similar case, my employer, ETH Zurich, did urge me
> "from above" to spend my time with such a tedious and ungratifying job ...}
> This is *NOT* something I'd be happy to redo.
>
> So *please* do not misuse such a public mailing list and do keep
> your private opinions private in such a case in the future!
>
> >>>>> Spencer Graves  on Thu, 2 Nov 2023 15:29:29 -0500 writes:
>
> > On 11/2/23 2:52 PM, Rolf Turner wrote:
> >>
> >> On Wed, 1 Nov 2023 16:10:34 + David Hugh-Jones wrote:
> >>
> >>> Aside from the package question, surely the other issue
> >>> here is that ’s email is extraordinarily
> >>> rude. Any paid employee would be sacked for that. I
> >>> appreciate R and CRAN are volunteer-run organisations,
> >>> but I don’t think that should be an excuse for this
> >>> level of, frankly, toxicity. Why is he allowed to get
> >>> away with it?
> >>>
> >>> David
>
> >>
> >> I've just had a look at the initial posting in this
> >> thread
> >>
> >> and can see nothing rude or offensive in the email
> >> that was copied and pasted into that  posting.
> >>
> >> I find *your* email far more offensive than anything that
> >>  has ever written.  Get a life.
> >>
> >> cheers,
> >>
> >> Rolf Turner
> >>
> >> P.S.  See fortunes::fortune(88).
> >>
> >> R. T.
>
>
> > Hi, David:
>
>
> []
>
>
> > I've been in the military, and I've learned to ignore
> > the tone and look for the value in comments I
> > receive. I've learned a lot from , and
> > others. When the tone seemed less supportive or even
> > insulting, I'm very glad the person took the time to
> > comment and didn't decide not to reply for fear of
> > offending me. I'm more productive and a better human for
> > all the help I've gotten from this and other R-related
> > lists.
>
>
> > fortunes::fortune('Spencer Graves')
>
> which can you get 4 different answers; using `showMatches` argument
> (which I think I had added), e.g. now gives
>
> > fortune("Spencer Graves", showMatches = TRUE)
> Matching row numbers: 90, 124, 177, 271
>
> Rolf Turner: In the middle of a Saturday morning (in my Time Zone!) I send
> out a plea for help, and in
> just over 20 minutes my problem is solved!
> I don't think you get service like that anywhere else. This R-help list is
> BLOODY AMAZING!
> Spencer Graves: 'The sun never sets on the (former) British Empire.'
> Today, it never sets on R-Help.
>-- Rolf Turner and Spencer Graves
>   R-help (May 2005)
>
> and then
>
> > fortune(90)
>
> Our great-great grandchildren as yet unborn may read some of the stupid
> questions and/or answers that I
> and perhaps others give from time to time. I'd rather get flamed for
> saying something stupid in public on
> this list than to continue to provide substandard service to the people
> with whom I work because I
> perpetrated the same mistake in an environment in which no one questioned
> so effectively my errors.
>-- Spencer Graves (in a discussion on whether answers on R-help should
> be more polite)
>   R-help (December 2004)
>
> > sg
>
> Martin
>
>
> --
> Martin Maechler
> ETH Zurich  and  R Core team
>
> __
> 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: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[David Hugh-Jones]

Aside from the package question, surely the other issue here is that Prof
Ripley’s email is extraordinarily rude. Any paid employee would be sacked
for that. I appreciate R and CRAN are volunteer-run organisations, but I
don’t think that should be an excuse for this level of, frankly, toxicity.
Why is he allowed to get away with it?

David

On Wed, 1 Nov 2023 at 11:15, Alberto Garre  wrote:

> Dear community,
>
> I feel dismay for having to write this email, but the issue must be brought
> up. On the 20th of October, I received an email from CRAN warning me of an
> issue with one of the packages I maintain (bioOED). The package depended on
> MEIGOR, a package that was no longer available in Bioconductor. I was given
> until 2023-11-03 to fix the issue.
>
> I contacted the MEIGOR maintainers and they told me they were migrating to
> CRAN. Yesterday, they contacted me again, telling me they needed more time
> for the migration. Hence, I responded to the email I received from CRAN,
> asking for an extension of the previous deadline (2023-11-03).
>
> To my surprise, it is not just that the extension was not granted, but the
> package has been removed from CRAN today (2023-11-01). Two days before the
> deadline (2023-11-03): https://cran.r-project.org/package=bioOED
>
> Then, I checked my inbox and I saw an email from one of the CRAN
> maintainers, showing that the package was removed because he had felt
> offended by my email. I copy-paste the email below.
>
> I understand that maintaining CRAN must be a huge work. I also work in
> academia, so I am totally aware of all the extra work that is required from
> us. But it is unreasonable that a package can be removed just because a
> maintainer throws a tantrum
>
> Again, I am really sorry I had to write this email, but CRAN cannot work if
> we allow this type of situation.
>
> Kind regards,
> Alberto Garre
>
> ## Mail from rip...@stats.ox.ac.uk on 2023-11-01 8:28
>
> On 31/10/2023 17:21, Alberto Garre wrote:
> > Dear Brian,
>
> Do be respectful whoever you are (you lack the manners to use a
> signature block but send HTML when you agreed not to!).  What exactly
> have you done for me that would allow you treat me as if I were your peer?
>
> Your ingratitude (for CRAN and R) is deafening.
>
> > I have talked to the MEIGOR developers and they need a bit more time to
> > update their package. Would it be possible to get a 4 weeks extension for
> > the update of bioOED?
>
> No one can even install it in current R, so it has been removed.
>
> "The time of the volunteers is CRAN’s most precious resource"
>
> Professor Ripley
>
> >
> > Thank you very much,
> > Alberto
> >
> >
> > El vie, 20 oct 2023 a las 9:24, Alberto Garre ( >)
> > escribió:
> >
> >> Thank you very much, Brian.
> >>
> >> I have just contacted the developers of MEIGOR because I think they were
> >> planning a migration to CRAN. I will update the package asap.
> >>
> >> Best,
> >> Alberto
> >>
> >>
> >> El vie, 20 oct 2023 a las 9:22, Prof Brian Ripley (<
> rip...@stats.ox.ac.uk
> >)
> >> escribió:
> >>
> >>> On 20/10/2023 08:17, Prof Brian Ripley wrote:
>  Dear maintainer,
> 
>  Please see the problems shown on
>  .
> 
>  Please correct before 2023-11-03 to safely retain your package on
> CRAN.
> 
>  The CRAN Team
> 
> >>> This requires package MEIGOR which is not part of BioC 3.18 and has
> been
> >>> deprecated so it very unlikely to be part of the final release next
> week.
> >>>
> >>>
> >>> --
> >>> Brian D. Ripley,  rip...@stats.ox.ac.uk
> >>> Emeritus Professor of Applied Statistics, University of Oxford
> >>>
> >>>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Writing: wyclif.substack.com
Book: www.wyclifsdust.com

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

I think trying to guess where topics have moved will be hard. I'll consider
version links.
David


On Fri, 30 Jun 2023 at 17:04, Duncan Murdoch 
wrote:

> I agree, really nice.
>
> One suggestion would be to check for the existence of the corresponding
> topic link.
>
> For example,
> <https://hughjonesd.github.io/r-help/2.9.0/graphics/plot.html> links to
> <https://stat.ethz.ch/R-manual/R-patched/library/graphics/html/plot.html>,
>
> which doesn't exist.  The generic is now in the base package, at
> <https://stat.ethz.ch/R-manual/R-patched/library/base/html/plot.html>.
>
> Duncan Murdoch
>
> On 30/06/2023 11:37 a.m., Ben Bolker wrote:
> > Nice! (I like "A longer description will go here eventually.")
> >
> >It would be cute/handy to have navigation links available for "go to
> > this help page in the next (previous) version of R" (if it's not a huge
> > pain)
> >
> > On 2023-06-30 11:10 a.m., David Hugh-Jones wrote:
> >> OK, so I took Jeff's hint and did this myself!
> >>
> >> https://github.com/hughjonesd/r-help
> >>
> >> Sample page for ?plot from the first version of R (at least, the first
> >> version that is on svn):
> >>
> >> https://hughjonesd.github.io/r-help/0.60/base/plot.html
> >>
> >> Not everything is guaranteed to work, so please report bugs if you find
> any.
> >>
> >> Cheers,
> >> David
> >>
> >>
> >> On Fri, 30 Jun 2023 at 13:23, David Hugh-Jones <
> davidhughjo...@gmail.com>
> >> wrote:
> >>
> >>>
> >>> There are plenty of places to find current docs. I think it’s fine to
> have
> >>> versioned ones also. I agree it would be a good idea to clearly signal
> >>> “hey, this is an old version” - indeed I’ve been bitten by that in
> python
> >>> before. I’m working on this now… will see what I can do.
> >>>
> >>> Does anyone happen to know if it’s possible to create 00index files
> >>> without installing the relevant package? (Loading R 0.60 is
> challenging…)
> >>>
> >>> D
> >>>
> >>>
> >>>
> >>> On Fri, 30 Jun 2023 at 13:02, Duncan Murdoch  >
> >>> wrote:
> >>>
> >>>> On 30/06/2023 7:57 a.m., David Hugh-Jones wrote:
> >>>>> Static web pages get indexed by google.
> >>>>
> >>>> Isn't that an argument against having static pages?  If I do a Google
> >>>> search for "R lm" I think it's better to find the current docs rather
> >>>> than dozens of obsolete versions.  It's rare that someone wants to see
> >>>> changes across versions, so doing that should take extra work.
> >>>>
> >>>> Duncan Murdoch
> >>>>
> >>>>>
> >>>>> David
> >>>>>
> >>>>>
> >>>>> On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch <
> murdoch.dun...@gmail.com
> >>>>> <mailto:murdoch.dun...@gmail.com>> wrote:
> >>>>>
> >>>>>   Why store them?  Download the source on demand, and convert it.
> >>>> Seems
> >>>>>   pretty simple.
> >>>>>
> >>>>>   Duncan Murdoch
> >>>>>
> >>>>>   On 30/06/2023 1:19 a.m., David Hugh-Jones wrote:
> >>>>>> This is for the rcheology package. I run a Shiny web app
> which
> >>>>>   lets you
> >>>>>> examine changes to functions across R versions:
> >>>>>>
> >>>>>> https://hughjonesd.shinyapps.io/rcheology/
> >>>>>   <https://hughjonesd.shinyapps.io/rcheology/>
> >>>>>>
> >>>>>> Manually storing and converting the Rd might be possible,
> but it
> >>>>>   would be
> >>>>>> burdensome in terms of data (and my time). And if the Rd
> spec has
> >>>>>   changed
> >>>>>> across versions, that’s another problem.
> >>>>>>
> >>>>>> More generally, shouldn’t there be publicly available
> versioned
> >>>>>    > documentation? Python has had this for a long time.
> >>>>>>
> >>>>>> David
> >>>

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

OK, so I took Jeff's hint and did this myself!

https://github.com/hughjonesd/r-help

Sample page for ?plot from the first version of R (at least, the first
version that is on svn):

https://hughjonesd.github.io/r-help/0.60/base/plot.html

Not everything is guaranteed to work, so please report bugs if you find any.

Cheers,
David


On Fri, 30 Jun 2023 at 13:23, David Hugh-Jones 
wrote:

>
> There are plenty of places to find current docs. I think it’s fine to have
> versioned ones also. I agree it would be a good idea to clearly signal
> “hey, this is an old version” - indeed I’ve been bitten by that in python
> before. I’m working on this now… will see what I can do.
>
> Does anyone happen to know if it’s possible to create 00index files
> without installing the relevant package? (Loading R 0.60 is challenging…)
>
> D
>
>
>
> On Fri, 30 Jun 2023 at 13:02, Duncan Murdoch 
> wrote:
>
>> On 30/06/2023 7:57 a.m., David Hugh-Jones wrote:
>> > Static web pages get indexed by google.
>>
>> Isn't that an argument against having static pages?  If I do a Google
>> search for "R lm" I think it's better to find the current docs rather
>> than dozens of obsolete versions.  It's rare that someone wants to see
>> changes across versions, so doing that should take extra work.
>>
>> Duncan Murdoch
>>
>> >
>> > David
>> >
>> >
>> > On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch > > <mailto:murdoch.dun...@gmail.com>> wrote:
>> >
>> > Why store them?  Download the source on demand, and convert it.
>> Seems
>> > pretty simple.
>> >
>> > Duncan Murdoch
>> >
>> > On 30/06/2023 1:19 a.m., David Hugh-Jones wrote:
>> >  > This is for the rcheology package. I run a Shiny web app which
>> > lets you
>> >  > examine changes to functions across R versions:
>> >  >
>> >  > https://hughjonesd.shinyapps.io/rcheology/
>> > <https://hughjonesd.shinyapps.io/rcheology/>
>> >  >
>> >  > Manually storing and converting the Rd might be possible, but it
>> > would be
>> >  > burdensome in terms of data (and my time). And if the Rd spec has
>> > changed
>> >  > across versions, that’s another problem.
>> >  >
>> >  > More generally, shouldn’t there be publicly available versioned
>> >  > documentation? Python has had this for a long time.
>> >  >
>> >  > David
>> >  >
>> >  >
>> >  > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller
>> > mailto:jdnew...@dcn.davis.ca.us>>
>> >  > wrote:
>> >  >
>> >  >> Sure. On your computer. Install the old version of R and let it
>> > serve the
>> >  >> relevant docs.
>> >  >>
>> >  >> Dunno of anyone doing this historical dive online for you
>> > though. Why
>> >  >> would you want preformatted docs if you didn't have those old
>> > versions
>> >  >> installed?
>> >  >>
>> >  >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones <
>> >  >> davidhughjo...@gmail.com <mailto:davidhughjo...@gmail.com>>
>> wrote:
>> >  >>> That’s useful to know. But is there anywhere with preformatted
>> > HTML pages?
>> >  >>>
>> >  >>> Cheers, D
>> >  >>>
>> >  >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov
>> > mailto:krylov.r...@gmail.com>> wrote:
>> >  >>>
>> >  >>>> On Thu, 29 Jun 2023 20:22:47 +0100
>> >  >>>> David Hugh-Jones > > <mailto:davidhughjo...@gmail.com>> wrote:
>> >  >>>>
>> >  >>>>> I'm looking for a source of online help for R base
>> >  >>>>> packages, which covers all versions (for some reasonable
>> value of
>> >  >>>>> "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
>> >  >>>>
>> >  >>>> These live in the R source tree, under src/library:
>> >  >>>> https://svn.r-project.org/R/trunk/src/library/
>> > <https://svn.r-project.org/R/trunk/src/library/>
>> >  >>>&

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

There are plenty of places to find current docs. I think it’s fine to have
versioned ones also. I agree it would be a good idea to clearly signal
“hey, this is an old version” - indeed I’ve been bitten by that in python
before. I’m working on this now… will see what I can do.

Does anyone happen to know if it’s possible to create 00index files without
installing the relevant package? (Loading R 0.60 is challenging…)

D



On Fri, 30 Jun 2023 at 13:02, Duncan Murdoch 
wrote:

> On 30/06/2023 7:57 a.m., David Hugh-Jones wrote:
> > Static web pages get indexed by google.
>
> Isn't that an argument against having static pages?  If I do a Google
> search for "R lm" I think it's better to find the current docs rather
> than dozens of obsolete versions.  It's rare that someone wants to see
> changes across versions, so doing that should take extra work.
>
> Duncan Murdoch
>
> >
> > David
> >
> >
> > On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch  > <mailto:murdoch.dun...@gmail.com>> wrote:
> >
> > Why store them?  Download the source on demand, and convert it.
> Seems
> > pretty simple.
> >
> > Duncan Murdoch
> >
> > On 30/06/2023 1:19 a.m., David Hugh-Jones wrote:
> >  > This is for the rcheology package. I run a Shiny web app which
> > lets you
> >  > examine changes to functions across R versions:
> >  >
> >  > https://hughjonesd.shinyapps.io/rcheology/
> > <https://hughjonesd.shinyapps.io/rcheology/>
> >  >
> >  > Manually storing and converting the Rd might be possible, but it
> > would be
> >  > burdensome in terms of data (and my time). And if the Rd spec has
> > changed
> >  > across versions, that’s another problem.
> >  >
> >  > More generally, shouldn’t there be publicly available versioned
> >  > documentation? Python has had this for a long time.
> >  >
> >  > David
> >  >
> >  >
> >  > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller
> > mailto:jdnew...@dcn.davis.ca.us>>
> >  > wrote:
> >  >
> >  >> Sure. On your computer. Install the old version of R and let it
> > serve the
> >  >> relevant docs.
> >  >>
> >  >> Dunno of anyone doing this historical dive online for you
> > though. Why
> >  >> would you want preformatted docs if you didn't have those old
> > versions
> >  >> installed?
> >  >>
> >  >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones <
> >  >> davidhughjo...@gmail.com <mailto:davidhughjo...@gmail.com>>
> wrote:
> >  >>> That’s useful to know. But is there anywhere with preformatted
> > HTML pages?
> >  >>>
> >  >>> Cheers, D
> >  >>>
> >  >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov
> > mailto:krylov.r...@gmail.com>> wrote:
> >  >>>
> >  >>>> On Thu, 29 Jun 2023 20:22:47 +0100
> >  >>>> David Hugh-Jones  > <mailto:davidhughjo...@gmail.com>> wrote:
> >  >>>>
> >  >>>>> I'm looking for a source of online help for R base
> >  >>>>> packages, which covers all versions (for some reasonable
> value of
> >  >>>>> "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
> >  >>>>
> >  >>>> These live in the R source tree, under src/library:
> >  >>>> https://svn.r-project.org/R/trunk/src/library/
> > <https://svn.r-project.org/R/trunk/src/library/>
> >  >>>>
> >  >>>> For the actual releases of R, you may have to go looking at the
> >  >>>> branches inside that repository, e.g., the following command:
> >  >>>>
> >  >>>> svn log \
> >  >>>>
> >  >>>>
> >  >>
> >
> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
> <
> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
> >
> >  >>>>
> >  >>>> ...should tell you the history of ?lm until the latest
> > R-4.1-patched.
> >  >>>>
> >  >>>> Do the Git mirrors track these release branches? The branching
> > model of
> >  >>>> Subversion [*] is different from the Git model, so perhaps not.
> >  >>>>
> >  >>>> --
> >  >>>> Best regards,
> >  >>>> Ivan
> >  >>>>
> >  >>>> [*]
> > https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
> > <https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html>
> >  >>>>
> >  >>
> >  >> --
> >  >> Sent from my phone. Please excuse my brevity.
> >  >>
> >  >> __
> >  >> R-package-devel@r-project.org
> > <mailto:R-package-devel@r-project.org> mailing list
> >  >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> >  >>
> >
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

Static web pages get indexed by google.

David


On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch 
wrote:

> Why store them?  Download the source on demand, and convert it.  Seems
> pretty simple.
>
> Duncan Murdoch
>
> On 30/06/2023 1:19 a.m., David Hugh-Jones wrote:
> > This is for the rcheology package. I run a Shiny web app which lets you
> > examine changes to functions across R versions:
> >
> > https://hughjonesd.shinyapps.io/rcheology/
> >
> > Manually storing and converting the Rd might be possible, but it would be
> > burdensome in terms of data (and my time). And if the Rd spec has changed
> > across versions, that’s another problem.
> >
> > More generally, shouldn’t there be publicly available versioned
> > documentation? Python has had this for a long time.
> >
> > David
> >
> >
> > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller 
> > wrote:
> >
> >> Sure. On your computer. Install the old version of R and let it serve
> the
> >> relevant docs.
> >>
> >> Dunno of anyone doing this historical dive online for you though. Why
> >> would you want preformatted docs if you didn't have those old versions
> >> installed?
> >>
> >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones <
> >> davidhughjo...@gmail.com> wrote:
> >>> That’s useful to know. But is there anywhere with preformatted HTML
> pages?
> >>>
> >>> Cheers, D
> >>>
> >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov 
> wrote:
> >>>
> >>>> On Thu, 29 Jun 2023 20:22:47 +0100
> >>>> David Hugh-Jones  wrote:
> >>>>
> >>>>> I'm looking for a source of online help for R base
> >>>>> packages, which covers all versions (for some reasonable value of
> >>>>> "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
> >>>>
> >>>> These live in the R source tree, under src/library:
> >>>> https://svn.r-project.org/R/trunk/src/library/
> >>>>
> >>>> For the actual releases of R, you may have to go looking at the
> >>>> branches inside that repository, e.g., the following command:
> >>>>
> >>>> svn log \
> >>>>
> >>>>
> >>
> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
> >>>>
> >>>> ...should tell you the history of ?lm until the latest R-4.1-patched.
> >>>>
> >>>> Do the Git mirrors track these release branches? The branching model
> of
> >>>> Subversion [*] is different from the Git model, so perhaps not.
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Ivan
> >>>>
> >>>> [*]
> https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
> >>>>
> >>
> >> --
> >> Sent from my phone. Please excuse my brevity.
> >>
> >> __
> >> 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: [R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

This is for the rcheology package. I run a Shiny web app which lets you
examine changes to functions across R versions:

https://hughjonesd.shinyapps.io/rcheology/

Manually storing and converting the Rd might be possible, but it would be
burdensome in terms of data (and my time). And if the Rd spec has changed
across versions, that’s another problem.

More generally, shouldn’t there be publicly available versioned
documentation? Python has had this for a long time.

David


On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller 
wrote:

> Sure. On your computer. Install the old version of R and let it serve the
> relevant docs.
>
> Dunno of anyone doing this historical dive online for you though. Why
> would you want preformatted docs if you didn't have those old versions
> installed?
>
> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
> >That’s useful to know. But is there anywhere with preformatted HTML pages?
> >
> >Cheers, D
> >
> >On Thu, 29 Jun 2023 at 21:46, Ivan Krylov  wrote:
> >
> >> On Thu, 29 Jun 2023 20:22:47 +0100
> >> David Hugh-Jones  wrote:
> >>
> >> > I'm looking for a source of online help for R base
> >> > packages, which covers all versions (for some reasonable value of
> >> > "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
> >>
> >> These live in the R source tree, under src/library:
> >> https://svn.r-project.org/R/trunk/src/library/
> >>
> >> For the actual releases of R, you may have to go looking at the
> >> branches inside that repository, e.g., the following command:
> >>
> >> svn log \
> >>
> >>
> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
> >>
> >> ...should tell you the history of ?lm until the latest R-4.1-patched.
> >>
> >> Do the Git mirrors track these release branches? The branching model of
> >> Subversion [*] is different from the Git model, so perhaps not.
> >>
> >> --
> >> Best regards,
> >> Ivan
> >>
> >> [*] https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
> >>
>
> --
> Sent from my phone. Please excuse my brevity.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

That’s useful to know. But is there anywhere with preformatted HTML pages?

Cheers, D

On Thu, 29 Jun 2023 at 21:46, Ivan Krylov  wrote:

> On Thu, 29 Jun 2023 20:22:47 +0100
> David Hugh-Jones  wrote:
>
> > I'm looking for a source of online help for R base
> > packages, which covers all versions (for some reasonable value of
> > "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
>
> These live in the R source tree, under src/library:
> https://svn.r-project.org/R/trunk/src/library/
>
> For the actual releases of R, you may have to go looking at the
> branches inside that repository, e.g., the following command:
>
> svn log \
>
> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
>
> ...should tell you the history of ?lm until the latest R-4.1-patched.
>
> Do the Git mirrors track these release branches? The branching model of
> Subversion [*] is different from the Git model, so perhaps not.
>
> --
> Best regards,
> Ivan
>
> [*] https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] Public URLs for help for versions of base packages

[David Hugh-Jones]

Dear R packagers,

This isn't strictly about packaging but I thought you guys might have the
most relevant expertise. I'm looking for a source of online help for R base
packages, which covers all versions (for some reasonable value of "all").
So e.g. the equivalent of `?lm` for R 4.1.0.
Is there any web page for that? Better still, an "official" source? I have
been using rdocumentation.org but it hasn't updated for a while.

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Acknowledging small functions from another package

[David Hugh-Jones]

Thank you both. This sounds sensible. Yeah, add my vote for `base::%||%`!!


David


On Thu, 4 May 2023 at 10:00, Duncan Murdoch 
wrote:

> On 04/05/2023 4:53 a.m., Ivan Krylov wrote:
> > On Thu, 4 May 2023 09:21:17 +0100
> > David Hugh-Jones  wrote:
> >
> >> One of my packages copy-pasted some small functions (stuff like
> >> `%||%` for is.null) from ggplot2. (Both packages are MIT-licensed.)
> >>
> >> What is an appropriate way to acknowledge this in the DESCRIPTION
> >> Author: or Authors@R section?
> >
> > One way would be to mention Hadley Wickham:
> >
> https://github.com/tidyverse/ggplot2/commit/ef2f944863a0db8841bf628e9eb4a9faef5049e6#diff-8f53135445ab98749043fa52e438346bb9acae8e0185aa95f186d0aa021bb7e0
> > (`git blame` will also tell you that he later moved this function to a
> > different file).
> >
> > I think that person('ggplot2 authors', role = 'cph', comment = 'The
> > %||% operator') is also fine, just like e.g. unitizer package mentions
> > the code taken from R itself.
> >
> > You can also find this operator in multiple base R packages, currently
> > unexported (maybe some day...). They mention in the comments that the
> > operator is adapted from ggplot2.
>
> I'd probably use role = "ctb" instead for "ggplot2 authors", and include
> Posit PBC as a copyright holder (as ggplot2 does).  Presumably you or
> others are also copyright holders for your package and should also have
> role = "cph" added so it doesn't give the impression that Posit owns
> everything.
>
> Duncan Murdoch
>
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Acknowledging small functions from another package

[David Hugh-Jones]

Hi,

One of my packages copy-pasted some small functions (stuff like `%||%` for
is.null) from ggplot2. (Both packages are MIT-licensed.)

What is an appropriate way to acknowledge this in the DESCRIPTION Author:
or Authors@R section? (Note that the list of ggplot2 authors is long and
changing.)

Cheers,
David

[[alternative HTML version deleted]]

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

[R-pkg-devel] FAQ

[David Hugh-Jones]

Hi all,

I see some questions coming up repeatedly here…. Would it help to have a
FAQ to point at?
I’d be happy to help though I’m no expert.

Cheers,
David
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] FW: Writing to users config directory for CRAN package

[David Hugh-Jones]

Thank you both. I guess the package can dog food itself by asking one time
whether it can store its files.
D



On Sun, 6 Nov 2022 at 06:33, Jonathan Godfrey 
wrote:

>
> Further to Dirk's advice, my BrailleR package creates a folder (dumping
> ground). Users are asked if they want to use  one of my choosing, or a
> temporary one. If they choose temporary, they get asked again and again
> until they cave in to my wishes!
>
>
> BrailleR also writes files to the current working directory, but these are
> done because the user has chosen to run a command that has the purpose of
> creating files. I put a warning in the documentation for such functions.
>
> I'm not suggesting my solution is the gold standard, but it is working
> well enough to keep the CRAN checkers happy.
>
> Jonathan
>
>
> -Original Message-
> From: R-package-devel  On Behalf
> Of Dirk Eddelbuettel
> Sent: Sunday, 6 November 2022 9:29 am
> To: David Hugh-Jones 
> Cc: R package devel 
> Subject: Re: [R-pkg-devel] Writing to users config directory for CRAN
> package
>
>
> On 5 November 2022 at 19:32, David Hugh-Jones wrote:
> | I'm considering submitting the package onetime (
> |
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhughjonesd%2Fonetime%2Fdata=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864581576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=EbBh9XCyyKsRTACo7eLxASZW3pm%2BTrXxzKjjnxBa%2Fpo%3Dreserved=0)
> to CRAN.
> |
> | Onetime has functions for showing a message or warning only once (ever
> | per user). It does this by writing to a file in the user's
> | configuration directory, as reported by rappdirs::user_config_dir().
>
> There is a base R function tools::R_user_dir() which I use in a few
> packages along with packageName() to store config information across
> sessions. A quick search at GitHub's 'cran' org mirroring CRAN finds 110
> hits:
>
>
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Dorg%253Acran%2BR_user_dir%26type%3Dcodedata=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864737810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Wlqbm0tZX0h25rm0veh%2F15IAwJ5mqP9VNPUovlaPhdY%3Dreserved=0
>
> You could keep a hashmap in that directory, and maybe (before it has been
> written a first time) alert the user that you cannot write without
> (initial) permission.  As I recall, the idea behind the (sensible) CRAN
> Policy is to not litter user directories with random files with the user
> knowing.
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
>
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864737810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kB8nHrtC5yGEm4tnOTZDOAGT%2FmtDViGblNvieFlZq7g%3Dreserved=0
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] Writing to users config directory for CRAN package

[David Hugh-Jones]

Hi,

I'm considering submitting the package onetime (
https://github.com/hughjonesd/onetime/) to CRAN.

Onetime has functions for showing a message or warning only once (ever per
user). It does this by writing to a file in the user's configuration
directory, as reported by rappdirs::user_config_dir().

I know that CRAN has rules about not writing to the user's file system
without permission. What would be an appropriate way to do this? For
example, the function onetime_message_confirm() prints a message and then
asks "Show this again?[yN]" Would a "no" count as permission to write the
file?

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [Rd] anonymous functions

[David Hugh-Jones]

I will stick my oar in here as a user to say that I find the \(x) syntax a bit 
line-noise-ish. 

David

> On 8 Dec 2020, at 00:05, Abby Spurdle  wrote:
> 
> Sorry, I should replace "cryptic-ness" from my last post, with
> "unnecessary cryptic-ness".
> Sometimes short symbolic expressions are necessary.
> 
> 
> P.S.
> Often, I wish I could write: f (x) = x^2.
> But that's replacement function syntax.
> 
> 
>> On Tue, Dec 8, 2020 at 11:56 AM Abby Spurdle  wrote:
>> 
>> I mostly agree with your comments on anonymous functions.
>> 
>> However, I think the main problem is cryptic-ness, rather than succinct-ness.
>> The backslash is a relatively universal symbol within programming
>> languages with C-like (ALGOL-like?) syntax.
>> Where it denotes escape sequences within strings.
>> 
>> Using the leading character for escape sequences, to define functions,
>> is like using integers to define floating point numbers:
>> 
>>my.integer <- as.integer (2) * pi
>> 
>> Arguably, the motive is more to be ultra-succinct than cryptic.
>> But either way, we get syntax which is difficult to read, from a
>> mathematical and statistical perspective.
>> 
>> 
>>> On Tue, Dec 8, 2020 at 6:04 AM Therneau, Terry M., Ph.D. via R-devel
>>>  wrote:
>>> 
>>> “The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be 
>>> helpful in making
>>> code containing simple function expressions more readable.”
>>> 
>>> Color me unimpressed.
>>> Over the decades I've seen several "who can write the shortest code" 
>>> threads: in Fortran,
>>> in C, in Splus, ...   The same old idea that "short" is a synonym for 
>>> either elegant,
>>> readable, or efficient is now being recylced in the tidyverse.   The truth 
>>> is that "short"
>>> is actually an antonym for all of these things, at least for anyone else 
>>> reading the code;
>>> or for the original coder 30-60 minutes after the "clever" lines were 
>>> written.  Minimal
>>> use of the spacebar and/or the return key isn't usually held up as a goal, 
>>> but creeps into
>>> many practiioner's code as well.
>>> 
>>> People are excited by replacing "function(" with "\("?  Really?   Are 
>>> people typing code
>>> with their thumbs?
>>> I am ambivalent about pipes: I think it is a great concept, but too many of 
>>> my colleagues
>>> think that using pipes = no need for any comments.
>>> 
>>> As time goes on, I find my goal is to make my code less compact and more 
>>> readable.  Every
>>> bug fix or new feature in the survival package now adds more lines of 
>>> comments or other
>>> documentation than lines of code.  If I have to puzzle out what a line 
>>> does, what about
>>> the poor sod who inherits the maintainance?
>>> 
>>> 
>>> --
>>> Terry M Therneau, PhD
>>> Department of Health Science Research
>>> Mayo Clinic
>>> thern...@mayo.edu
>>> 
>>> "TERR-ree THUR-noh"
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [R-pkg-devel] How long to wait before resending response to CRAN

[David Hugh-Jones]

So if I reply all, do they not reply back?

David


On Thu, 17 Sep 2020 at 21:39, Max Turgeon  wrote:

> Hi David,
>
> I think you'll need to resubmit, because your package is now in the
> archive folder. You can check this by running 'foghorn::cran_incoming(pkg
> = "huxtable")'.
>
> But you probably want to address these NOTES during your resubmission,
> otherwise you're likely to face the same outcome.
>
> Cheers,
>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
>
> ------
> *From:* R-package-devel  on behalf
> of David Hugh-Jones 
> *Sent:* Thursday, September 17, 2020 2:55 PM
> *To:* R package devel 
> *Subject:* [R-pkg-devel] How long to wait before resending response to
> CRAN
>
> 
> Caution: This message was sent from outside the University of Manitoba.
> 
>
> Hi all,
>
> I submitted a package update to CRAN (package "huxtable") and got a couple
> of NOTES and the usual message about replying-all if I thought the NOTES
> were false positives. Rightly or wrongly, I did think this, so I replied
> all with my explanation. This was a week ago. I have not yet heard back.
> How long ought I to wait before replying again with a nudge or follow-up?
>
> Cheers,
> David
>
> [[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

[R-pkg-devel] How long to wait before resending response to CRAN

[David Hugh-Jones]

Hi all,

I submitted a package update to CRAN (package "huxtable") and got a couple
of NOTES and the usual message about replying-all if I thought the NOTES
were false positives. Rightly or wrongly, I did think this, so I replied
all with my explanation. This was a week ago. I have not yet heard back.
How long ought I to wait before replying again with a nudge or follow-up?

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[David Hugh-Jones]

Thank you so much!
David


On Tue, 16 Jun 2020 at 08:36, Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:

> The Rd file is mplus.Rd, so
>  ‘[lubridate:mplus]{lubridate::add_with_rollback()}’ would do.
>
> Georgi Boshnakov
>
> -Original Message-
> From: R-package-devel  On Behalf
> Of David Hugh-Jones
> Sent: 16 June 2020 07:51
> To: Duncan Murdoch 
> Cc: List r-package-devel 
> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> package-anchored link(s)
>
> On this note, I just got
>
> Non-file package-anchored link(s) in documentation object
> 'brk_width-for-datetime.Rd':
>   ‘[lubridate:%m+%]{lubridate::add_with_rollback()}’
>
> The correct filename appears to be %m+% in the lubridate help. Can anyone
> tell me the right way to format this? I would work it out myself, but the
> check didn't cause problems on the r-devel systems I tested with, so I'd be
> testing blind.
>
> Cheers,
> David
>
>
> On Mon, 15 Jun 2020 at 17:30, Duncan Murdoch 
> wrote:
>
> > On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> > >
> > >  > I agree with almost everything you wrote, except one thing:
> > > this
> > isn't
> > >  > newly enforced, it has been enforced since the help system
> > began.  What
> > >  > I think is new is that there are now tests for it.
> > > Previously
> > those
> > >  > links just wouldn't work.
> > >
> > >  > Duncan Murdoch
> > >
> > > Yes, to all... including Duncan's agreement with Gábor.
> > >
> > > Also, Duncan M earlier did mention that he had wanted to
> > > *change* the link-to-file behavior for these cases (when he wrote
> > > most of the Rd2html source code) but somehow did not get it.
> >
> > Actually, I don't think I pushed for this change at the time (or at
> > least I didn't push much).  I just wish now that I had, because I
> > think it will be harder to do it now than it would have been then.
> >
> > Duncan
> >
> > >
> > > And that's why we had partial workarounds (as the dynamic server
> > > still finding the links under some circumstances).
> > >
> > > My personal opinions was also that "we" (the R community; i.e.,
> > > people providing good patches to the R sources / collaborating with
> > > R core / ...) should rather work to fix the current
> > > design/implementation "infelicity" than the current checks starting
> > > to enforce something which is really a wart in my view, and indeed,
> > > as Gábor also notes, will create R source documentation that depends
> > > on implementation details of other package's documentation.
> > > I don't like it either, not at all.
> > >
> > > Martin
> > >
> > >  > On 14/06/2020 6:26 a.m., Gábor Csárdi wrote:
> > >  >> On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
> > >  >>  wrote:
> > >  >> [...]
> > >  >>>
> > >  >>> I think the argument was that static builds of the help
> > > pages
> > would have
> > >  >>> trouble resolving the links.  With the current system, you
> > > can
> > build a
> > >  >>> help page that links to a page in package foo even if
> > > package
> > foo is not
> > >  >>> installed yet, and have the link work later after you
> > > install
> > foo.
> > >  >>
> > >  >> That is true, but it is also not a big problem, I think. The
> CRAN
> > >  >> Windows R installer does indeed build static help pages by
> > default.
> > >  >> But the built-in web server that serves these works around
> broken
> > >  >> links by treating them as help topics instead of files. As
> > > you
> > know.
> > >  >> :) So this would only be a problem if you wanted to serve
> > > the
> > static
> > >  >> help pages with another web server. (Which is not a bad use
> > case, but
> > >  >> then maybe Rd2HTML() can just resolve them as topics and
> > > avoid
> > the
> > >  >> broken links.)
> > >  >>
> > >  >> Btw. the problem of linking to the wrong page is even worse
> with
> > >  >> static builds of help pages, 

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[David Hugh-Jones]

On this note, I just got

Non-file package-anchored link(s) in documentation object
'brk_width-for-datetime.Rd':
  ‘[lubridate:%m+%]{lubridate::add_with_rollback()}’

The correct filename appears to be %m+% in the lubridate help. Can anyone
tell me the right way to format this? I would work it out myself, but the
check didn't cause problems on the r-devel systems I tested with, so I'd be
testing blind.

Cheers,
David


On Mon, 15 Jun 2020 at 17:30, Duncan Murdoch 
wrote:

> On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> >> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> >
> >  > I agree with almost everything you wrote, except one thing:  this
> isn't
> >  > newly enforced, it has been enforced since the help system
> began.  What
> >  > I think is new is that there are now tests for it.  Previously
> those
> >  > links just wouldn't work.
> >
> >  > Duncan Murdoch
> >
> > Yes, to all... including Duncan's agreement with Gábor.
> >
> > Also, Duncan M earlier did mention that he had wanted to
> > *change* the link-to-file behavior for these cases (when he
> > wrote most of the Rd2html source code) but somehow did not get it.
>
> Actually, I don't think I pushed for this change at the time (or at
> least I didn't push much).  I just wish now that I had, because I think
> it will be harder to do it now than it would have been then.
>
> Duncan
>
> >
> > And that's why we had partial workarounds (as the dynamic server
> > still finding the links under some circumstances).
> >
> > My personal opinions was also that "we" (the R community; i.e.,
> > people providing good patches to the R sources / collaborating
> > with R core / ...) should rather work to fix the current
> > design/implementation "infelicity" than the current checks
> > starting to enforce something which is really a wart in my view,
> > and indeed, as Gábor also notes, will create R source
> > documentation that depends on implementation details of other
> > package's documentation.
> > I don't like it either, not at all.
> >
> > Martin
> >
> >  > On 14/06/2020 6:26 a.m., Gábor Csárdi wrote:
> >  >> On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
> >  >>  wrote:
> >  >> [...]
> >  >>>
> >  >>> I think the argument was that static builds of the help pages
> would have
> >  >>> trouble resolving the links.  With the current system, you can
> build a
> >  >>> help page that links to a page in package foo even if package
> foo is not
> >  >>> installed yet, and have the link work later after you install
> foo.
> >  >>
> >  >> That is true, but it is also not a big problem, I think. The CRAN
> >  >> Windows R installer does indeed build static help pages by
> default.
> >  >> But the built-in web server that serves these works around broken
> >  >> links by treating them as help topics instead of files. As you
> know.
> >  >> :) So this would only be a problem if you wanted to serve the
> static
> >  >> help pages with another web server. (Which is not a bad use
> case, but
> >  >> then maybe Rd2HTML() can just resolve them as topics and avoid
> the
> >  >> broken links.)
> >  >>
> >  >> Btw. the problem of linking to the wrong page is even worse with
> >  >> static builds of help pages, because if a link w/o a package
> (e.g.
> >  >> \link{filter}) picks up the wrong package at install time, then
> the
> >  >> wrong link is hard-coded in the html. If you are building binary
> >  >> packages, then they will link to the wrong help pages.
> >  >>
> >  >> WRE says that specifying the package in the link is rarely
> needed.
> >  >> This was probably the case some time ago, especially when
> packages did
> >  >> not have (compulsory) namespaces. But I am not sure if it still
> holds.
> >  >> I would argue that it is better to specify the package you are
> linking
> >  >> to. But the newly enforced requirement that we need to link to
> files
> >  >> instead of topics makes this more error prone.
> >  >>
> >  >> Gabor
> >  >>
> >  >> [...]
> >
>
> __
> 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: [R-pkg-devel] Including fonts in an rmarkdown vignette

[David Hugh-Jones]

Thank you for these suggestions. Google fonts sounds like quite an easy
approach.
David


On Wed, 3 Jun 2020 at 10:03, David Gohel  wrote:

> David
>
> If you are ok to use one of the fonts available on google font, you could
> use package gfonts (in Suggests):
> https://cran.r-project.org/web/packages/gfonts/vignettes/gfonts.html
>
> As it will be « inline », your document size could inflate (I guess it
> could be an issue with CRAN) - if only one font, size should be ok.
>
> Otherwise, you also could add a css chunk to import the font from a public
> server - if no internet connexion, nothing will break.
>
> David
>
>
> Le 3 juin 2020 à 08:46, Maëlle SALMON via R-package-devel <
> r-package-devel@r-project.org> a écrit :
>
> Hi,
>
> I've recently seen an example of a package that provides its own fonts for
> a vignette. See links in
> https://blog.r-hub.io/2020/06/03/vignettes/#pretty-vignettes
>
>
> In that same post I link to a workaround I saw on this list
> https://www.mail-archive.com/r-package-devel@r-project.org/msg02921.html
> for changing the vignette format based on the versions of dependencies.
> Maybe something similar is possible for fonts (I have no idea).
>
> Maëlle.
>
> Den tisdag 2 juni 2020 20:14:24 CEST, David Hugh-Jones <
> davidhughjo...@gmail.com> skrev:
>
>
>
>
>
> Hi,
>
> I'd like to build a rmarkdown vignette with my own choice of fonts – I'm
> pernickety about look and feel.
>
> R CMD check will rebuild vignettes in the vignettes/ directory, and if
> relevant fonts aren't on the build machine, it'll give a warning.
>
> Here are the options I can think of:
> * build vignettes on my machine and put them in inst/doc. Don't mention the
> specific fonts in the Rmd file in vignettes/. So the file built by "R CMD
> check" won't look quite like the pre-built version.  This might work, but
> it seems against open source principle.
> * put font files in vignettes/ and refer to them in the rmarkdown file. I'm
> not sure how to do this.
> * limit myself to the fonts preinstalled on win-builder or CRAN machines.
> I'm not sure what these are
>
> Has anyone got any advice or examples?
>
> Cheers,
> David
>
> [[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
>
>
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Including fonts in an rmarkdown vignette

[David Hugh-Jones]

Hi,

I'd like to build a rmarkdown vignette with my own choice of fonts – I'm
pernickety about look and feel.

R CMD check will rebuild vignettes in the vignettes/ directory, and if
relevant fonts aren't on the build machine, it'll give a warning.

Here are the options I can think of:
* build vignettes on my machine and put them in inst/doc. Don't mention the
specific fonts in the Rmd file in vignettes/. So the file built by "R CMD
check" won't look quite like the pre-built version.  This might work, but
it seems against open source principle.
* put font files in vignettes/ and refer to them in the rmarkdown file. I'm
not sure how to do this.
* limit myself to the fonts preinstalled on win-builder or CRAN machines.
I'm not sure what these are

Has anyone got any advice or examples?

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] slightly polemic question re R CMD check

[David Hugh-Jones]

I see the logic, but it seems in practice people often write specific
methods with their own specific arguments. (Think of the many plot or print
methods for different objects, for example.) Here, enforcing a ... argument
does not buy us much. All that we really need is that plot(x) will work for
many classes of x. Beyond that, we expect users to read the method-specific
documentation.

Maybe this is an antipattern. It just seems that S3 methods have turned out
to be often used that way. Enforcing ... hasn't stopped it, and causes some
awkwardnesses in documentation and error checking. To be clear, I'm not
arguing against the generic having flexibility. I'm arguing against
enforcing that the method always accepts every argument that the generic
could accept.




On Sun, 8 Mar 2020, 17:14 Jeff Newmiller,  wrote:

> R encourages the use of ... particularly in S3 generics, to avoid
> over-depending on inheritance to enable flexible use of these generics.
> That is, when you call the generic without knowing which class you are
> giving it, you cannot specify class-specific arguments. However, some
> methods have obvious alternative class-specific behaviors that are
> typically enabled using class-specific arguments (e.g. plot). You cannot
> support both fully-generic calls and class-specific calls without giving
> the generic some flexibility that won't get used in some cases.
>
>
> On March 8, 2020 9:41:51 AM PDT, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
> >Hi Jeff,
> >
> >I wouldn't say R encourages that in general. Non-generic functions will
> >throw an error if you use a non-existent argument. And some generic
> >functions check for it:
> >
> >seq(1, 3, blah = 1)
> >[1] 1 2 3
> >Warning message:
> >In seq.default(1, 3, blah = 1) :
> > extra argument ‘blah’ will be disregarded
> >
> >In fact there is even a `chkDots()` function to help with this - which,
> >despite having used R or 17 years, I first discovered today :-). So, it
> >seems the R base developers thought lenient argument checking could be
> >a
> >bad thing, presumably because it lets errors go undetected.
> >
> >Maybe chkDots is a reasonable workaround. But I wonder what the
> >rationale
> >is for R CMD check enforcing that methods *must* be as lenient as the
> >generic. It seems to lead to a lot of documentation of the form:
> >
> >@param ... Not used.
> >
> >Cheers,
> >David
> >
> >
> >On Sun, 8 Mar 2020 at 16:24, Jeff Newmiller 
> >wrote:
> >
> >> You seem to think this is a bad thing. R does encourage lenient
> >argument
> >> checking... what rock have you been under for the last 20 years?
> >>
> >> On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones <
> >> davidhughjo...@gmail.com> wrote:
> >> >You're quite right :-) But I think the polemic still holds, because
> >I
> >> >have
> >> >to add manual argument checking to all my methods, which has a cost
> >in
> >> >lines of code. Indeed, few base R methods have chosen to do this. In
> >> >effect, the current setup encourages writing methods with "lenient"
> >> >argument specifications.
> >> >
> >> >Thank you for the suggestion about ellipsis.
> >> >
> >> >On Sun, 8 Mar 2020, 11:04 Gábor Csárdi, 
> >wrote:
> >> >
> >> >> You can add the ... argument to chop.default(), and then check
> >that
> >> >> length(list(...)) is zero.
> >> >>
> >> >> Also, you might be interested in the ellipsis package.
> >> >>
> >> >> Gabor
> >> >>
> >> >> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
> >> >>  wrote:
> >> >> >
> >> >> > Hi all,
> >> >> >
> >> >> > My package defines the following method and generic:
> >> >> >
> >> >> > chop <- function (x, ...) UseMethod("chop")
> >> >> >
> >> >> > chop.default <- function (x, breaks, labels, extend = NULL, drop
> >=
> >> >TRUE)
> >> >> {
> >> >> > ... }
> >> >> >
> >> >> > R CMD check then gives a warning:
> >> >> >
> >> >> > W  checking S3 generic/method consistency (695ms)
> >> >> >chop:
> >> >> >  function(x, ...)
> >> >> >chop.default:
> >> >> >  function(x, breaks, labels, extend, 

Re: [R-pkg-devel] slightly polemic question re R CMD check

[David Hugh-Jones]

Hi Jeff,

I wouldn't say R encourages that in general. Non-generic functions will
throw an error if you use a non-existent argument. And some generic
functions check for it:

seq(1, 3, blah = 1)
[1] 1 2 3
Warning message:
In seq.default(1, 3, blah = 1) :
 extra argument ‘blah’ will be disregarded

In fact there is even a `chkDots()` function to help with this - which,
despite having used R or 17 years, I first discovered today :-). So, it
seems the R base developers thought lenient argument checking could be a
bad thing, presumably because it lets errors go undetected.

Maybe chkDots is a reasonable workaround. But I wonder what the rationale
is for R CMD check enforcing that methods *must* be as lenient as the
generic. It seems to lead to a lot of documentation of the form:

@param ... Not used.

Cheers,
David


On Sun, 8 Mar 2020 at 16:24, Jeff Newmiller 
wrote:

> You seem to think this is a bad thing. R does encourage lenient argument
> checking... what rock have you been under for the last 20 years?
>
> On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
> >You're quite right :-) But I think the polemic still holds, because I
> >have
> >to add manual argument checking to all my methods, which has a cost in
> >lines of code. Indeed, few base R methods have chosen to do this. In
> >effect, the current setup encourages writing methods with "lenient"
> >argument specifications.
> >
> >Thank you for the suggestion about ellipsis.
> >
> >On Sun, 8 Mar 2020, 11:04 Gábor Csárdi,  wrote:
> >
> >> You can add the ... argument to chop.default(), and then check that
> >> length(list(...)) is zero.
> >>
> >> Also, you might be interested in the ellipsis package.
> >>
> >> Gabor
> >>
> >> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
> >>  wrote:
> >> >
> >> > Hi all,
> >> >
> >> > My package defines the following method and generic:
> >> >
> >> > chop <- function (x, ...) UseMethod("chop")
> >> >
> >> > chop.default <- function (x, breaks, labels, extend = NULL, drop =
> >TRUE)
> >> {
> >> > ... }
> >> >
> >> > R CMD check then gives a warning:
> >> >
> >> > W  checking S3 generic/method consistency (695ms)
> >> >chop:
> >> >  function(x, ...)
> >> >chop.default:
> >> >  function(x, breaks, labels, extend, drop)
> >> >
> >> >See section ‘Generic functions and methods’ in the ‘Writing R
> >> >Extensions’ manual.
> >> >
> >> > I can fix this by adding a ... argument to chop.default:
> >> >
> >> > chop.default <- function (x, breaks, labels, extend = NULL, drop =
> >> > TRUE, ...)
> >> >
> >> > But that makes the code less robust because e.g.
> >> >
> >> > chop(x, Breaks = 1:3)
> >> >
> >> > will no longer throw an error from the misspelled argument.
> >> >
> >> > Or I can write:
> >> >
> >> > chop(x, breaks, labels, extend, drop) UseMethod("chop")
> >> >
> >> > but this means I cannot use a different interface for a different
> >method.
> >> >
> >> > This seems like a mistake. (That's the polemic.) Or am I missing a
> >better
> >> > way? (That's the question.)
> >> >
> >> > David
> >> >
> >> > [[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
>
> --
> Sent from my phone. Please excuse my brevity.
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] slightly polemic question re R CMD check

[David Hugh-Jones]

You're quite right :-) But I think the polemic still holds, because I have
to add manual argument checking to all my methods, which has a cost in
lines of code. Indeed, few base R methods have chosen to do this. In
effect, the current setup encourages writing methods with "lenient"
argument specifications.

Thank you for the suggestion about ellipsis.

On Sun, 8 Mar 2020, 11:04 Gábor Csárdi,  wrote:

> You can add the ... argument to chop.default(), and then check that
> length(list(...)) is zero.
>
> Also, you might be interested in the ellipsis package.
>
> Gabor
>
> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
>  wrote:
> >
> > Hi all,
> >
> > My package defines the following method and generic:
> >
> > chop <- function (x, ...) UseMethod("chop")
> >
> > chop.default <- function (x, breaks, labels, extend = NULL, drop = TRUE)
> {
> > ... }
> >
> > R CMD check then gives a warning:
> >
> > W  checking S3 generic/method consistency (695ms)
> >chop:
> >  function(x, ...)
> >chop.default:
> >  function(x, breaks, labels, extend, drop)
> >
> >See section ‘Generic functions and methods’ in the ‘Writing R
> >Extensions’ manual.
> >
> > I can fix this by adding a ... argument to chop.default:
> >
> > chop.default <- function (x, breaks, labels, extend = NULL, drop =
> > TRUE, ...)
> >
> > But that makes the code less robust because e.g.
> >
> > chop(x, Breaks = 1:3)
> >
> > will no longer throw an error from the misspelled argument.
> >
> > Or I can write:
> >
> > chop(x, breaks, labels, extend, drop) UseMethod("chop")
> >
> > but this means I cannot use a different interface for a different method.
> >
> > This seems like a mistake. (That's the polemic.) Or am I missing a better
> > way? (That's the question.)
> >
> > David
> >
> > [[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

[R-pkg-devel] slightly polemic question re R CMD check

[David Hugh-Jones]

Hi all,

My package defines the following method and generic:

chop <- function (x, ...) UseMethod("chop")

chop.default <- function (x, breaks, labels, extend = NULL, drop = TRUE) {
... }

R CMD check then gives a warning:

W  checking S3 generic/method consistency (695ms)
   chop:
 function(x, ...)
   chop.default:
 function(x, breaks, labels, extend, drop)

   See section ‘Generic functions and methods’ in the ‘Writing R
   Extensions’ manual.

I can fix this by adding a ... argument to chop.default:

chop.default <- function (x, breaks, labels, extend = NULL, drop =
TRUE, ...)

But that makes the code less robust because e.g.

chop(x, Breaks = 1:3)

will no longer throw an error from the misspelled argument.

Or I can write:

chop(x, breaks, labels, extend, drop) UseMethod("chop")

but this means I cannot use a different interface for a different method.

This seems like a mistake. (That's the polemic.) Or am I missing a better
way? (That's the question.)

David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Alternatives to R-devel on a Mac for package checking?

[David Hugh-Jones]

The other obvious online checker is rhub, via the rhub package.
David


On Wed, 15 Jan 2020 at 21:39, Jonathan Greenberg  wrote:

> One of the issues I'm running into is that it seems every time there's a
> Mac update something gets broken with regards to compilers, making it
> incredibly challenging to get the development install of R working with
> Rcpp (which is a requirement for the packages I need to use to check my
> packages).
>
> I'd like to start moving towards an easier approach rather than spending
> days fixing various issues on my Mac just to run a simple --as-cran check
> on a package with the latest  r-devel.  I was HOPING there is an up-to-date
> Docker for the r-development 4.0 version out in the wild, but it seems like
> the rocker r-devel is just 3.6.2.  Any ideas?
>
> docker run --rm -ti rocker/r-devel
>
> Alternatively, are there any decent online checkers (except the CRAN
> ones)?  r-forge seems to not do r-devel checks anymore.
>
> --j
>
> [[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: [R-pkg-devel] What counts as an API change?

[David Hugh-Jones]

Thanks Jeff. My function is currently:

insert_column <- function (ht, ..., after = 0, copy_cell_props = TRUE)

and I want to add a `fill` argument:

insert_column <- function (ht, ..., after = 0, fill = NULL, copy_cell_props
= TRUE)

This is definitely the best place for the fill argument - I wouldn't like
to put it after copy_cell_props.

Actually, thinking about it, both after and copy_cell_props have to be
named arguments, given the position of ... . So maybe this is my get out of
jail free card. If I add "fill", existing function calls won't break, and I
can call this "adding functionality in a backwards-compatible manner".

David


On Wed, 25 Sep 2019 at 17:26, Jeff Newmiller 
wrote:

> "assume default values are provided."
>
> Ah, no. Choosing to specify or not specify default values is a critical
> step. As is deciding where any ... argument will be placed (all specific
> arguments after that have to be named when called so positional
> compatibility cannot come back to bite you).
>
> "I wonder if it always matters"
>
> That would depend on the relationship you plan to maintain with users of
> your package. Still, sometimes breaking changes are necessary for a better
> future.
>
> I think the definition of breaking is pretty clear if you are precise in
> your argument lists. (R CMD check is very helpful in pestering you to
> document your arguments, so you do have the opportunity to be precise in
> your API definition.) It is really bad to have silent changes in behavior,
> and precision in specification is crucial to avoid that if you distribute
> packages.
>
> On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
> >Hi Jeff,
> >
> >You're right. Indeed, assume default values are provided. I should have
> >been more precise.
> >
> >I understand that the positional behaviour has changed. But I wonder if
> >it
> >always matters. OTOH I appreciate the force of the idea that an API
> >change
> >is an API change, and should be defined precisely.
> >
> >Best,
> >David
> >
> >
> >On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller 
> >wrote:
> >
> >> Both of your examples are incompatible.
> >>
> >> foo <- function (a, b, c, d, e = NA )
> >>
> >> (add with default value) would be compatible.
> >>
> >> Your second example cannot be made compatible even with default
> >values
> >> because the positional behaviour has changed.
> >>
> >> On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
> >> davidhughjo...@gmail.com> wrote:
> >> >Hi all,
> >> >
> >> >Philosophical question. My package follows semantic versioning (
> >> >https://semver.org). Incompatible API changes should trigger a major
> >> >version upgrade. OK, but what counts as an incompatible change to an
> >R
> >> >API?
> >> >Suppose my current function signature is
> >> >
> >> >foo <- function (a, b, c, d)
> >> >
> >> >and the new one is
> >> >
> >> >foo <- function (a, b, c, d, e)
> >> >
> >> >is that compatible? What if I add an argument, but not at the end:
> >> >
> >> >foo <- function (a, b, c, e, d)
> >> >
> >> >That would be incompatible if people have been calling the arguments
> >by
> >> >order rather than by name. But sometimes that is unlikely: I doubt
> >if
> >> >many
> >> >people write
> >> >
> >> >lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
> >> >FALSE)
> >> >
> >> >Should I be strict or relaxed about this?
> >> >
> >> >Cheers,
> >> >David
> >> >
> >> >   [[alternative HTML version deleted]]
> >> >
> >> >__
> >> >R-package-devel@r-project.org mailing list
> >> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> --
> >> Sent from my phone. Please excuse my brevity.
> >>
>
> --
> Sent from my phone. Please excuse my brevity.
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] What counts as an API change?

[David Hugh-Jones]

Hi all,

Philosophical question. My package follows semantic versioning (
https://semver.org). Incompatible API changes should trigger a major
version upgrade. OK, but what counts as an incompatible change to an R API?
Suppose my current function signature is

foo <- function (a, b, c, d)

and the new one is

foo <- function (a, b, c, d, e)

is that compatible? What if I add an argument, but not at the end:

foo <- function (a, b, c, e, d)

That would be incompatible if people have been calling the arguments by
order rather than by name. But sometimes that is unlikely: I doubt if many
people write

lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE, FALSE)

Should I be strict or relaxed about this?

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Require -package.Rd?

[David Hugh-Jones]

I would be in favour. I actually used R for several years before figuring
out that the vignette was usually where the useful introduction was. Until
then I was like “R help is way too technical”

On Tue, 24 Sep 2019 at 13:26, Joris Meys  wrote:

> Dear Dr. Vichtbauer,
>
> I'm not a CRAN member, but I personally think this is a sensible
> requirement. I try to include those in every package myself, even if it's
> only to direct people to a vignette.
>
> That said, I do look for vignettes first when I encounter an unfamiliar
> package actually. That format gives more possibilities for giving a good
> introduction to the package imho.
>
> My humble 2 cents
> Cheers
> Joris
>
> On Tue, Sep 24, 2019 at 2:17 PM Viechtbauer, Wolfgang (SP) <
> wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
>
> > Hi All,
> >
> > When starting to work with an unfamiliar package, one might typically
> look
> > for vignettes, a paper/book accompanying the package, a package website,
> > and of course the help files themselves, but
> >
> > help(package="")
> >
> > is often not so useful -- such a listing of functions (with titles) might
> > not clarify what the main 'workhorses' of the package are and how to get
> > started. Personally, the first thing I do is try:
> >
> > help()
> >
> > in the hopes that the package author(s) have created a
> > -package.Rd file to get new users started (or to point them to
> > appropriate places to get going). In my experience, if such a package
> help
> > file is available, it is tremendously useful.
> >
> > Unfortunately, many packages do not provide a -package.Rd file.
> I
> > am curious how others and CRAN members would feel about making this a
> > requirement (not retrospectively, but at least for new / resubmissions).
> >
> > Best,
> > Wolfgang
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to submit to CRAN from GitHub?

[David Hugh-Jones]

If you click on the “check” log in travis, you will find:

* checking data for ASCII and uncompressed saves ... WARNING
1411
1412 Note: significantly better compression could be obtained
1413 by using R CMD build --resave-data


(Excuse the poor formatting – posting from my phone.)

This suggests you need to compress your data (there may be a usethis::
function to do this also).

There’s no especial way to submit from GitHub, though I find the approach
taken by devtools::release() to be quite helpful.

D

On Sun, 22 Sep 2019 at 19:33, Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

> Hello:
>
>
>Two questions:
>
>
> HOW TO SUBMIT TO CRAN FROM GITHUB:  Is there a standard method for
> submitting to CRAN from GitHub?  (There's a simple protocol for
> submitting to CRAN from R-Forge, but I've experienced insurmountable
> problems using R-Forge recently.)
>
>
> PACKAGE STILL FAILING TRAVIS CI:  The latest report from
> bui...@travis-ci.org on my Ecdat package for R on GitHub ends with
> "Found warnings, treating as errors (as requested)."  The word "warning"
> appears in that report over 100 times.  I didn't see anything there that
> suggested to me anything I understand how to change.
>
>
> NOTE:  "R CMD build Ecdat --resave-data" followed by "R CMD check
> Ecdat_0.3.3-tar.gz" completed with no errors, warnings or notes under
> macOS 10.14.6 and Windows 7 and 10.
>
>
>Thanks,
>Spencer Graves
>
>
>  Forwarded Message 
> Subject:Still Failing: sbgraves237/Ecdat#9 (master - c680f08)
> Date:   Sun, 22 Sep 2019 15:21:08 +
> From:   Travis CI 
> To: spencer.gra...@effectivedefense.org
>
>
>
> sbgraves237
>
> /
>
> Ecdat
>
> <
> https://travis-ci.org/sbgraves237/Ecdat?utm_medium=notification_source=email>
>
>
>
> branch iconmaster 
>
> build has failed
> Build #9 is still failing
> <
> https://travis-ci.org/sbgraves237/Ecdat/builds/588124072?utm_medium=notification_source=email
> >
> arrow to build time
> clock icon5 mins and 8 secs
>
> sbgraves237 avatarsbgraves237
>
> c680f08 CHANGESET →
> 
>
> roll date
>
> Want to know about upcoming build environment updates?
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
>
> SIGN UP HERE 
>
> book icon
>
> Documentation  about Travis CI
>
> Have any questions? We're here to help. 
> Unsubscribe
> <
> https://travis-ci.org/account/preferences/unsubscribe?repository=25157200_medium=notification_source=email>
>
> from build emails from the sbgraves237/Ecdat repository.
> To unsubscribe from *all* build emails, please update your settings
> <
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email>.
>
>
> black and white travis ci logo 
>
> Travis CI GmbH, Rigaer Str. 8
> ,
> 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: cont...@travis-ci.com  |
> Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß
> §27 a Umsatzsteuergesetz: DE282002648
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] References in package description file

[David Hugh-Jones]

Hi Wolfgang,

You can use the CITATION file. See ?citation and ?bibentry.

Cheers,
David


On Mon, 16 Sep 2019 at 08:55, Wolfgang Lenhard <
wolfgang.lenh...@uni-wuerzburg.de> wrote:

> Hello world,
> is there a standard way of adding references (scientific papers ...) to
> the description file in R packages other than putting the DOI in the
> description text? Does a best practise exist on how much references are
> advisable in order not to clutter the package information? Or should I
> put these things in the vignette instead?
>
> Thanks and best regards,
>  Wolfgang
>
> __
> 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

[R-pkg-devel] meta-question

[David Hugh-Jones]

Hi all,

A meta-question: I am developing a new package (
https://github.com/hughjonesd/santoku) and I would like to ask some
questions. But they are not about e.g. R CMD check or CRAN submission -
instead they're more abstract questions of software design. Is this the
right place to ask?

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Another CRAN-only bug

[David Hugh-Jones]

That is true. But the test doesn’t fail on my machine, or several others,
so I still wonder how I am going to debug it.

On Thu, 13 Jun 2019 at 10:54, Iñaki Ucar  wrote:

> On Thu, 13 Jun 2019 at 10:41, David Hugh-Jones 
> wrote:
> >
> >  Well, the test that fails is this one:
> >
> https://win-builder.r-project.org/incoming_pretest/huxtable_4.6.0_20190612_195453/Windows/examples_and_tests/tests_x64/testthat/test-openxlsx.R
> >
> >
> > The last line fails here:
> >
> >   hx <- huxtable(a = 1:2 + 0.5, b = -1:-2 + 0.5, d = letters[1:2],
> > add_colnames = TRUE)
> >   wb <- as_Workbook(hx)
> >   expect_error(openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx",
> > overwrite = TRUE),
> > regexp = NA) # openxlsx may emit messages
> >   dfr <- openxlsx::read.xlsx("test-xlsx.xlsx")
> >   expect_equivalent(class(dfr[[1]]), "numeric")
> >   expect_equivalent(class(dfr[[2]]), "numeric")
> >   expect_equivalent(class(dfr[[3]]), "character")
> >   expect_equal(dfr[[1]], 1:2 + 0.5)
> >
> > Putting to one side the issue of testthat’s putative faults, I am happy
> to
> > debug this myself, but how can I reproduce the platform to do it on?
>
> According to the errors,
>
> -- 1. Failure: Data written in appropriate format (@test-openxlsx.R#107)
> --
> dfr[[1]] not equal to 1:2 + 0.5.
> 2/2 mismatches (average diff: 0.5)
> [1] 1 - 1.5 == -0.5
> [2] 2 - 2.5 == -0.5
>
> -- 2. Failure: Data written in appropriate format (@test-openxlsx.R#108)
> --
> dfr[[2]] not equal to -1:-2 + 0.5.
> 2/2 mismatches (average diff: 0.5)
> [1]  0 - -0.5 == 0.5
> [2] -1 - -1.5 == 0.5
>
> your values are being casted to integers at some point. There are 4
> places in the test where this may have happened:
>
> - huxtable()
> - as_Workbook()
> - openxlsx::saveWorkbook()
> - openxlsx::read.xlsx()
>
> Iñaki
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Another CRAN-only bug

[David Hugh-Jones]

 Well, the test that fails is this one:
https://win-builder.r-project.org/incoming_pretest/huxtable_4.6.0_20190612_195453/Windows/examples_and_tests/tests_x64/testthat/test-openxlsx.R


The last line fails here:

  hx <- huxtable(a = 1:2 + 0.5, b = -1:-2 + 0.5, d = letters[1:2],
add_colnames = TRUE)
  wb <- as_Workbook(hx)
  expect_error(openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx",
overwrite = TRUE),
regexp = NA) # openxlsx may emit messages
  dfr <- openxlsx::read.xlsx("test-xlsx.xlsx")
  expect_equivalent(class(dfr[[1]]), "numeric")
  expect_equivalent(class(dfr[[2]]), "numeric")
  expect_equivalent(class(dfr[[3]]), "character")
  expect_equal(dfr[[1]], 1:2 + 0.5)

Putting to one side the issue of testthat’s putative faults, I am happy to
debug this myself, but how can I reproduce the platform to do it on?

David

On Thu, 13 Jun 2019 at 08:39, Uwe Ligges 
wrote:

> You can assume that CRAN packages are available within a day for on
> demand checks and even at once for CRAN incoming checks on winbuilder.
>
> Nevertheless, I have no idea where the problem comes from given the
> standard test mechanisms are not use and hence output does not show what
> the actual test was.
>
> Best,
> Uwe Ligges
>
>
>
>
> On 13.06.2019 06:59, David Hugh-Jones wrote:
> > Hi Duncan,
> >
> > Of course I appreciate the value of a centralised repository, and I
> > acknowledge the hard work that goes into maintaining it. That does not
> mean
> > that it should be beyond criticism. I wrote out of frustration, but also
> > because I hope things could be better.
> >
> > David
> >
> >
> >
> > On Wed, 12 Jun 2019 at 23:26, Duncan Murdoch 
> > wrote:
> >
> >> On 12/06/2019 4:57 p.m., David Hugh-Jones wrote:
> >>> Hi all,
> >>>
> >>> Not for the first time, my package has a bug that isn't found on rhub,
> >>> travis, appveyor, or my local machine, but is found on CRAN. This time
> >> it's
> >>> Windows-only, so I can't even download a Docker image and investigate
> >> that
> >>> way.
> >>>
> >>> TBH I am not very enthused by having to treat CRAN servers as "ground
> >>> truth", when there seems no way to reliably reproduce their
> >> configuration,
> >>> figure out what versions of packages are used, etc. Am I missing
> >> something?
> >>> Is another world possible?
> >>
> >> Nothing is forcing you to release your package on CRAN.  The only
> >> advantage to doing so is that they maintain high standards, which means
> >> people trust them.
> >>
> >> Just put your package on Github, and anyone can use it, no matter how
> >> bad it is.
> >>
> >> Duncan Murdoch
> >>
> >>>
> >>> Anyway, the error is at:
> >>>
> >>
> https://win-builder.r-project.org/incoming_pretest/huxtable_4.6.0_20190612_195453/Windows/examples_and_tests/
> >>> and it seems to relate to the openxlsx package, which is on 4.1.0.1
> since
> >>> May 28 - presumably long enough for the latest version to be available
> on
> >>> win-builder. Any ideas would be welcome
> >>>
> >>> David
> >>>
> >>>[[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >> --
> > Sent from Gmail Mobile
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Another CRAN-only bug

[David Hugh-Jones]

Hi Duncan,

Of course I appreciate the value of a centralised repository, and I
acknowledge the hard work that goes into maintaining it. That does not mean
that it should be beyond criticism. I wrote out of frustration, but also
because I hope things could be better.

David



On Wed, 12 Jun 2019 at 23:26, Duncan Murdoch 
wrote:

> On 12/06/2019 4:57 p.m., David Hugh-Jones wrote:
> > Hi all,
> >
> > Not for the first time, my package has a bug that isn't found on rhub,
> > travis, appveyor, or my local machine, but is found on CRAN. This time
> it's
> > Windows-only, so I can't even download a Docker image and investigate
> that
> > way.
> >
> > TBH I am not very enthused by having to treat CRAN servers as "ground
> > truth", when there seems no way to reliably reproduce their
> configuration,
> > figure out what versions of packages are used, etc. Am I missing
> something?
> > Is another world possible?
>
> Nothing is forcing you to release your package on CRAN.  The only
> advantage to doing so is that they maintain high standards, which means
> people trust them.
>
> Just put your package on Github, and anyone can use it, no matter how
> bad it is.
>
> Duncan Murdoch
>
> >
> > Anyway, the error is at:
> >
> https://win-builder.r-project.org/incoming_pretest/huxtable_4.6.0_20190612_195453/Windows/examples_and_tests/
> > and it seems to relate to the openxlsx package, which is on 4.1.0.1 since
> > May 28 - presumably long enough for the latest version to be available on
> > win-builder. Any ideas would be welcome
> >
> > David
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN student assistants

[David Hugh-Jones]

Joris,

I have no dog in this fight, but I think you should cool down a bit. Hadley
explained why he thought these people were students: it’s the adjective
studentische in the job description. I don’t think he meant, or implied,
any disrespect to the individuals concerned. He is entitled to ask in
public about CRAN’s process, which is of concern to everybody who deals
with CRAN. Lastly, accusations of “gaslighting” are over the top, and
adding heat to this debate.

If you think it’s wrong to record  correspondence with CRAN in public, you
may have a point – that is a separate topic. I would lean that CRAN
responses ought not to be considered confidential, but perhaps identifying
information should be shared with care. These are quite subtle issues, so
again, thoughtful discussion would be great.

David


On Thu, 16 May 2019 at 18:41, Joris Meys  wrote:

> On Thu, May 16, 2019 at 4:59 PM Hadley Wickham 
> wrote:
>
> > Hi all,
> >
> > I am most interested in understanding what level of
> > discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> > critique the implementation of R packages
>
>
> Ing. is the german title for "Engineer". You made her name public in the
> repositories of your own organisation. So at least have the decency to
> google her before you question her competence in public. Your obvious lack
> of understanding about the Austrian education system is no excuse for
> questioning her competence.
>
>
> > I mean no disrespect towards the CRAN maintainers
> >
>
> The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
> at the next R foundation in case you really need to know. The unrespectful
> thing to do, is to gaslight on a public mailing list to the point you make
> others, like Alejandro, question the competence of CRAN maintainers.
>
>
> >
> > I do recognise that my question "Who are they?" may have been
> > perceived as overly intrusive.
>
>
> The word is "bewildering", as you know their names, and your organisation
> shared personally identifying information (i.e. her email address which
> includes the institute she WORKS for) on their github repo.
>
>
> > To clarify: I don't want to know names
> > or other personally identifying information, but I would like to know
> > in general terms how many there are, and what backgrounds they have.
> >
>
> That's again something you can ask Dr. Ligges IN PRIVATE at the next R
> foundation meeting, and not a subject for an open mailing list. And after
> this exchange, I would totally understand if he refuses to answer that.
>
>
> > Similarly, I don't want to know how much they are paid, just whether
> > or not they are volunteers or employees.
> >
>
> The budgetary arrangements between a university and their _employee_ are of
> no concern to the mailing list. Asking about such arrangements for an
> employee that's not yours, is considered highly impolite in Europe.
>
> RStudio has been very vocal on numerous occasions about standards they
> hold. I would appreciate if the chief scientist of RStudio abides by those
> standards.
>
> Thank you.
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] package cartograflow_0.0.0.9000.tar.gz

[David Hugh-Jones]

Is “conflicted” in your DESCRIPTION file? Btw, can we see the package
source somewhere?

On Wed, 3 Apr 2019 at 19:24, cartograf...@gmail.com 
wrote:

>  Yes!
>
> Le mercredi 3 avril 2019 à 20:21:59 UTC+2, Ben Bolker <
> bbol...@gmail.com> a écrit :
>
>
>  Have you installed the 'conflicted' package on your local machine
> (i.e., the machine you're running the checks on)?
>
> On 2019-04-03 2:11 p.m., cartograf...@gmail.com wrote:
> >  Hi,
> >
> > I come back to you  because I have always the problem with
> devtools::check of my package.
> >
> > I used the command to check my package with R-devel :
> > sylvain@sylvain:~/svn$ bash R-devel.sh CMD check --as-cran
> /home/sylvain/work/12_R_studio/package/cartograflow_0.0.0.1.tar.gz
> >
> > When I start the rmd file there is a warning due to package dplyr :
> > Attaching package: 'dplyr'
> > The following objects are masked from 'package:stats':
> > filter, lag
> > The following objects are masked from 'package:base':
> > intersect, setdiff, setequal, union
> >
> > The solve this issue I added in rmd file, description file and the
> namespace the package conflicted.
> > So, the package conflicted avoid to have this warning.
> >
> > But when I run R-devel CMD check I have a new issue that is Error in
> loadNamespace...no package called ‘conflicted’ (see below)
> >
> > Can you help me to solve this issue if tit's possible?
> > Thanks in advance to your help !
> > Sylvain
> > -
> > Below extract of 00check.log
> > * checking whether package ‘cartograflow’ can be installed ... ERROR
> > Installation failed.
> > See ‘/home/sylvain/svn/cartograflow.Rcheck/00install.out’ for details.
> > * DONE
> > Status: 1 ERROR, 1 NOTE
> >
> > Below 00install.out
> > * installing *source* package ‘cartograflow’ ...
> > ** using staged installation
> > ** R
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
> vI[[i]]) :
> >   there is no package called ‘conflicted’
> > Calls:  ... loadNamespace -> withRestarts -> withOneRestart
> -> doWithOneRestart
> > Exécution arrêtée
> > ERROR: lazy loading failed for package ‘cartograflow’
> > * removing ‘/home/sylvain/svn/cartograflow.Rcheck/cartograflow’
> >
> >
> >
> >
> >
> >
> >
> >Le mardi 26 mars 2019 à 22:42:21 UTC+1, Henrik Bengtsson <
> henrik.bengts...@gmail.com> a écrit :
> >
> >  FWIW, you should be able to reproduce at least the following NOTEs
> > with your current R 3.5.2 and R CMD check --as-cran:
> >
> > * checking CRAN incoming feasibility ... NOTE
> > Maintainer: ‘cartogRaflow ’
> >
> > New submission
> >
> > Version contains large components (0.0.0.9000)
> >
> > Possibly mis-spelled words in DESCRIPTION:
> >   flowmapping (7:41)
> >
> > Author field should be Authors@R.  Current value is:
> >   c(person("Françoise", "Bahoken", email =
> > "francoise.baho...@ifsttar.fr", role = c("cre","aut")),
> > person("Sylvain", "Blondeau", email =
> > "blondeau.sylv...@yahoo.fr", role = c("aut"))
> >
> > The Title field should be in title case. Current version is:
> > ‘thematic cartography of flows and movements’
> > In title case that is:
> > ‘Thematic Cartography of Flows and Movements’
> >
> > Those are all classical mistakes ("we've all been there").  The
> > vignette errors may or may not be specific to R devel.
> >
> > /Henrik
> >
> > On Tue, Mar 26, 2019 at 2:29 PM cartograf...@gmail.com
> >  wrote:
> >>
> >> Hi,  l've made R CMD check --as-cran on rstudio 3.5.2Why I have to use
> r-devel?
> >> I confirm that I didn't received à error message when I've made
> dev_tool::check.
> >> How can I solve my problem ?
> >> Thanks in advance Sylvain
> >>
> >>
> >> nvoyé depuis Yahoo Mail pour Android
> >>
> >>   Le lun., mars 25, 2019 à 23:38, Uwe Ligges<
> lig...@statistik.tu-dortmund.de> a écrit :  I cannot beloeve it. But this
> is certainly not R-devel?
> >>
> >> Not sure about devtools which we do not use on CRAN, but simply
> >>
> >> R CMD check --as-cran
> >>
> >> with a recent R-devel  version on the package tarball should reproduce
> >> the findings.
> >>
> >> Best,
> >> Uwe Ligges
> >>
> >>
> >> On 25.03.2019 23:12, cartograf...@gmail.com wrote:
> >>> Hello,
> >>> I've submitted my package cartograflow and I received an email from
> your teeam that it does not pass the incoming checks automatically.Debian: <
> https://win-builder.r-project.org/incoming_pretest/cartograflow_0.0.0.9000_20190324_230822/Debian/00check.log
> >
> >>> Status: 1 ERROR, 2 WARNINGs, 1 NOTE
> >>>
> >>> So, I've made the new check on my plateform (linux ubuntu) and the
> check is OK.I used : ==> devtools::check(args =
> c('--no-manual','--as-cran'))Status is :
> >>> ── R CMD check results  cartograflow
> 0.0.0.9000 
> >>> Duration: 54.6s
> >>> 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
> >>> R CMD check succeeded
> >>> Can you  help me to fix the 

Re: [Rd] New grDevices::hcl.colors()

[David Hugh-Jones]

Hi Achim

Quick Q: why do some palettes have a hyphen in the name and others not?

David

On Tue, 2 Apr 2019 at 00:38, Achim Zeileis  wrote:

> Hi everyone,
>
> I wanted to draw your attention to a new post on the
> developer.R-project.org blog:
>
> https://developer.R-project.org/Blog/public/2019/04/01/hcl-based-color-palettes-in-grdevices/
>
> A new function grDevices::hcl.colors() greatly extends the color palette
> functionality available in base R. Also, the defaults in the heatmap
> functions image() and filled.contour() have been adapted accordingly.
>
> Feedback is welcome, especially regarding potential problems with the
> changed defaults.
>
> Best wishes,
> Z
>
> __
> 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: [R-pkg-devel] How to debug CRAN errors?

[David Hugh-Jones]

Thanks to Maëlle for getting me fixed up with r-hub, which is looking quite
slick.

I debugged the problem and it comes down to the R tinytex package not
playing nicely with Debian’s texlive installation.

I  think the answer is just to turn off all relevant tests on CRAN. It’s
reasonable for them to use texlive, and reasonable for Yihui to not want to
support it; meanwhile Travis etc still run the tests.

Thanks for your help, everyone!

David


On Thu, 14 Mar 2019 at 12:50, Maëlle SALMON  wrote:

> To follow up on the great answers regarding R-hub,
> - to use R-hub Linux Docker images you can use this brand-new rhub
> function https://r-hub.github.io/rhub/reference/local_check_linux.html
> (untested on Windows)
> - here's WIP R-hub docs entry about choosing a platform to reproduce an
> error https://docs.r-hub.io/#rhub-cran-platforms
>
> Maëlle.
>
>
>
>
> Den torsdag 14 mars 2019 08:48:34 CET, David Hugh-Jones <
> davidhughjo...@gmail.com> skrev:
>
>
> Thank you! Got it. This should be close enough to CRAN, and there’s a
> Docker image available too.
>
> On Thu, 14 Mar 2019 at 00:40, Duncan Murdoch 
> wrote:
>
> > On 13/03/2019 8:34 p.m., David Hugh-Jones wrote:
> > >
> > > Hi guys
> > >
> > > That might be it. But there was no error until the latest release -
> > > whereas that test has been there for 9 months. The file is written
> > > within testthat... is there a new check for this in CRAN?
> > >
> > > Meanwhile, I am still figuring out how to debug this problem. I
> uploaded
> > > to r-hub... does anyone know how I can access the artifacts created
> > > after the build? The URL build was
> > >
> > >
> >
> https://builder.r-hub.io/status/huxtable_4.4.0.tar.gz-b91485ad24b7a2f9c73bad2d51ebdb9d
> >
> > You should have got an email giving the link.  In the ones I've seen,
> > you replace the prefix
> >
> > https://builder.r-hub.io/status/
> >
> > with
> >
> > https://artifacts.r-hub.io/
> >
> > and you'll see them.  It works for yours.
> >
> > Duncan Murdoch
> >
> > >
> > > David
> > >
> > >
> > >
> > >  > By the way, I think your test test should write to a file in [a
> > >  > subdirectory of]] tempdir(), not to a file in the current
> > directory.
> > >
> > >That could be the source of the error:  it's a violation of CRAN
> > policy
> > >to write to the current directory.  An obvious way to test this
> > >would be
> > >to make it unwriteable.
> > >
> > >Duncan Murdoch
> > >
> > >  >
> > >  > comes from
> > >  > Bill Dunlap
> > >  > TIBCO Software
> > >  > wdunlap tibco.com <http://tibco.com>
> > >  >
> > >  >
> > >  > On Wed, Mar 13, 2019 at 8:50 AM David Hugh-Jones
> > >mailto:davidhughjo...@gmail.com>>
> > >  > wrote:
> > >  >>
> > >  >> Hi all,
> > >  >>
> > >  >> My package has errors on CRAN's Linux and Solaris:
> > >  >>
> > >  >>
> > https://cran.r-project.org/web/checks/check_results_huxtable.html
> > >  >>
> > >  >> which I can't reproduce on my local OSX Machine, nor on Linux
> on
> > >Travis.
> > >  >>
> > >  >> Does anyone have any general hints on how to reproduce and/or
> > >debug such
> > >  >> errors?
> > >  >>
> > >  >> Specifically the error relates to a call to
> > openxlsx::saveWorkbook
> > >  >> producing a message. openxlsx hasn't changed recently, though.
> > >  >>
> > >  >> Cheers,
> > >  >> David
> > >  >>
> > >  >>  [[alternative HTML version deleted]]
> > >  >>
> > >  >> __
> > >  >> R-package-devel@r-project.org
> > ><mailto: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
> > ><mailto:R-package-devel@r-project.org> mailing list
> > >  > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > >  >
> > >
> >
> > --
> Sent from Gmail Mobile
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to debug CRAN errors?

[David Hugh-Jones]

Thank you! Got it. This should be close enough to CRAN, and there’s a
Docker image available too.

On Thu, 14 Mar 2019 at 00:40, Duncan Murdoch 
wrote:

> On 13/03/2019 8:34 p.m., David Hugh-Jones wrote:
> >
> > Hi guys
> >
> > That might be it. But there was no error until the latest release -
> > whereas that test has been there for 9 months. The file is written
> > within testthat... is there a new check for this in CRAN?
> >
> > Meanwhile, I am still figuring out how to debug this problem. I uploaded
> > to r-hub... does anyone know how I can access the artifacts created
> > after the build? The URL build was
> >
> >
> https://builder.r-hub.io/status/huxtable_4.4.0.tar.gz-b91485ad24b7a2f9c73bad2d51ebdb9d
>
> You should have got an email giving the link.  In the ones I've seen,
> you replace the prefix
>
> https://builder.r-hub.io/status/
>
> with
>
> https://artifacts.r-hub.io/
>
> and you'll see them.  It works for yours.
>
> Duncan Murdoch
>
> >
> > David
> >
> >
> >
> >  > By the way, I think your test test should write to a file in [a
> >  > subdirectory of]] tempdir(), not to a file in the current
> directory.
> >
> > That could be the source of the error:  it's a violation of CRAN
> policy
> > to write to the current directory.  An obvious way to test this
> > would be
> > to make it unwriteable.
> >
> >     Duncan Murdoch
> >
> >  >
> >  > comes from
> >  > Bill Dunlap
> >  > TIBCO Software
> >  > wdunlap tibco.com <http://tibco.com>
> >  >
> >  >
> >  > On Wed, Mar 13, 2019 at 8:50 AM David Hugh-Jones
> > mailto:davidhughjo...@gmail.com>>
> >  > wrote:
> >  >>
> >  >> Hi all,
> >  >>
> >  >> My package has errors on CRAN's Linux and Solaris:
> >  >>
> >  >>
> https://cran.r-project.org/web/checks/check_results_huxtable.html
> >  >>
> >  >> which I can't reproduce on my local OSX Machine, nor on Linux on
> > Travis.
> >  >>
> >  >> Does anyone have any general hints on how to reproduce and/or
> > debug such
> >  >> errors?
> >  >>
> >  >> Specifically the error relates to a call to
> openxlsx::saveWorkbook
> >  >> producing a message. openxlsx hasn't changed recently, though.
> >  >>
> >  >> Cheers,
> >  >> David
> >  >>
> >  >>  [[alternative HTML version deleted]]
> >  >>
> >  >> __
> >  >> R-package-devel@r-project.org
> > <mailto: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
> > <mailto:R-package-devel@r-project.org> mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >  >
> >
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to debug CRAN errors?

[David Hugh-Jones]

Hi guys

That might be it. But there was no error until the latest release - whereas
that test has been there for 9 months. The file is written within
testthat... is there a new check for this in CRAN?

Meanwhile, I am still figuring out how to debug this problem. I uploaded to
r-hub... does anyone know how I can access the artifacts created after the
build? The URL build was

https://builder.r-hub.io/status/huxtable_4.4.0.tar.gz-b91485ad24b7a2f9c73bad2d51ebdb9d

David


>
> > By the way, I think your test test should write to a file in [a
> > subdirectory of]] tempdir(), not to a file in the current directory.
>
> That could be the source of the error:  it's a violation of CRAN policy
> to write to the current directory.  An obvious way to test this would be
> to make it unwriteable.
>
> Duncan Murdoch
>
> >
> > comes from
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> >
> > On Wed, Mar 13, 2019 at 8:50 AM David Hugh-Jones <
> davidhughjo...@gmail.com>
> > wrote:
> >>
> >> Hi all,
> >>
> >> My package has errors on CRAN's Linux and Solaris:
> >>
> >> https://cran.r-project.org/web/checks/check_results_huxtable.html
> >>
> >> which I can't reproduce on my local OSX Machine, nor on Linux on Travis.
> >>
> >> Does anyone have any general hints on how to reproduce and/or debug such
> >> errors?
> >>
> >> Specifically the error relates to a call to openxlsx::saveWorkbook
> >> producing a message. openxlsx hasn't changed recently, though.
> >>
> >> Cheers,
> >> David
> >>
> >>  [[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
> >
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to debug CRAN errors?

[David Hugh-Jones]

Hi Bill,

I take your point. Meanwhile, though, is there any way to debug the
problem? I’ll assume that making repeated uploads to CRAN is not a viable
approach it would be great if there were a Docker image of their setup
available, for example.

On Wed, 13 Mar 2019 at 17:00, William Dunlap  wrote:

> The complaint
>
> > test_check("huxtable")
>  -- 1. Failure: Data written in appropriate format
> (@test-openxlsx.R#101) --
>  `openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx", overwrite =
> TRUE)` produced messages.
>
> comes from your call to testthat::expect_silent()
>
> test_that("Data written in appropriate format", {
>   hx <- huxtable(a = 1:2 + 0.5, b = -1:-2 + 0.5, d = letters[1:2],
> add_colnames = TRUE)
>   wb <- as_Workbook(hx)
>   expect_silent(openxlsx::saveWorkbook(wb, file = "test-xlsx.xlsx",
> overwrite = TRUE))
>
>
> Perhaps you should suggest to the authors of testthat that it would be
> nice if expect_silent() showed some of the text of the messages, etc.,
> instead of just saying that messages were produced.
>
> By the way, I think your test test should write to a file in [a
> subdirectory of]] tempdir(), not to a file in the current directory.
>
> comes from
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
>
> On Wed, Mar 13, 2019 at 8:50 AM David Hugh-Jones 
> wrote:
> >
> > Hi all,
> >
> > My package has errors on CRAN's Linux and Solaris:
> >
> > https://cran.r-project.org/web/checks/check_results_huxtable.html
> >
> > which I can't reproduce on my local OSX Machine, nor on Linux on Travis.
> >
> > Does anyone have any general hints on how to reproduce and/or debug such
> > errors?
> >
> > Specifically the error relates to a call to openxlsx::saveWorkbook
> > producing a message. openxlsx hasn't changed recently, though.
> >
> > Cheers,
> > David
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] How to debug CRAN errors?

[David Hugh-Jones]

Hi all,

My package has errors on CRAN's Linux and Solaris:

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

which I can't reproduce on my local OSX Machine, nor on Linux on Travis.

Does anyone have any general hints on how to reproduce and/or debug such
errors?

Specifically the error relates to a call to openxlsx::saveWorkbook
producing a message. openxlsx hasn't changed recently, though.

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [Rd] Documentation examples for lm and glm

[David Hugh-Jones]

I would argue examples should encourage good practice. Beginners ought to
learn to keep data in data frames and not to overuse attach(). Experts can
do otherwise at their own risk, but they have less need of explicit
examples.

On Fri, 14 Dec 2018 at 14:51, S Ellison  wrote:

> FWIW, before all the examples are changed to data frame variants, I think
> there's fairly good reason to have at least _one_ example that does _not_
> place variables in a data frame.
>
> The data argument in lm() is optional. And there is more than one way to
> manage data in a project. I personally don't much like lots of stray
> variables lurking about, but if those are the only variables out there and
> we can be sure they aren't affected by other code, it's hardly essential to
> create a data frame to hold something you already have.
> Also, attach() is still part of R, for those folk who have a data frame
> but want to reference the contents across a wider range of functions
> without using with() a lot. lm() can reasonably omit the data argument
> there, too.
>
> So while there are good reasons to use data frames, there are also good
> reasons to provide examples that don't.
>
> Steve Ellison
>
>
> > -Original Message-
> > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Ben
> > Bolker
> > Sent: 13 December 2018 20:36
> > To: r-devel@r-project.org
> > Subject: Re: [Rd] Documentation examples for lm and glm
> >
> >
> >   Agree.  Or just create the data frame with those variables in it
> > directly ...
> >
> > On 2018-12-13 3:26 p.m., Thomas Yee wrote:
> > > Hello,
> > >
> > > something that has been on my mind for a decade or two has
> > > been the examples for lm() and glm(). They encourage poor style
> > > because of mismanagement of data frames. Also, having the
> > > variables in a data frame means that predict()
> > > is more likely to work properly.
> > >
> > > For lm(), the variables should be put into a data frame.
> > > As 2 vectors are assigned first in the general workspace they
> > > should be deleted afterwards.
> > >
> > > For the glm(), the data frame d.AD is constructed but not used. Also,
> > > its 3 components were assigned first in the general workspace, so they
> > > float around dangerously afterwards like in the lm() example.
> > >
> > > Rather than attached improved .Rd files here, they are put at
> > > www.stat.auckland.ac.nz/~yee/Rdfiles
> > > You are welcome to use them!
> > >
> > > Best,
> > >
> > > Thomas
> > >
> > > __
> > > 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
>
>
> ***
> This email and any attachments are confidential. Any u...{{dropped:12}}

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

Re: [R-pkg-devel] Suggested package relies on recent R

[David Hugh-Jones]

Yes, I certainly will do that. I've checked on win-builder and the package
seems to pass, so my examples seem to be in good order.
David


On Sat, 8 Dec 2018 at 15:17, Dirk Eddelbuettel  wrote:

>
> On 8 December 2018 at 14:41, David Hugh-Jones wrote:
> | Thanks guys. If CRAN already sets FORCE_SUGGESTS = false, then I think I
> | don't have a problem.
>
> I think you still do as long as you ignore Duncan's advice.  It's not
> "just"
> about skirting CRAN tests and rules, it is about doing packaging right.
>
> For that, Suggests != Depends and you should test presence of optional
> ppackage just like Duncan showed you.
>
> Dirk
>
>
> | David
> |
> |
> | On Sat, 8 Dec 2018 at 14:36, Duncan Murdoch 
> | wrote:
> |
> | > On 08/12/2018 9:28 AM, Hadley Wickham wrote:
> | > > Can you just set _R_CHECK_FORCE_SUGGESTS_=false?
> | > >
> | > > env:
> | > >global:
> | > ># don't treat missing suggested packages as error
> | > >- _R_CHECK_FORCE_SUGGESTS_=false
> | > >
> | > > I am reasonably certain that is what CRAN uses.
> | >
> | > Also make sure that examples fail gracefully if the suggested package
> is
> | > not present, i.e. wrap uses of the suggested package in
> | >
> | > if (requireNamespace(...)) { ... }
>
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Suggested package relies on recent R

[David Hugh-Jones]

Thanks guys. If CRAN already sets FORCE_SUGGESTS = false, then I think I
don't have a problem.
David


On Sat, 8 Dec 2018 at 14:36, Duncan Murdoch 
wrote:

> On 08/12/2018 9:28 AM, Hadley Wickham wrote:
> > Can you just set _R_CHECK_FORCE_SUGGESTS_=false?
> >
> > env:
> >global:
> ># don't treat missing suggested packages as error
> >- _R_CHECK_FORCE_SUGGESTS_=false
> >
> > I am reasonably certain that is what CRAN uses.
>
> Also make sure that examples fail gracefully if the suggested package is
> not present, i.e. wrap uses of the suggested package in
>
> if (requireNamespace(...)) { ... }
>
> Duncan Murdoch
>
>
> >
> > Hadley
> >
> > On Fri, Dec 7, 2018 at 9:11 AM David Hugh-Jones
> >  wrote:
> >>
> >> Hi,
> >>
> >> My package Suggests a package that relies on R >= 3.5.0. My package
> works
> >> fine with earlier R, though. When travis runs R CMD check on R-oldrel,
> >> therefore, it fails because it can't install the suggested package.
> >>
> >> Is this going to stop me submitting to CRAN? I don't really want to
> require
> >> R 3.5.0 just to satisfy an optional dependency.
>
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR

[David Hugh-Jones]

My package had this issue and still got accepted. I think it is a known
transient glitch. Just mention it when you submit.

On Wed, 7 Nov 2018 at 22:05, Ben Bolker  wrote:

>
>   Does it happen consistently?  If it's only happened once, could be a
> transient glitch in package dependencies.  I'd try re-testing, as a
> start.  Alternatively, if you're willing to add an R >= 3.5.1 dependency
> to your package, presumably CRAN won't mind if it fails tests on
> old-release ...
>
>
>
> On 2018-11-07 4:55 p.m., Derek Ogle wrote:
> > I am considering a CRAN release of a new package and was using
> R-winbuilder as a check. The check was successful with all but the
> "old-release" version (see
> https://win-builder.r-project.org/UhyHnNyn4Ukz/00check.log). The two
> errors both appear to be related to tests using testhtat::expect_output()
> and begin with the "ICU init failed: U_FILE_ACCESS_ERROR" error message.
> The full output for the first error is pasted below. My internet searches
> suggest (to me, but I am not confident) that this error is related to the
> stringr or stringi packages, which both appear to be used by
> testthat::expect_output(). Given that I don't receive this error in any
> other checking, I am not sure how to troubleshoot it (besides simply
> removing this test). Any thoughts would be greatly appreciated. Thank you.
> >
> > ** running tests for arch 'i386' ... [5s] ERROR
> >   Running 'test-all.R' [4s]
> > Running the tests in 'tests/test-all.R' failed.
> > Complete output:
> >   > library(testthat)
> >   > test_check("RFishBC")
> >   Loading required package: RFishBC
> >   ## RFishBC v0.0.13.9000. See vignettes at derekogle.com/RFishBC/.
> >
> >   -- 1. Error: backCalc() output types (@test_OUTPUTS.R#272)
> 
> >   ICU init failed: U_FILE_ACCESS_ERROR
> >   1: expect_output(backCalc(SMBassWB, lencap, BCM = "DALE", inFormat =
> "wide", digits = 0),
> >  "Dahl-Lea") at testthat/test_OUTPUTS.R:272
> >   2: quasi_capture(enquo(object), capture_output, label = label)
> >   3: capture(act$val <- eval_bare(get_expr(quo), get_env(quo)))
> >   4: capture_output_lines(code, print, width = width)
> >   5: eval_with_output(code, print = print, width = width)
> >   6: withr::with_output_sink(temp, withVisible(code))
> >   7: force(code)
> >   8: withVisible(code)
> >   9: eval_bare(get_expr(quo), get_env(quo))
> >   10: backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide", digits
> = 0)
> >   11: stringr::str_replace_all
> >   12: getExportedValue(pkg, name)
> >   13: asNamespace(ns)
> >   14: getNamespace(ns)
> >   15: tryCatch(loadNamespace(name), error = function(e) stop(e))
> >   16: tryCatchList(expr, classes, parentenv, handlers)
> >   17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> >   18: value[[3L]](cond)
> >
> > __
> > 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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[Rd] small bug in formatC?

[David Hugh-Jones]

formatC(0.0001, digits = 3, format = "f", zero.print="< 0.01")
Error in strrep(" ", nc - i1) : invalid 'times' value

The problem, if it is one, is in .format.zeros:
.format.zeros("0.000", "xx")
Error in strrep(" ", nc - i1) : invalid 'times' value

R version 3.5.1.


David

[[alternative HTML version deleted]]

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

Re: [Rd] Bias in R's random integers?

[David Hugh-Jones]

It doesn't seem too hard to come up with plausible ways in which this could
give bad results. Suppose I sample rows from a large dataset, maybe for
bootstrapping. Suppose the rows are non-randomly ordered, e.g. odd rows are
males, even rows are females. Oops! Very non-representative sample,
bootstrap p values are garbage.

David

On Wed, 19 Sep 2018 at 21:20, Duncan Murdoch 
wrote:

> On 19/09/2018 3:52 PM, Philip B. Stark wrote:
> > Hi Duncan--
> >
> >
>
> That is a mathematically true statement, but I suspect it is not very
> relevant.  Pseudo-random number generators always have test functions
> whose sample averages are quite different from the expectation under the
> true distribution.  Remember Von Neumann's "state of sin" quote.  The
> bug in sample() just means it is easier to find such a function than it
> would otherwise be.
>
> The practical question is whether such a function is likely to arise in
> practice or not.
>
>  > Whether those correspond to commonly used statistics or not, I have no
>  > idea.
>
> I am pretty confident that this bug rarely matters.
>
> > Regarding backwards compatibility: as a user, I'd rather the default
> > sample() do the best possible thing, and take an extra step to use
> > something like sample(..., legacy=TRUE) if I want to reproduce old
> results.
>
> I suspect there's a good chance the bug I discovered today (non-integer
> x values not being truncated) will be declared to be a feature, and the
> documentation will be changed.  Then the rejection sampling approach
> would need to be quite a bit more complicated.
>
> I think a documentation warning about the accuracy of sampling
> probabilities would also be a sufficient fix here, and would be quite a
> bit less trouble than changing the default sample().  But as I said in
> my original post, a contribution of a function without this bug would be
> a nice addition.
>
> Duncan Murdoch
>
> >
> > Regards,
> > Philip
> >
> > On Wed, Sep 19, 2018 at 9:50 AM Duncan Murdoch  > > wrote:
> >
> > On 19/09/2018 12:23 PM, Philip B. Stark wrote:
> >  > No, the 2nd call only happens when m > 2**31. Here's the code:
> >
> > Yes, you're right. Sorry!
> >
> > So the ratio really does come close to 2.  However, the difference in
> > probabilities between outcomes is still at most 2^-32 when m is less
> > than that cutoff.  That's not feasible to detect; the only detectable
> > difference would happen if some event was constructed to hold an
> > abundance of outcomes with especially low (or especially high)
> > probability.
> >
> > As I said in my original post, it's probably not hard to construct
> such
> > a thing, but as I've said more recently, it probably wouldn't happen
> by
> > chance.  Here's one attempt to do it:
> >
> > Call the values from unif_rand() "the unif_rand() outcomes".  Call
> the
> > values from sample() the sample outcomes.
> >
> > It would be easiest to see the error if half of the sample() outcomes
> > used two unif_rand() outcomes, and half used just one.  That would
> mean
> > m should be (2/3) * 2^32, but that's too big and would trigger the
> > other
> > version.
> >
> > So how about half use 2 unif_rands(), and half use 3?  That means m =
> > (2/5) * 2^32 = 1717986918.  A good guess is that sample() outcomes
> > would
> > alternate between the two possibilities, so our event could be even
> > versus odd outcomes.
> >
> > Let's try it:
> >
> >   > m <- (2/5)*2^32
> >   > m > 2^31
> > [1] FALSE
> >   > x <- sample(m, 100, replace = TRUE)
> >   > table(x %% 2)
> >
> >0  1
> > 399850 600150
> >
> > Since m is an even number, the true proportions of evens and odds
> > should
> > be exactly 0.5.  That's some pretty strong evidence of the bug in the
> > generator.  (Note that the ratio of the observed probabilities is
> about
> > 1.5, so I may not be the first person to have done this.)
> >
> > I'm still not convinced that there has ever been a simulation run
> with
> > detectable bias compared to Monte Carlo error unless it (like this
> one)
> > was designed specifically to show the problem.
> >
> > Duncan Murdoch
> >
> >  >
> >  > (RNG.c, lines 793ff)
> >  >
> >  > double R_unif_index(double dn)
> >  > {
> >  >  double cut = INT_MAX;
> >  >
> >  >  switch(RNG_kind) {
> >  >  case KNUTH_TAOCP:
> >  >  case USER_UNIF:
> >  >  case KNUTH_TAOCP2:
> >  > cut = 33554431.0; /* 2^25 - 1 */
> >  > break;
> >  >  default:
> >  > break;
> >  > }
> >  >
> >  >  double u = dn > cut ? ru() : unif_rand();
> >  >  return floor(dn * u);
> >  > }
> >  >
> >  > On Wed, Sep 19, 2018 at 9:20 AM Duncan Murdoch
> > mailto:murdoch.dun...@gmail.com>
> >  >  

Re: [Rd] Bias in R's random integers?

[David Hugh-Jones]

On Wed, 19 Sep 2018 at 13:43, Duncan Murdoch 
wrote:

>
> I think the analyses are correct, but I doubt if a change to the default
> is likely to be accepted as it would make it more difficult to reproduce
> older results.


I'm a bit alarmed by the logic here. Unbiased sampling seems basic for a
statistical language. As a consumer of R I'd like to think that e.g. my
bootstrapped p values are correct.
Surely if the old results depend on the biased algorithm, then they are
false results?
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R graphics 'text' package 'adj' parameter order wrong incorrect reversed?

[David Hugh-Jones]

Perhaps the documentation could be clearer, though. (I've been confused by
it also.) How about:

adj allows adjustment of the text with respect to (x, y). Values of 0, 0.5
and 1 specify that text will appear right of/above, centred around, and
left of/below the anchor point,  respectively.

On Wed, 19 Sep 2018 at 08:31, peter dalgaard  wrote:

> Exactly. And left alignment means that the left end of the text is aligned
> with the anchor point, etc. So documentation is correct.
>
> -pd
>
> > On 19 Sep 2018, at 01:33 , Jim Lemon  wrote:
> >
> > Hi Simon,
> > I think the conventions of typesetting are to blame. Think of an
> > invisible box around the text being displayed.
> > __
> > |Left justification  |
> > |-|
> > meaning that the text _starts_ at the left of the field and is to the
> > right of the text position specified
> > __
> > |Right justification|
> > |-|
> >
> > meaning that the text _ends_ at the right of the field and is to the
> > left of the text position. Can't do the top and bottom justification
> > this way, but I think you get the idea.
> >
> > Jim
> >
> > On Wed, Sep 19, 2018 at 9:13 AM Simon Dedman 
> wrote:
> >>
> >> Original stack overflow post here:
> >>
> https://stackoverflow.com/questions/52194719/r-graphic-text-package-adj-parameter-order-wrong-incorrect-reversed
> >>
> >> Hopefully this is now the appropriate place to post this as the above
> post
> >> got a single comment of agreement.
> >>
> >> Content:
> >>
> >> I believe R core package graphics text function's adj parameter is
> >> incorrectly described in the manual
> >> 
> and
> >> would be grateful if someone could confirm this before I submit a bug
> report
> >> .
> >>
> >> adj text:
> >>
> >> adj allows adjustment of the text with respect to (x, y). Values of 0,
> 0.5,
> >> and 1 specify left/bottom, middle and right/top alignment, respectively.
> >>
> >> Since text controls these labels and not the points which have already
> been
> >> plotted, I can't see how "with respect to x,y" can mean anything other
> than
> >> "in this direction relative to their points".
> >>
> >> However the order is reversed: 0,0 (supposedly left & bottom) is top &
> >> right; 1,1 (supposedly right & top) is left and bottom.
> >>
> >> Reproducible example:
> >>
> >> tens = 1:10
> >> plot(tens, tens, xlab = "adj 0,0 left/bottom")
> >> text(tens, tens, labels = letters[tens], adj = c(0,0))
> >> plot(tens, tens, xlab = "adj 0.5,0.5 middle")
> >> text(tens, tens, labels = letters[tens], adj = c(0.5,0.5))
> >> plot(tens, tens, xlab = "adj 1,1 right/top")
> >> text(tens, tens, labels = letters[tens], adj = c(1,1))
> >>
> >> Thanks.
> >>
> >>[[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
>
> --
> 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-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[David Hugh-Jones]

On Fri, 7 Sep 2018 at 09:01, Duncan Murdoch 
wrote:

>
> I think it's useful to think of 3 groups who might run tests:
>
>   - authors
>   - CRAN
>   - other users of a package.
>
> What Hadley was arguing for is that CRAN should identify itself to a
> package, so that by default a package could run different tests for
> CRAN than for other users.  I am arguing that they should run the same
> tests by default.


This seems like the crux. But there are occasions when authors want to
single out CRAN. Sometimes things just don't work on CRAN; the exact config
of CRAN servers is not always clear, so debugging can be hard; at some
point, it just gets easier to say skip_on_cran() or the equivalent. (The
same applies to some degree for e.g. appveyor/travis). I appreciate this is
an imperfect workaround. If the CRAN config were exactly reproducible eg
via a docker image, perhaps it wouldn't be necessary.
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[David Hugh-Jones]

On Fri, 7 Sep 2018 at 01:16, Duncan Murdoch 
wrote:

>
>
> When packages delete tests just for CRAN, the quality of the repository
> suffers.  Users should be able to check an install by running the tests
> that passed on CRAN and seeing them pass on their system as well.


In my limited experience there are usually tests that can't run on CRAN
 because they take too long, rely on external software or configuration
that is absent, or just fail on CRAN only (which is naturally hard to
debug). This seems normal, and having the ability to turn off some tests is
useful. The fact that multiple workarounds have evolved to do this suggests
that the need is widespread.



> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Recommendations about adding options to a package in order to change default values of some functions on-the-fly

[David Hugh-Jones]

Hi all,

A simple solution - if indeed you want to go down this route - is to use
options() and getOption(), ensuring all options are namespaced, e.g. by
prefixing them with the package name.

David

On Thu, 6 Sep 2018 at 17:15, Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> Dear Samuel,
>
> Many may object (for good reasons) that adding options would clash with
> functional paradigm, but it is possible.
> I don't know about the least worse practice but as far as I would do it,
> you could:
>
> 1. directly write and then read elements in the (hidden) list .Options that
> is present in the global environment:
> options(test = "blabla") ## add element in .Options
> .Options$test ## read element (for use in your own function)
>
> 2. you could also create your own alternative to options(), as ex:
> https://github.com/courtiol/IsoriX/blob/master/IsoriX/R/options.R
> Option 2 has the benefits of not risking conflict with existing names in
> .Options and it would thus also not mess up the way other packages may
> work.
> Option 1 uses what is already in place.
>
> I hope this help,
> Best
>
> Alex
>
> On Thu, 6 Sep 2018 at 17:18, Samuel  wrote:
>
> > Hi,
> >
> > I would like to change the default value of some arguments of some
> > functions in a package of mine. I don't want to change explicitly the
> > calls in the many scripts that have been written. For example, I would
> > to change the delimiter in all write.mytable() without changing any
> > calls it and without changing the default value currently assigned to
> > that delimiter in the declaration of this function. What I would like is
> > to add a command at the beginning of the scripts that says "since now,
> > the delimiter is ;".
> >
> > I am thinking about setting global options that those functions will
> > read and use to overwrite the default values. Of course the
> > write.mytable function has to be modify to exploit these settings, but
> > none of the scripts. I think about something similar to the par() and
> > options() functions.
> >
> > I noticed the settings package, but I would like to know if there is a
> > simple and recommended solution without adding any dependency.
> >
> > Hope my question is clear.
> >
> > Thanks for any advice,
> > Samuel
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
>
> --
> Alexandre Courtiol
>
> http://sites.google.com/site/alexandrecourtiol/home
>
> *"Science is the belief in the ignorance of experts"*, R. Feynman
>
> [[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] Puzzle or bug with matrix indexing

[David Hugh-Jones]

Yup, I worked it out in time... for future reference, as.matrix calls
`format` on logicals, converting them to the form seen.

On Sat, 4 Aug 2018 at 17:53, Berry, Charles  wrote:

>
>
> > On Aug 4, 2018, at 6:55 AM, David Hugh-Jones 
> wrote:
> >
> > I'm not sure why this is happening:
> >
> > tmp <- data.frame(
> >  a = letters[1:2],
> >  b=c(TRUE, FALSE),
> >  stringsAsFactors = FALSE
> > )
> > idx <- matrix(c(1, 2, 2, 2), 2, byrow = TRUE)
> > tmp[idx]
> >
> > [1] " TRUE" "FALSE"
> >
>
> From ?"[.data.frame"
>
> Extract.data.frame {base}
> .
> .
> .
> Matrix indexing (x[i] with a logical or a 2-column integer matrix i) using
> [ is not recommended. For extraction, x is first coerced to a matrix.
>
> [...]
>
> Thus, something like
>
> as.matrix(tmp)
>
> happens converting every column to character. Dig deeper by reading
>
> ?matrix
>
> and see the paragraph on `as.matrix' under `Details'.
>
> HTH,
>
> Chuck
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[Rd] Puzzle or bug with matrix indexing

[David Hugh-Jones]

I'm not sure why this is happening:

tmp <- data.frame(
  a = letters[1:2],
  b=c(TRUE, FALSE),
  stringsAsFactors = FALSE
)
idx <- matrix(c(1, 2, 2, 2), 2, byrow = TRUE)
tmp[idx]

[1] " TRUE" "FALSE"

Notice there is a space before the TRUE: " TRUE".

This space isn't happening purely because of coercion:

c("blah", TRUE, FALSE)
[1] "blah"  "TRUE"  "FALSE"

No space.

Obviously:
as.logical(tmp[idx])
[1]NA FALSE

which is why I think this might be a bug.

David

[[alternative HTML version deleted]]

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

Re: [Rd] Fwd: help building very old R

[David Hugh-Jones]

Thanks for the tip. That could be a huge timesaver. But it lists only a
single package for versions 0.90.1-2 ... how does that work?
David


On Mon, 30 Jul 2018 at 12:27, Dirk Eddelbuettel  wrote:

>
> On 30 July 2018 at 05:35, David Hugh-Jones wrote:
> | Hi guys,
> |
> | Perhaps someone here can help.
> |
> | I am trying to build versions of R 1 for the rcheology package (just
> | arrived on CRAN).
> |
> | For R prior to 1.5.0, I cannot configure support for tcl-tk.
> |
> | I am building on Debian Woody (provided by Docker debian/eol) and have
> the
> | following packages installed:
> | r-base-dev tclx8.3-dev tk8.3-dev xvfb xbase-clients x-window-system-core
> |
> | I download R source from http://cran.r-project.org/src/base/R-1 and run
> |
> | ./configure --with-tcl-tk=yes
> | --with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh
> |   --with-tk-config=/usr/lib/tk8.3/tkConfig.sh
> |
> | These are the locations for the relevant tkConfig.sh and tclConfig.sh
> files.
> | This gives output as follows:
> |
> | R is now configured for x86_64-unknown-linux-gnu
> |
> |   Source directory:  .
> |   Installation directory:/usr/local
> |
> |   C compiler:gcc  -g -O2
> |   C++ compiler:  c++  -g -O2
> |   FORTRAN compiler:  g77  -g -O2
> |   X11 support:   yes
> |   Gnome support: no
> |   Tcl/Tk support:no
> |   R profiling support:   yes
> |   R as a shared library: no
> |
> | And config.log reveals:
> | configure:13099: checking for /usr/lib/tcl8.3/tclConfig.sh
> | configure:13134: checking for /usr/lib/tk8.3/tkConfig.sh
> | configure:13204: checking for /usr/include/tcl8.3/tcl.h
> | configure:13214: gcc -E -I/usr/local/include conftest.c >/dev/null
> | 2>conftest.out
> | configure:13313: checking for /usr/include/tk8.3/tk.h
> | configure:13323: gcc -E -I/usr/local/include -I/usr/X11R6/include
> | -I/usr/include
> | /tcl8.3 conftest.c >/dev/null 2>conftest.out
> | configure:13319: /usr/include/tk8.3/tk.h: No such file or directory
> | configure: failed program was:
> | #line 13318 "configure"
> | #include "confdefs.h"
> | #include 
> | configure:13348: checking for /usr/include/tk.h
> | configure:13358: gcc -E -I/usr/local/include -I/usr/X11R6/include
> | -I/usr/include
> | /tcl8.3 conftest.c >/dev/null 2>conftest.out
> | configure:13354: /usr/include/tk.h: No such file or directory
> | configure: failed program was:
> | #line 13353 "configure"
> | #include "confdefs.h"
> | #include 
> | configure:13385: checking for tk.h
> | configure:13389: tk.h: No such file or directory
> |
> | In fact, tk.h is in  /usr/include/tcl8.3/ , despite the failed program
> | compilation report.
> |
> | R 1.5.0 and above work fine. Can anyone remember far back, if something
> | changed in the configure script?
> |
> | Alternatively, those who are feeling brave can download the Docker image
> | creation scripts from github.com/hughjonesd/rcheology .
>
> Have you considered the actual Debian packages from "way back then" ?
> Debian has this nifty snapshot archive where you can get old binaries:
>
>   http://snapshot.debian.org/
>
> For (source package) r-base we see 3.5.1 all the way down to 0.61.2
>
>   http://snapshot.debian.org/package/r-base/
>
> Alternatively, the package itself is now (finally, my bad) in a git repo
> which goes back to 0.61.2 as well (using snapshot as the feeder)
>
>   https://salsa.debian.org/edd/r-base/commits/master
>
> Hth,  Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [Rd] apply with zero-row matrix

[David Hugh-Jones]

Interesting discussion. I'm not wholly convinced by Martin's and Emil's
arguments. The behaviour seems to violate an obvious expectation (fun is
called once per row) to satisfy a subtle one (result has a guaranteed
dimension and type).

In any case, here's a suggested chunk of rd to go at the end of the "Value":

If \code{dim(X)[MARGIN]} is zero, then \code{FUN} is called once, with an
argument of the appropriate dimensions. The argument's type is the same as
\code{typeof(m)}, and the argument values are those returned by
\code{vector(typeof(m))}. For example, if m is numeric, the argument will
be a vector (or matrix or array) of zeroes. The type and length of the
value returned by \code{FUN} is used to determine the type of the result.

And at the end of "Details":

\code{FUN} is always called at least once, see below.


David


On Mon, 30 Jul 2018 at 15:05, Gabor Grothendieck 
wrote:

> Try pmap and related functions in purrr:
>
>   pmap(as.data.frame(m), ~ { cat("Called...\n"); print(c(...)) })
>   ## list()
>
> On Mon, Jul 30, 2018 at 12:33 AM, David Hugh-Jones
>  wrote:
> > Forgive me if this has been asked many times before, but I couldn't find
> > anything on the mailing lists.
> >
> > I'd expect apply(m, 1, foo) not to call `foo` if m is a matrix with zero
> > rows.
> > In fact:
> >
> > m <- matrix(NA, 0, 5)
> > apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> > ## Called...
> > ## [1] FALSE FALSE FALSE FALSE FALSE
> >
> > Similarly for apply(m, 2,...) if m has no columns.
> > Is there a reason for this? Could it be documented?
> >
> > David
> > --
> > Sent from Gmail Mobile
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] apply with zero-row matrix

[David Hugh-Jones]

Hi Martin,

Fair enough for R functions in general. But the behaviour of apply violates
the expectation that apply(m, 1, fun) calls fun n times when m has n rows.
That seems pretty basic.

Also, I understand from your argument why it makes sense to call apply and
return a special result (presumably NULL) for an empty argument; but why
should apply call fun?

Cheers
David

On Mon, 30 Jul 2018 at 08:41, Martin Maechler 
wrote:

> >>>>> David Hugh-Jones
> >>>>> on Mon, 30 Jul 2018 05:33:19 +0100 writes:
>
> > Forgive me if this has been asked many times before, but I
> > couldn't find anything on the mailing lists.
>
> > I'd expect apply(m, 1, foo) not to call `foo` if m is a
> > matrix with zero rows.  In fact:
>
> > m <- matrix(NA, 0, 5)
> > apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> > ## Called...
> > ## [1] FALSE FALSE FALSE FALSE FALSE
>
>
> > Similarly for apply(m, 2,...) if m has no columns.  Is
> > there a reason for this?
>
> Yes :
>
> The reverse is really true for almost all basic R functions:
>
> They *are* called and give an "empty" result automatically
> when the main argument is empty.
>
> What you basicaly propose is to add an extra
>
>  if()
>  return()
>
> to all R functions.  While that makes sense for high-level R
> functions that do a lot of things, this would really be a bad
> idea in general :
>
> This would make all of these basic functions larger {more to maintain} and
> slightly slower for all non-zero cases just to make them
> slightly faster for the rare zero-length case.
>
> Martin Maechler
> ETH Zurich and R core Team
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[Rd] Fwd: help building very old R

[David Hugh-Jones]

Hi guys,

Perhaps someone here can help.

I am trying to build versions of R 1 for the rcheology package (just
arrived on CRAN).

For R prior to 1.5.0, I cannot configure support for tcl-tk.

I am building on Debian Woody (provided by Docker debian/eol) and have the
following packages installed:
r-base-dev tclx8.3-dev tk8.3-dev xvfb xbase-clients x-window-system-core

I download R source from http://cran.r-project.org/src/base/R-1 and run

./configure --with-tcl-tk=yes
--with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh
  --with-tk-config=/usr/lib/tk8.3/tkConfig.sh

These are the locations for the relevant tkConfig.sh and tclConfig.sh files.
This gives output as follows:

R is now configured for x86_64-unknown-linux-gnu

  Source directory:  .
  Installation directory:/usr/local

  C compiler:gcc  -g -O2
  C++ compiler:  c++  -g -O2
  FORTRAN compiler:  g77  -g -O2
  X11 support:   yes
  Gnome support: no
  Tcl/Tk support:no
  R profiling support:   yes
  R as a shared library: no

And config.log reveals:
configure:13099: checking for /usr/lib/tcl8.3/tclConfig.sh
configure:13134: checking for /usr/lib/tk8.3/tkConfig.sh
configure:13204: checking for /usr/include/tcl8.3/tcl.h
configure:13214: gcc -E -I/usr/local/include conftest.c >/dev/null
2>conftest.out
configure:13313: checking for /usr/include/tk8.3/tk.h
configure:13323: gcc -E -I/usr/local/include -I/usr/X11R6/include
-I/usr/include
/tcl8.3 conftest.c >/dev/null 2>conftest.out
configure:13319: /usr/include/tk8.3/tk.h: No such file or directory
configure: failed program was:
#line 13318 "configure"
#include "confdefs.h"
#include 
configure:13348: checking for /usr/include/tk.h
configure:13358: gcc -E -I/usr/local/include -I/usr/X11R6/include
-I/usr/include
/tcl8.3 conftest.c >/dev/null 2>conftest.out
configure:13354: /usr/include/tk.h: No such file or directory
configure: failed program was:
#line 13353 "configure"
#include "confdefs.h"
#include 
configure:13385: checking for tk.h
configure:13389: tk.h: No such file or directory

In fact, tk.h is in  /usr/include/tcl8.3/ , despite the failed program
compilation report.

R 1.5.0 and above work fine. Can anyone remember far back, if something
changed in the configure script?

Alternatively, those who are feeling brave can download the Docker image
creation scripts from github.com/hughjonesd/rcheology .

Cheers,

David
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[Rd] apply with zero-row matrix

[David Hugh-Jones]

Forgive me if this has been asked many times before, but I couldn't find
anything on the mailing lists.

I'd expect apply(m, 1, foo) not to call `foo` if m is a matrix with zero
rows.
In fact:

m <- matrix(NA, 0, 5)
apply(m, 1, function (x) {cat("Called...\n"); print(x)})
## Called...
## [1] FALSE FALSE FALSE FALSE FALSE

Similarly for apply(m, 2,...) if m has no columns.
Is there a reason for this? Could it be documented?

David
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] More on explosive dependencies

[David Hugh-Jones]

Hi Russell,

That's v helpful and I am going to try it myself. Can I just ask what goes
in your namespace file (and what roxygen tags you use) for the relevant
methods?

David


On Tue, 17 Jul 2018 at 02:29, Lenth, Russell V 
wrote:

> Thanks to all who responded. I am pleased to say that with your help, I
> have managed to work around this problem by dynamically registering the
> methods. My file zzz.R contains code to register various methods having
> generics in coda and multcomp. Those packages are in Suggests (not Imports)
> and my code is:
>
> .onLoad = function(libname, pkgname) {
> if (requireNamespace("coda", quietly = TRUE)) {
> register_s3_method("coda", "as.mcmc", "emmGrid")
> register_s3_method("coda", "as.mcmc.list", "emmGrid")
> }
> if (requireNamespace("multcomp", quietly = TRUE)) {
> register_s3_method("multcomp", "glht", "emmlf")
> register_s3_method("multcomp", "glht", "emmGrid")
> register_s3_method("multcomp", "cld", "emmGrid")
> register_s3_method("multcomp", "modelparm", "emmwrap")
>  }
> }
>
> The function register_s3_method was copied from hms:::register_s3_method.
> That function sets up and calls base::registerS3method if the package in
> the first argument is already loaded, and sets a hook to do so if it is not
> (or if it is subsequently unloaded and reloaded).
>
> My package now has the desired small number of dependencies, and passes
> checks even with Sys.setenv(`_R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_`
> = TRUE), i.e., require all S3 methods to be registered.
>
> Russ
>
> Russell V. Lenth  -  Professor Emeritus
> Department of Statistics and Actuarial Science
> The University of Iowa  -  Iowa City, IA 52242  USA
> Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017
>
> -Original Message-
> From: Lenth, Russell V
> Sent: Sunday, July 15, 2018 8:24 PM
> To: r-package-devel@r-project.org
> Subject: More on explosive dependencies
>
> Package developers,
>
> I posted a question a couple of months ago dealing with how to reduce the
> number of dependencies in a package. Part of the specific issue I face is
> that I have a `cld` S3 method for which the generic is in the multcomp
> package, but I don't want to import multcomp because it comes with a number
> of unneeded dependencies.
>
> My solution at first appeared to be that I could just export my function
> `cld.emmGrid`; then if users have the multcomp package, this method is
> available. I also moved multcomp from Imports to Suggests, so that it is no
> longer a dependency. This fix works just fine for me. It passed the
> preliminary CRAN checks and it was accepted by CRAN. But then I was advised
> that the package fails the CRAN checks with Debian because those checks
> require S3 methods to actually be registered.
>
> So what I tried next is what Duncan Murdoch suggested earlier in this
> thread -- to register the method conditionally using the following code in
> my NAMESPACE:
>
> if (requireNamespace("multcomp")) {
> importFrom(multcomp, cld)
> S3method(cld, emmGrid)
> }
>
> This worked fine in my initial testing, both with multcomp installed and
> with multcomp absent.
>
> However, now the package doesn't pass the checking procedure. The reason
> apparently is that every package mentioned in import() or importFrom() --
> conditionally or not -- must be listed in Imports in the DESCRIPTION file.
> I could move multcomp back to Imports, but that defeats the whole purpose
> of getting rid of unneeded dependencies. It's a Catch-22.
>
> Is there any recourse possible? Alas, I'm guessing there isn't, unless we
> can convince everybody to allow unregistered S3 methods on all platforms.
> This situation makes it really difficult for package developers to provide
> methods for other contributors' packages and still keep theirs lightweight.
> Almost all S3 generics are very simple functions, so being forced to load a
> dozen or so namespaces just to register a method is crazy. Plus, the more
> dependencies a package has, the less robust it is to other developers'
> updates.
>
> I'm now wondering how much interest there is in developing a separate
> package just for generics, say, "S3generics". We could all collaborate to
> contribute our own generics to that one package, move them out of our own
> packages, and instead import just that package.
>
> Russ
>
> __
> 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: [R-pkg-devel] More on explosive dependencies

[David Hugh-Jones]

Hi Russ,

 Possibly relevant: the modelgenerics package (on GitHub) does exactly what
you're suggesting for standard model functions like `nobs` etc. I think at
some point it is going to become part of the tidyverse.

D


On Mon, 16 Jul 2018 at 02:24, Lenth, Russell V 
wrote:

> Package developers,
>
> I posted a question a couple of months ago dealing with how to reduce the
> number of dependencies in a package. Part of the specific issue I face is
> that I have a `cld` S3 method for which the generic is in the multcomp
> package, but I don't want to import multcomp because it comes with a number
> of unneeded dependencies.
>
> My solution at first appeared to be that I could just export my function
> `cld.emmGrid`; then if users have the multcomp package, this method is
> available. I also moved multcomp from Imports to Suggests, so that it is no
> longer a dependency. This fix works just fine for me. It passed the
> preliminary CRAN checks and it was accepted by CRAN. But then I was advised
> that the package fails the CRAN checks with Debian because those checks
> require S3 methods to actually be registered.
>
> So what I tried next is what Duncan Murdoch suggested earlier in this
> thread -- to register the method conditionally using the following code in
> my NAMESPACE:
>
> if (requireNamespace("multcomp")) {
> importFrom(multcomp, cld)
> S3method(cld, emmGrid)
> }
>
> This worked fine in my initial testing, both with multcomp installed and
> with multcomp absent.
>
> However, now the package doesn't pass the checking procedure. The reason
> apparently is that every package mentioned in import() or importFrom() --
> conditionally or not -- must be listed in Imports in the DESCRIPTION file.
> I could move multcomp back to Imports, but that defeats the whole purpose
> of getting rid of unneeded dependencies. It's a Catch-22.
>
> Is there any recourse possible? Alas, I'm guessing there isn't, unless we
> can convince everybody to allow unregistered S3 methods on all platforms.
> This situation makes it really difficult for package developers to provide
> methods for other contributors' packages and still keep theirs lightweight.
> Almost all S3 generics are very simple functions, so being forced to load a
> dozen or so namespaces just to register a method is crazy. Plus, the more
> dependencies a package has, the less robust it is to other developers'
> updates.
>
> I'm now wondering how much interest there is in developing a separate
> package just for generics, say, "S3generics". We could all collaborate to
> contribute our own generics to that one package, move them out of our own
> packages, and instead import just that package.
>
> Russ
>
> Russell V. Lenth  -  Professor Emeritus
> Department of Statistics and Actuarial Science
> The University of Iowa  -  Iowa City, IA 52242  USA
> Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Versioning conventions

[David Hugh-Jones]

Thanks! Fixed.

Sounds like people favour 3.5.1.0 as the style. Seems reasonable.


David


On Tue, 10 Jul 2018 at 16:00, Hugh Parsonage 
wrote:

> 3.5.1.0 with the 4th number (0) for within-release changes.
>
> Lovely package by the way -- I was looking for it earlier this year
> but thought it had been lost!
>
> The link in the GitHub description appears broken, however.
>
> On 10 July 2018 at 23:59, David Hugh-Jones 
> wrote:
> > Hi all,
> >
> > Just updated my rcheology package with data on functions for R 3.5.1 (no
> > change from R 3.5.0 afaik). See https://github.com/hughjonesd/rcheology.
> >
> > I'm wondering how to version this package. It's not on CRAN yet so it
> would
> > be good to get things right.
> >
> > Possibilities:
> >
> > * Just copy the R versions, so the new version would be 3.5.1
> > Advantages: easy to understand. Disadvantages: semantic versioning would
> > follow R, not the package itself (which does contain a single function
> with
> > a public API); what if I make changes between R releases.
> > * ownversion.major.minor-Rversion.major.minor e.g. 0.1.0-3.5.1
> > Advantages: shows the R version clearly, contains own semantic versioning
> > information. Disadvantages: long.
> > * ownversion.major.minor-Rversionmajorminor e.g. 0.1.0-351
> > Advantage: as above but shorter. Disadvantages: if we hit e.g. 3.10.0,
> then
> > go back to 4.0.0, then we'd end up going backward in the last component.
> >
> > Any ideas?
> >
> > Cheers,
> > David
> >
> > [[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

[R-pkg-devel] Versioning conventions

[David Hugh-Jones]

Hi all,

Just updated my rcheology package with data on functions for R 3.5.1 (no
change from R 3.5.0 afaik). See https://github.com/hughjonesd/rcheology.

I'm wondering how to version this package. It's not on CRAN yet so it would
be good to get things right.

Possibilities:

* Just copy the R versions, so the new version would be 3.5.1
Advantages: easy to understand. Disadvantages: semantic versioning would
follow R, not the package itself (which does contain a single function with
a public API); what if I make changes between R releases.
* ownversion.major.minor-Rversion.major.minor e.g. 0.1.0-3.5.1
Advantages: shows the R version clearly, contains own semantic versioning
information. Disadvantages: long.
* ownversion.major.minor-Rversionmajorminor e.g. 0.1.0-351
Advantage: as above but shorter. Disadvantages: if we hit e.g. 3.10.0, then
go back to 4.0.0, then we'd end up going backward in the last component.

Any ideas?

Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[David Hugh-Jones]

That will indeed fail everywhere.  The puzzle is why it fails (only
sometimes) when the methods are all exported. The GitHub equivalent is tag
v4.0.1-rc1.

On Thu, 5 Jul 2018 at 20:43, Iñaki Úcar  wrote:

>
>
> El jue., 5 jul. 2018 21:35, David Hugh-Jones 
> escribió:
>
>> Installed from CRAN or github? CRAN should be OK - I hope!
>>
>
> From GitHub before the patch.
>
>
>> On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:
>>
>>> I installed huxtable in two environments, my own Fedora installation
>>> with R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4
>>> and an empty library. In both cases, huxtable is unusable: every example I
>>> try fails because it doesn't find the methods.
>>>
>>> So it has nothing to do with R checks or CRAN scripts, and it seems
>>> improbable to me that the error comes from a corrupted dependency.
>>>
>>> Iñaki
>>>
>>>
>>> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
>>> escribió:
>>>
>>>> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
>>>> >
>>>> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
>>>> > v4.0.1 on CRAN has a namespace file which contains
>>>> >
>>>> > S3method(bold,huxtable)
>>>> > export(bold)
>>>> > export(bold.huxtable)
>>>> >
>>>> > and
>>>> >
>>>> > S3method("align<-",huxtable)
>>>> > export("align<-")
>>>> > export("align<-.huxtable")
>>>> >
>>>> > yet still fails on linux-patched and linux-release, with "no
>>>> applicable
>>>> > method" errors for align<- and bold. Unfortunately, I don't know how
>>>> to
>>>> > reproduce the error on any other platform
>>>>
>>>> I just got R installed on an Ubuntu VM, and ran "R CMD check
>>>> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without
>>>> seeing
>>>> the error you quoted.  (I did see other problems, related to not having
>>>> things like pandoc installed; nothing that looked like a problem with
>>>> the package rather than a problem with my R installation.)
>>>>
>>>> That looks like a bug, but without having a system that can reproduce
>>>> it, it's hard to narrow down where:
>>>>
>>>>   - In R's checks?  Seems unlikely, given it is so system specific.
>>>>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>>>>   - In huxtable or some package used by huxtable?  Seems possible:
>>>> maybe memory got corrupted.  Perhaps running under some memory checker
>>>> would be more informative.
>>>>
>>>> Perhaps the CRAN team could be helpful here.
>>>>
>>>> >
>>>> > Anyway, meanwhile, my problem is fixed and I have learned something
>>>> > about function environments.
>>>>
>>>> Given that the error is unrelated to the solution, it really looks like
>>>> memory corruption somewhere or other.
>>>>
>>>> Duncan Murdoch
>>>>
>>> --
>> Sent from Gmail Mobile
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[David Hugh-Jones]

Installed from CRAN or github? CRAN should be OK - I hope!

On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:

> I installed huxtable in two environments, my own Fedora installation with
> R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4 and
> an empty library. In both cases, huxtable is unusable: every example I try
> fails because it doesn't find the methods.
>
> So it has nothing to do with R checks or CRAN scripts, and it seems
> improbable to me that the error comes from a corrupted dependency.
>
> Iñaki
>
>
> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
> escribió:
>
>> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
>> >
>> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
>> > v4.0.1 on CRAN has a namespace file which contains
>> >
>> > S3method(bold,huxtable)
>> > export(bold)
>> > export(bold.huxtable)
>> >
>> > and
>> >
>> > S3method("align<-",huxtable)
>> > export("align<-")
>> > export("align<-.huxtable")
>> >
>> > yet still fails on linux-patched and linux-release, with "no applicable
>> > method" errors for align<- and bold. Unfortunately, I don't know how to
>> > reproduce the error on any other platform
>>
>> I just got R installed on an Ubuntu VM, and ran "R CMD check
>> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
>> the error you quoted.  (I did see other problems, related to not having
>> things like pandoc installed; nothing that looked like a problem with
>> the package rather than a problem with my R installation.)
>>
>> That looks like a bug, but without having a system that can reproduce
>> it, it's hard to narrow down where:
>>
>>   - In R's checks?  Seems unlikely, given it is so system specific.
>>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>>   - In huxtable or some package used by huxtable?  Seems possible:
>> maybe memory got corrupted.  Perhaps running under some memory checker
>> would be more informative.
>>
>> Perhaps the CRAN team could be helpful here.
>>
>> >
>> > Anyway, meanwhile, my problem is fixed and I have learned something
>> > about function environments.
>>
>> Given that the error is unrelated to the solution, it really looks like
>> memory corruption somewhere or other.
>>
>> Duncan Murdoch
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[David Hugh-Jones]

Agreed. I fixed the roxygen2 and it works fine. But yet, the original
v4.0.1 on CRAN has a namespace file which contains

S3method(bold,huxtable)
export(bold)
export(bold.huxtable)

and

S3method("align<-",huxtable)
export("align<-")
export("align<-.huxtable")

yet still fails on linux-patched and linux-release, with "no applicable
method" errors for align<- and bold. Unfortunately, I don't know how to
reproduce the error on any other platform

Anyway, meanwhile, my problem is fixed and I have learned something about
function environments.

Cheers,
David




On Thu, 5 Jul 2018 at 12:20, Duncan Murdoch 
wrote:

>
> That's a roxygen2 bug or misuse.  If you use the code below without the
> roxygen2 processing, and manually build the NAMESPACE file as
>
> export(foo)
> S3method(foo, bar)
>
> then things are fine.  I don't know roxygen2 well enough to know what
> else you should have done to get your NAMESPACE file to look like that.
>
> Duncan Murdoch
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[David Hugh-Jones]

Wow, this is extremely helpful. I've applied Joris' patch. By the way, the
github master has the change that I stopped exporting methods, as per
Hadley's suggestion; this caused *all* functions created via
make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
exported, which was masking the error in most cases. I don't know why
bold() was failing in certain cases only... in any case, the patch seems to
fix things.

Here is a brief test case that shows the original problem. I don't know
whether this reveals any problem in base R:

# in package mypackage:
#' @export
foo <- function (x, ...) UseMethod('foo')
make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
foo.bar"), pos = getNamespace('mypackage'))
make_a_method()

# in the console:
library(mypackage)
mypackage:::foo.bar
## function (x, ...) cat("In foo.bar")
## 
## 
x <- structure(1, class='bar')
foo(x)
## Error in UseMethod("foo") :
##  no applicable method for 'foo' applied to an object of class "bar"

Also, I know I shouldn't be using @s3method ... it's on the TODO list... !

Cheers,
David


On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar  wrote:

> El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
> () escribió:
> >
> > On 04/07/2018 4:04 PM, Joris Meys wrote:
> > >
> > >
> > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch <
> murdoch.dun...@gmail.com
> > > > wrote:
> > >
> > >
> > > That shouldn't matter.  That function was created in a local
> > > environment whose parent is 
> > > (probably by the huxtable:::make_setter_getters function, but I
> > > didn't check).
> > >
> > > Duncan Murdoch
> > >
> > > I would think it does matter. Methods are found on the search path, but
> > > the environment where the methods are defined is not on the search
> path.
> > > It's a child environment of the namespace, and hence cannot be reached
> > > from either the global environment or the namespace if I understood it
> > > correctly.
> > >
> >
> > The environment of a function is where it looks for objects, not where
> > it is stored.  That method is stored in the huxtable namespace, and
> > exported from it.  That's why
> > getFromNamespace("align.huxtable","huxtable") (or even
> > huxtable::align.huxtable) finds it.
> >
> > I don't know the source of the original error.
>
> I don't know either. But obviously it has something to do with the
> function environment and how UseMethod looks for methods when they are
> exported from a namespace (I tested a similar "layout" in the global
> environment and the method is correctly found). So maybe this thread
> belongs to r-devel instead.
>
> Iñaki
>
> >
> > Duncan Murdoch
> >
>
> __
> 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: [R-pkg-devel] Weird error on CRAN linux check

[David Hugh-Jones]

I figured that. Actually I just tried this. I now get the interesting
result that all calls to a generic fail with the UseMethod error...?

On Wed, 4 Jul 2018 at 16:12, Joris Meys  wrote:

> On Wed, Jul 4, 2018 at 4:22 PM, Hadley Wickham 
> wrote:
>
>> I don't think it's related to the error, but you shouldn't be exporting
>> this:
>>
>> export("align<-.huxtable")
>>
>> You should generally only export the method.
>>
>
> Hadley means to say that you should generally only export the generic, not
> the individual methods.
> More information here:
>
> https://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods
>
> Cheers
> Joris
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> 
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] Weird error on CRAN linux check

[David Hugh-Jones]

Hi all,

The following shows an error for my package:
https://www.r-project.org/nosvn/R.check/r-release-linux-x86_64/huxtable-00check.html

Here's an excerpt:

> ### ** Examples
>
>
> ht <- huxtable(a = 1:3, b = 1:3)
> align(ht) <- 'right'
Error in UseMethod("align<-") :
  no applicable method for 'align<-' applied to an object of class
"c('huxtable', 'data.frame')"
Calls: align<-


The error didn't show up on win-builder, travis, appveyor or my own
computer (a mac). The package defines an `align<-.huxtable` method which is
correctly loaded on my computer, and the NAMESPACE file contains these
lines:

S3method("align<-",huxtable)
export("align<-")
export("align<-.huxtable")

Has anyone got any ideas?

David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] r-patched error

[David Hugh-Jones]

Thank you very much for this thoughtful advice! I am guessing that
getNamespace("huxtable") would be another more self-documenting way to do
this. I will make the change.

David


On Mon, 4 Jun 2018 at 13:26, Duncan Murdoch 
wrote:

>
> I'd worry a little bit about your "make_getter_setters" function:  it
> saves the result using
>
>lapply(names(funs), function (x) {
>  assign(x, funs[[x]], envir = parent.frame(3)) # 3: 1 for
> function(x), 2 for lapply, 3 for the caller!
>})
>
> That count of 3 looks like an implementation detail that could
> conceivably vary, for instance if the compiler decided to optimize out a
> call or two, or lapply's implementation changed.  (I suspect this isn't
> the cause of the error you saw, or you would have seen it a lot more:
> but I'd still fix it.)
>
> I think a safer way to find the huxtable namespace is something like
>
> huxtableNamespace <- .getNamespace("huxtable")
>
> though this is advised against; a documented but less obvious way to do
> it would be
>
> huxtableNamespace <- environment(huxtable)
>
> The "huxtable" on the right is the function; most other functions in
> your package would also be fine, as long as you haven't done anything
> tricky to change their environments.
>
> With one of those definitions, you could change your lapply() to
>
>lapply(names(funs), function (x) {
>  assign(x, funs[[x]], envir = huxtableNamespace)
>})
>
>  > Checks are passing fine on other platforms. Is this just a weirdness
> to do
>  > with the changes in R 3.5.0 on Linux? Or does it indicate a real
> problem?
>
> A possibility is memory corruption at the C level.  Since you don't have
> any C code in huxtable that couldn't be caused by what you did, but you
> might still be a victim of it.
>
> Duncan Murdoch
>
>
> >
> > Cheers,
> > David
> >
> >  > ### ** Examples
> >  >
> >  >
> >  > ht <- huxtable(a = 1:3, b = 1:3)
> >  > align(ht) <- 'right'
> >  Error in UseMethod("align<-") :
> >   no applicable method for 'align<-' applied to an object of class
> > "c('huxtable', 'data.frame')"
> >  Calls: align<-
> >  Execution halted
> > Flavor: r-patched-linux-x86_64
> > <
> https://www.r-project.org/nosvn/R.check/r-patched-linux-x86_64/huxtable-00check.html
> >
> >
> > Version: 4.0.0
> > Check: re-building of vignette outputs
> > Result: WARN
> >  Error in re-building vignettes:
> >   ...
> >  Quitting from lines 52-104 (design-principles.Rmd)
> >  Error: processing vignette ‘design-principles.Rmd’ failed with
> > diagnostics:
> >  no applicable method for ‘bold’ applied to an object of class
> > "c('huxtable', 'data.frame')"
> >  Execution halted
> > Flavor: r-patched-linux-x86_64
> > <
> https://www.r-project.org/nosvn/R.check/r-patched-linux-x86_64/huxtable-00check.html
> >
> > David
> >
> >   [[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

[R-pkg-devel] r-patched error

[David Hugh-Jones]

Hi all,

Latest release of my package has an error when checked on r-patched-linux
and r-devel-linux. Relevant output is shown below (from
https://cran.r-project.org/web/checks/check_results_huxtable.html). It
suggests that there's no method for `align<-` and `bold` for huxtable
objects. In fact the package defines and exports such methods. Selected
lines from the NAMESPACE file:

S3method("align<-",huxtable)
S3method(bold,huxtable)
export("align<-")
export("align<-.huxtable")
export(bold)
export(bold.huxtable)

Checks are passing fine on other platforms. Is this just a weirdness to do
with the changes in R 3.5.0 on Linux? Or does it indicate a real problem?

Cheers,
David

> ### ** Examples
>
>
> ht <- huxtable(a = 1:3, b = 1:3)
> align(ht) <- 'right'
Error in UseMethod("align<-") :
 no applicable method for 'align<-' applied to an object of class
"c('huxtable', 'data.frame')"
Calls: align<-
Execution halted
Flavor: r-patched-linux-x86_64


Version: 4.0.0
Check: re-building of vignette outputs
Result: WARN
Error in re-building vignettes:
 ...
Quitting from lines 52-104 (design-principles.Rmd)
Error: processing vignette ‘design-principles.Rmd’ failed with
diagnostics:
no applicable method for ‘bold’ applied to an object of class
"c('huxtable', 'data.frame')"
Execution halted
Flavor: r-patched-linux-x86_64

David

[[alternative HTML version deleted]]

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

Re: [Rd] cat(fill=N)

[David Hugh-Jones]

Agreed. Perhaps this is a documentation issue:

fill: a logical or (positive) numeric controlling how the output is
  broken into successive lines.  If ‘FALSE’ (default), only
  newlines created explicitly by ‘"\n"’ are printed.
  Otherwise, the output is broken into lines with print width
  equal to the option ‘width’ if ‘fill’ is ‘TRUE’, or the value
  of ‘fill’ if this is numeric.  Non-positive ‘fill’ values are
  ignored, with a warning.

could add "Newlines are only printed between elements of x, not within
elements".

But I think the behaviour I expected is more intuitive. The natural use
case is to
limit line length, and if so, that should apply globally not just between
elements.


On 16 March 2018 at 16:19, Serguei Sokol <so...@insa-toulouse.fr> wrote:

> Le 16/03/2018 à 17:10, David Hugh-Jones a écrit :
>
>> Hi all,
>>
>> I expect I'm getting something wrong, but
>>
>> cat("foo bar baz foo bar baz foo bar baz", fill = 10)
>>
>> should be broken into lines of width 10, whereas I get:
>>
>> cat("foo bar baz foo bar baz foo bar baz", fill = 10)
>>>
>> foo bar baz foo bar baz foo bar baz
>>
> On the other side, if I do
> > cat(strsplit("foo bar baz foo bar baz foo bar baz", " ")[[1]], fill = 10)
> I get the expected result:
>
> foo bar
> baz foo
> bar baz
> foo bar
> baz
>
> Which suggest that cat() doesn't break elements of submitted character
> vector
> put put enough of them to fill the requested width.
>
> Serguei.
>
>
>> This is on R 3.4.3, but I don't see mentions of it fixed in 3.4.4 or
>> r-devel NEWS.
>>
>> Cheers,
>> David
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>

[[alternative HTML version deleted]]

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

[Rd] cat(fill=N)

[David Hugh-Jones]

Hi all,

I expect I'm getting something wrong, but

cat("foo bar baz foo bar baz foo bar baz", fill = 10)

should be broken into lines of width 10, whereas I get:

> cat("foo bar baz foo bar baz foo bar baz", fill = 10)

foo bar baz foo bar baz foo bar baz

This is on R 3.4.3, but I don't see mentions of it fixed in 3.4.4 or
r-devel NEWS.

Cheers,
David

[[alternative HTML version deleted]]

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

[Rd] speeding up R compilation

[David Hugh-Jones]

Hello all,

First, a small advert for this:
https://hughjonesd.shinyapps.io/rcheology/
which lists functions in core R going back to 3.0.1.

Second, I'm trying to extend this back to 2.0.0. That involves building
many versions of R from source on a Docker image of Debian Sarge. (Shades
 of 2006, when the Linux desktop was around the corner, just as soon as I'd
finished compiling this *^&%* software...)

This is obviously quite slow. Do list members have any suggestions for how
to maximize compilation speed of (old) R sources?

Currently I'm doing:

 CFLAGS="-O0 -pipe" FFLAGS=-O0 ./configure --with-recommended-packages=no \
  --with-libpng=no --with-libjpeg=no \
  --with-tcl-config=/usr/lib/tcl8.4/tclConfig.sh \
  --with-tk-config=/usr/lib/tk8.4/tkConfig.sh --with-tcl-tk=yes
 make -j4

Cheers,
David

[[alternative HTML version deleted]]

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

[Rd] Fwd: install.packages doesn't produce warnings unless qualified with utils::

[David Hugh-Jones]

On Sat, 3 Mar 2018 at 20:01, Joshua Ulrich  wrote:

>
> >
> My guess is that something (a package, console, etc) is masking
> utils::install.packages().
>
>
This looks about right. On R in the terminal the warning is thrown. In
Rstudio I have the problem, and:

 > getAnywhere('install.packages')
2 differing objects matching ‘install.packages’ were found
in the following places
  package:utils
  namespace:utils
Use [] to view one of them

And the version in package.utils looks like:

function (...)
.rs.callAs(name, hook, original, ...)

OK, so an RStudio issue. Indeed, this looks like the problem:

https://github.com/rstudio/rstudio/blob/master/src/cpp/r/R/Tools.R

There, callAs is defined as running a function with error handlers which
use `cat` to reprint warnings.

Thanks!
David
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[Rd] install.packages doesn't produce warnings unless qualified with utils::

[David Hugh-Jones]

Hi all,

Assuming this is an R core issue:

tryCatch(install.packages("clipr", repos = "bullshit"), warning = function
(w) cat("got a warning"))
Warning in install.packages :
  unable to access index for repository bullshit/src/contrib:
  cannot open URL 'bullshit/src/contrib/PACKAGES'
Warning in install.packages :
  package ‘clipr’ is not available (for R version 3.4.3)
Warning in install.packages :
  unable to access index for repository
bullshit/bin/macosx/el-capitan/contrib/3.4:
  cannot open URL 'bullshit/bin/macosx/el-capitan/contrib/3.4/PACKAGES'

In other words, lots of warnings, but none are caught.

It works if you use the fully qualified version in utils:

tryCatch(utils::install.packages("clipr", repos = "bullshit"), warning =
function (w) cat("got a warning"))
got a warning

Any ideas?
Cheers,
David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission huxtable 2.0.2

[David Hugh-Jones]

Hi Dirk

Not running the test on CRAN would fix the problem, but it is kind of an
admission of failure. Part of CRAN's point is quality control, so switching
off tests just to pass seems perverse. I'll do it if that is the only
option.

Yes, I bet the CRAN guys are highly busy, and full respect to them. It
might be nice, though, if there were a public document about what is on
those servers. Just e.g. a list of software and versions. Or the name of
the OS and release. That would presumably help
travis/win-builder/individual R developers to create environments closer to
the CRAN one, and that would reduce the number of CRAN-only bugs.

Cheers,
David

On 7 February 2018 at 12:20, Dirk Eddelbuettel  wrote:

>
> Maybe don't run the test if it always fails, and you cannot control the
> setting?
>
> Rcpp has had conditional tests for (I guess at least) 5+ years -- I just
> test
> if the version number has four components (ie 0.1.2.3, a test version) as
> opposed to three (ie 0.1.3, a release) and test only on the former (my box,
> Travis, ... but not CRAN). That started because CRAN had its time limit,
> but
> the idea is generally valid.
>
> | In general, is there any info available about the CRAN check servers? I
> | keep running into problems that are specific to them and cannot be
> | replicated on any other machine available to me.
>
> You can ask, and eventually someone will answer, but "those in charge" are
> busy too.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission huxtable 2.0.2

[David Hugh-Jones]

Hi guys,

I've been having some problems with updating my 'huxtable' package on CRAN.
The latest issue is that I run a test which renders a rmarkdown document to
PDF, using rmarkdown::render. This passes R CMD check fine on my machine,
on travis and on win-builder, but fails on the CRAN machines as follows:

Last 13 lines of output:
  BEGIN failed--compilation aborted at
D:\Compiler\texmf\scripts\latexmk\perl\latexmk.pl line 122.
  File::Path version 2.08 required--this is only version 1.08 at
D:\Compiler\texmf\scripts\latexmk\perl\latexmk.pl line 122.

This looks like something coming via pandoc, and it also looks as if it is
a function of a very old version of Perl: File::Path version 2.08 came out
in 2009. Version 1.08 is included with Perl 5.8 which came out in 2002.

What's going on here, and can anyone suggest a fix?

In general, is there any info available about the CRAN check servers? I
keep running into problems that are specific to them and cannot be
replicated on any other machine available to me.

David


On 5 February 2018 at 13:07,  wrote:

> Dear maintainer,
>
> package huxtable_2.0.2.tar.gz does not pass the incoming checks
> automatically, please see the pre-test at:
>  135743_huxtable_202/00check.log>
> Status: 2 ERRORs, 1 NOTE
>
> Current CRAN status: ERROR: 1, OK: 1
> See: 
>
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on
> the R-package-devel mailing list:
> 
> If you are fairly certain the rejection is a false positive, please
> reply-all to this message and explain.
>
> More details are given in the directory:
>  135743_huxtable_202>
> The files will be removed after roughly 7 days.
>
>
> Best regards,
> CRAN teams' auto-check service
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] r-quantities seeking feedback

[David Hugh-Jones]

Hi Iñaki,

OK, it sounds like we have no practical disagreement: you're planning to
keep separate packages and then have a third one for integration. That will
be fine for people like me who don't necessarily want to specify units for
our regressions. I look forward to seeing this!

Cheers,
David

On 7 October 2017 at 13:00, Iñaki Úcar <i.uca...@gmail.com> wrote:

> 2017-10-06 22:28 GMT+02:00 David Hugh-Jones <davidhughjo...@gmail.com>:
> > Many measurements have no unit, but some uncertainty - e.g. the b and se
> > from an arbitrary regression. Can you give specific examples of the
> > advantages from binding these packages tightly together?
>
> As Duncan already pointed out, the units of b and se from an arbitrary
> regression depend on the units of your variables. The advantages from
> integrating both packages are the combination of advantages from each
> one with the same workflow as if you were working with bare numbers.
>
> It seems that you are already aware of the advantages of automatic
> error propagation. Regarding the units package, it is very useful for
> painless conversion of units. A conversion from kg to g is elementary,
> but some others require more care, for example J to eV, or N.m-1 to
> dyn.cm-1. In electromagnetism, it is very common to work with the CGS
> units system, and an automatic conversion from/to the SI comes in
> handy.
>
> If you are not persuaded already, we can also talk about the Mars
> Climate Orbiter, a robotic space probe launched by NASA on 1998 which
> disintegrated in Mars' upper atmosphere due to a computation with
> wrong units.
>
> Iñaki
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] r-quantities seeking feedback

[David Hugh-Jones]

Many measurements have no unit, but some uncertainty - e.g. the b and se
from an arbitrary regression. Can you give specific examples of the
advantages from binding these packages tightly together?

On Fri, 6 Oct 2017 at 21:23, Iñaki Úcar <i.uca...@gmail.com> wrote:

> El 6 oct. 2017 19:13, "David Hugh-Jones" <davidhughjo...@gmail.com>
> escribió:
>
> One question that comes to mind: what's the synergy? I e why are units and
> errors best handled together? I use standard errors a lot, but never
> units... I would like a standard way to represent uncertainty but don't
> think I need the other stuff.
>
>
> You will always be able to use errors (or units) alone if you wish, but
> every measurement has a unit and some uncertainty, so we think it's
> interesting to have the possibility of handling them in a unified way (I/O,
> propagation, automatic axes and error bars in plots...).
>
> Iñaki
>
> Cheers,
> D
>
> On Fri, 6 Oct 2017 at 17:25, Iñaki Úcar <i.uca...@gmail.com> wrote:
>
>> Dear all,
>>
>> Edzer Pebesma and I are combining forces into a new GitHub
>> organisation called "r-quantities", to which we have moved the CRAN
>> packages 'units', 'errors' and 'constants'. The idea is to write a new
>> package called 'quantities' to integrate 'units' and 'errors' into a
>> comprehensive solution for dealing with quantity values + uncertainty
>> calculus.
>>
>> Given that a significant fraction of R users, both practitioners and
>> researchers, use R to analyse measurements, we believe that the R
>> community would benefit from such a project. Moreover, to the best of
>> our knowledge, there exists no such an integrated and automated
>> framework outside the R language.
>>
>> We would like to share a proposal [1] to be submitted to the R
>> Consortium before October 15. Until then, we kindly invite the R
>> package developers to review it. Any feedback or contribution would be
>> very helpful.
>>
>> [1] https://github.com/r-quantities/proposal
>>
>> Regards,
>> Iñaki
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Sent from Gmail Mobile
>
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] r-quantities seeking feedback

[David Hugh-Jones]

One question that comes to mind: what's the synergy? I e why are units and
errors best handled together? I use standard errors a lot, but never
units... I would like a standard way to represent uncertainty but don't
think I need the other stuff.
Cheers,
D

On Fri, 6 Oct 2017 at 17:25, Iñaki Úcar  wrote:

> Dear all,
>
> Edzer Pebesma and I are combining forces into a new GitHub
> organisation called "r-quantities", to which we have moved the CRAN
> packages 'units', 'errors' and 'constants'. The idea is to write a new
> package called 'quantities' to integrate 'units' and 'errors' into a
> comprehensive solution for dealing with quantity values + uncertainty
> calculus.
>
> Given that a significant fraction of R users, both practitioners and
> researchers, use R to analyse measurements, we believe that the R
> community would benefit from such a project. Moreover, to the best of
> our knowledge, there exists no such an integrated and automated
> framework outside the R language.
>
> We would like to share a proposal [1] to be submitted to the R
> Consortium before October 15. Until then, we kindly invite the R
> package developers to review it. Any feedback or contribution would be
> very helpful.
>
> [1] https://github.com/r-quantities/proposal
>
> Regards,
> Iñaki
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Category (Subjection) in R documentation for package

[David Hugh-Jones]

In roxygen2 you do

@section Section name:

The colon is important.

David

On 1 October 2017 at 19:50, Duncan Murdoch  wrote:

> On 01/10/2017 12:42 PM, Mohammad Tanvir Ahamed via R-package-devel wrote:
>
>> I am building package R-studio (Roxygen2).
>> In the package function documentation, now the standard format is to show
>> all function name.
>>
>> Now I want to categorize those function under some section/heading.
>> Can any one please hey me regarding this issue?
>> Is there any way or idea how one can do it ?
>>
>
>
> I don't know how to do this with Roxygen2, but what you want to get is a
> package help page (typically yourpackage-package.Rd with
> \alias{yourpackage-package}, and maybe also \alias{yourpackage}).  On that
> page you can have sections using
>
> \section{section_title}{
>some content
> }
>
> The "some content" can be a list of links to your help topics using
> \itemize, \enumerate, or \tabular.  See the built-in manual "Writing R
> Extensions", and presumably some Roxygen2 documentation to tell you how to
> let all of this get through to the .Rd file.
>
> Duncan Murdoch
>
>
> __
> 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: [R-pkg-devel] tibbles are not data frames

[David Hugh-Jones]

These replies seem to be missing the point, which is that old code has to
be rewritten because tibbles don't behave like data frames.

It is true that subclasses can override behaviour, but there is an implicit
contract that the same methods should do the same things.

The as.xxx pattern seems weird to me, though I see it a lot. What is the
point of inheritance if you always have to convert an object upwards before
you can treat it as a member of the superclass?

I can see this argument will run...

David

On 26 September 2017 at 11:15, Gábor Csárdi  wrote:

> What is the benefit here, compared to just calling as.data.frame() on it?
>
> Gabor
>
> On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke 
> wrote:
> > Since tibbles add their class attributes first, you could use:
> >
> > tb <- tibble(a = 5)
> > inherits(tb, "data.frame", which = TRUE) == 1
> >
> > if "tb" is a data frame (only), TRUE is returned, for tibble FALSE. You
> could then coerce to data frame: as.data.frame(tb)
> >
> > -Ursprüngliche Nachricht-
> > Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im
> Auftrag von Göran Broström
> > Gesendet: Dienstag, 26. September 2017 12:09
> > An: r-package-devel@r-project.org
> > Betreff: Re: [R-pkg-devel] tibbles are not data frames
> >
> >
> >
> > On 2017-09-26 11:56, Gábor Csárdi wrote:
> >> On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys 
> wrote:
> >>> I don't like the dropping of dimensions either. That doesn't change
> >>> the fact that a tibble reacts different from a data.frame. So tibbles
> >>> do not inherit correctly from the class data.frame, and it can thus
> >>> be argued that it's against OOP paradigms to pretend tibbles inherit
> >>> from the class data.frame.
> >>
> >> I have yet to see an OOP system in which a subclass cannot override
> >> the methods of its superclass. Not only is this in line with OOP
> >> paradigms, it is actually one of the essential OOP features.
> >>
> >> To be more constructive, if you have a function that only works with
> >> data frame inputs, then it is good practice to check that the supplied
> >> input is indeed a data frame. This is independent of tibbles.
> >
> > It is not. I check input for being a data frame, but tibbles pass that
> test. That's the essence of the problem.
> >
> >> In practice it seems to me that an easy fix is to just call
> >> as.data.frame on the input. This should either convert it to a data
> >> frame, or throw an error.
> >
> > Sure, but I still need to rewrite the package.
> >
> > Görn
> >
> >> For tibbles it
> >> drops the tbl* classes.
> >>
> >> Gabor
> >>
> >>> Defensive coding techniques would check if it's a tibble and return
> >>> an error saying a data.frame is expected. Unless tibbles inherit
> >>> correctly from data.frame.
> >>>
> >>> I have nothing against tibbles. But calling them "data.frame" raises
> >>> expectations that can't be fulfilled.
> >>
> >> [...]
> >>
> >> __
> >> 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
> >
> > --
> >
> > _
> >
> > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
> Rechts; Gerichtsstand: Hamburg | www.uke.de
> > Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr.
> Dr. Uwe Koch-Gromus, Joachim Prölß, Martina Saurin (komm.)
> > _
> >
> > SAVE PAPER - THINK BEFORE PRINTING
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Changing a package's name

[David Hugh-Jones]

Apropos of nothing, I just came across this line at
https://github.com/trestletech/plumber:

plumber was originally released as the rapier package and has since been
renamed (7/13/2015)

Heh.

David

On 13 June 2017 at 13:29, Michael Dewey <li...@dewey.myzen.co.uk> wrote:

> Dear David
>
> It is your package and you can choose the name you prefer. If you feel
> uncomfortable with the current one then change it. I do not think anyone
> else's opinion is relevant unless a package author picks a name that all
> right thinking people would find offensive.
>
>
> On 11/06/2017 14:51, David Hugh-Jones wrote:
>
>> Hello all,
>>
>> A short while ago I released the "huxtable" package for writing HTML and
>> LaTeX tables:
>> https://www.github.com/hughjonesd/huxtable
>>
>> The name seemed cute to me, but I later found out that to Americans it has
>> special associations. The Huxtables were the family in the Cosby show.
>> That
>> would be fine, except that Bill Cosby is now on trial for one case of
>> rape,
>> and there are accusations of many other cases.
>>
>> So, two questions:
>>
>> * Do you think I should change the name?
>>
>> Comments welcome from Americans and others on this difficult cultural
>> issue.
>>
>> * If I do, what's the best and least disruptive way to do it? Bear in mind
>> that I have a couple of thousand users.
>>
>> My first thought would be to release an update which gives a warning about
>> the future change when the package is loaded; then release a package with
>> the new name and continue development on this branch.
>>
>> David
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ---
>> This email has been checked for viruses by AVG.
>> http://www.avg.com
>>
>>
>>
> --
> Michael
> http://www.dewey.myzen.co.uk/home.html
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Changing a package's name

[David Hugh-Jones]

Hello all,

A short while ago I released the "huxtable" package for writing HTML and
LaTeX tables:
https://www.github.com/hughjonesd/huxtable

The name seemed cute to me, but I later found out that to Americans it has
special associations. The Huxtables were the family in the Cosby show. That
would be fine, except that Bill Cosby is now on trial for one case of rape,
and there are accusations of many other cases.

So, two questions:

* Do you think I should change the name?

Comments welcome from Americans and others on this difficult cultural issue.

* If I do, what's the best and least disruptive way to do it? Bear in mind
that I have a couple of thousand users.

My first thought would be to release an update which gives a warning about
the future change when the package is loaded; then release a package with
the new name and continue development on this branch.

David

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Hi guys,

Thanks very much for all of your comments. I now have a good sense of what
the possibilities are, and I will think about what works best for my
package.

Cheers,
David


On 20 April 2017 at 14:42, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:

> On 20/04/2017 4:57 AM, Brian G. Peterson wrote:
>
>> David,
>>
>> I'd suggest creating a vignette for each of HTML and PDF, and including
>> a source file that contains the common code.  e.g. have a pdf header and
>> an html header file, and then include the 'main' Rmd as a child doc from
>> each header Rmd.  This way R CMD build could build both pdf and html
>> versions of the output.
>>
>
> That's another solution.  My suggestion would be simpler:  just pick one
> of PDF or HTML, and give the user instructions to produce the other if
> necessary, but don't produce it for them.
>
> Duncan Murdoch
>
>
>
>> Regards,
>>
>> Brian
>>
>> On 04/20/2017 03:38 AM, David Hugh-Jones wrote:
>>
>>> Hi Duncan,
>>>
>>> Thank you very much for taking the time to look at this.
>>>
>>> I tried rebuilding the tar file so as to include only the .Rmd files, not
>>> the HTML files, in 'vignettes':
>>>
>>> drwxr-xr-x  0 david  staff   0 20 Apr 09:21 huxtable/vignettes/
>>>
>>> -rw-r--r--  0 david  staff1633  6 Apr 16:26
>>> huxtable/vignettes/comparison.csv
>>>
>>> -rw-r--r--  0 david  staff6697  6 Apr 14:44
>>> huxtable/vignettes/design-principles.Rmd
>>>
>>> -rw-r--r--  0 david  staff5521  6 Apr 14:30
>>> huxtable/vignettes/huxreg.Rmd
>>>
>>> -rw-r--r--  0 david  staff   20552  6 Apr 16:19
>>> huxtable/vignettes/huxtable.Rmd
>>>
>>> -rw-r--r--  0 david  staff  22 17 Mar 00:19
>>> huxtable/vignettes/placeins-header.tex
>>>
>>>
>>> But when I run R CMD check, I still get the same warning:
>>>
>>> * checking package vignettes in ‘inst/doc’ ... WARNING
>>>
>>> Package vignettes without corresponding PDF/HTML:
>>>
>>>‘design-principles.Rmd’
>>>
>>>‘huxreg.Rmd’
>>>
>>>‘huxtable.Rmd’
>>>
>>> So, the warning does not seem to be related to the presence of HTML files
>>> in vignettes.
>>>
>>> I also tried manually removing .Rmd files from inst/doc (leaving them
>>> only
>>> in vignettes) but this still gave the same error.
>>>
>>> My goal here is that for package-specific reasons, I would like both pdf
>>> and HTML versions of my vignettes to be available (I am writing code that
>>> prints HTML and LaTeX tables and want my users to have examples of how
>>> both
>>> output formats work). This is why I build those files manually, and place
>>> them in inst/doc.
>>>
>>> Side comment: at the moment, I feel as if I am running through the
>>> combinatorics of including and excluding files from vignettes and
>>> inst/doc,
>>> without much insight into what I am doing. Would it be fair to say that
>>> the
>>> current system is not very easy to comprehend?
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 19 April 2017 at 21:24, Duncan Murdoch <murdoch.dun...@gmail.com>
>>> wrote:
>>>
>>> On 19/04/2017 1:00 PM, David Hugh-Jones wrote:
>>>>
>>>> Hi Uwe,
>>>>>
>>>>> I'm not sure if you ever got my off-list message with my tarball or
>>>>> subsequent messages. I can't send a tarball on-list - it gets rejected
>>>>> as
>>>>> too large - but here is a dropbox link. If you could confirm receipt,
>>>>> that
>>>>> would be extremely helpful!
>>>>>
>>>>> https://www.dropbox.com/s/179jrm19kx9o7dz/huxtable_0.2.0.tar.gz?dl=0
>>>>>
>>>>>
>>>>> Not sure if Uwe has had a chance to look, but I just ran R CMD check on
>>>> your tarball using the latest version of R-devel.  It reported the
>>>> following problems:
>>>>
>>>> * checking CRAN incoming feasibility ... NOTE
>>>> Maintainer: ‘David Hugh-Jones <davidhughjo...@gmail.com>’
>>>>
>>>> Found the following (possibly) invalid URLs:
>>>>   URL: http://cran.rstudio.com/web/packages/huxtable/index.html
>>>> From: README.md
>>>> CRAN URL not in canonical form
>>>>   Canonical CRAN.

Re: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Hi Duncan,

Thank you very much for taking the time to look at this.

I tried rebuilding the tar file so as to include only the .Rmd files, not
the HTML files, in 'vignettes':

drwxr-xr-x  0 david  staff   0 20 Apr 09:21 huxtable/vignettes/

-rw-r--r--  0 david  staff1633  6 Apr 16:26
huxtable/vignettes/comparison.csv

-rw-r--r--  0 david  staff6697  6 Apr 14:44
huxtable/vignettes/design-principles.Rmd

-rw-r--r--  0 david  staff5521  6 Apr 14:30
huxtable/vignettes/huxreg.Rmd

-rw-r--r--  0 david  staff   20552  6 Apr 16:19
huxtable/vignettes/huxtable.Rmd

-rw-r--r--  0 david  staff  22 17 Mar 00:19
huxtable/vignettes/placeins-header.tex


But when I run R CMD check, I still get the same warning:

* checking package vignettes in ‘inst/doc’ ... WARNING

Package vignettes without corresponding PDF/HTML:

   ‘design-principles.Rmd’

   ‘huxreg.Rmd’

   ‘huxtable.Rmd’

So, the warning does not seem to be related to the presence of HTML files
in vignettes.

I also tried manually removing .Rmd files from inst/doc (leaving them only
in vignettes) but this still gave the same error.

My goal here is that for package-specific reasons, I would like both pdf
and HTML versions of my vignettes to be available (I am writing code that
prints HTML and LaTeX tables and want my users to have examples of how both
output formats work). This is why I build those files manually, and place
them in inst/doc.

Side comment: at the moment, I feel as if I am running through the
combinatorics of including and excluding files from vignettes and inst/doc,
without much insight into what I am doing. Would it be fair to say that the
current system is not very easy to comprehend?

Cheers,

David

On 19 April 2017 at 21:24, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:

> On 19/04/2017 1:00 PM, David Hugh-Jones wrote:
>
>> Hi Uwe,
>>
>> I'm not sure if you ever got my off-list message with my tarball or
>> subsequent messages. I can't send a tarball on-list - it gets rejected as
>> too large - but here is a dropbox link. If you could confirm receipt, that
>> would be extremely helpful!
>>
>> https://www.dropbox.com/s/179jrm19kx9o7dz/huxtable_0.2.0.tar.gz?dl=0
>>
>>
> Not sure if Uwe has had a chance to look, but I just ran R CMD check on
> your tarball using the latest version of R-devel.  It reported the
> following problems:
>
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: ‘David Hugh-Jones <davidhughjo...@gmail.com>’
>
> Found the following (possibly) invalid URLs:
>   URL: http://cran.rstudio.com/web/packages/huxtable/index.html
> From: README.md
> CRAN URL not in canonical form
>   Canonical CRAN.R-project.org URLs use https.
>
> The URL for your package should be in the form
>
> https://CRAN.R-project.org/package=huxtable
>
> * checking top-level files ... NOTE
> Non-standard file/directory found at top level:
>   ‘multirow.rds’
>
> I'm not sure where that file belongs, but not there.
>
> * checking files in ‘vignettes’ ... WARNING
> Files in the 'vignettes' directory newer than all files in 'inst/doc':
>   ‘huxreg.html’, ‘huxtable.html’
>
> Those files shouldn't be in the vignettes directory, they are products of
> building the vignettes.  Only the source should normally be in the
> vignettes directory.
>
> * checking package vignettes in ‘inst/doc’ ... WARNING
> Package vignettes without corresponding PDF/HTML:
>‘design-principles.Rmd’
>‘huxreg.Rmd’
>‘huxtable.Rmd’
>
> I think this is the warning you were asking about.  If I look at just the
> first of those files, I see that design-principles.Rmd exists in vignettes
> and is set to produce PDF output (only the first output entry in the YAML
> counts).  You also have a .html file in vignettes; it shouldn't be there.
> In inst/doc, you have source, .html and .pdf versions of that file.
>
> The warning isn't very helpful, but I think it is triggered by the fact
> that you've got the .html file in your vignettes directory.  If I remove
> everything but the source from that directory, and everything from the
> inst/doc directory, then all the vignette warnings go away.
>
> (I haven't traced through the code, but I think the warning may be
> literally correct.  Since you had .html files that looked like vignette
> outputs but weren't, you have vignettes without *corresponding* HTML. It
> would have been nicer if it suggested how to fix this, but that vignette
> code is quite tricky, because any file could be source, and any html, tex
> or pdf file could be output.  At some point I may try to clean it up a bit
> and then maybe the error messages will be less obscure.)
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Hi Uwe,

I'm not sure if you ever got my off-list message with my tarball or
subsequent messages. I can't send a tarball on-list - it gets rejected as
too large - but here is a dropbox link. If you could confirm receipt, that
would be extremely helpful!

https://www.dropbox.com/s/179jrm19kx9o7dz/huxtable_0.2.0.tar.gz?dl=0

Cheers,
David Hugh-Jones


On 7 April 2017 at 11:20, Uwe Ligges <lig...@statistik.tu-dortmund.de>
wrote:

> Can you send the tarball please, I can take a look,
>
>> Uwe
>
>>
>>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Hi Berry,

Good call, and I would have been very embarrassed if so, but no. Actually,
if they had been, I guess they would not have appeared in the tarball.

Cheers,
David

On 10 April 2017 at 14:57, Berry Boessenkool <berryboessenk...@hotmail.com>
wrote:

>
> The "missing" files or their directory are not by accident listed in
> Rbuildignore, right?
>
>
>
> 
> From: R-package-devel <r-package-devel-boun...@r-project.org> on behalf
> of Uwe Ligges <lig...@statistik.tu-dortmund.de>
> Sent: Friday, April 7, 2017 12:20
> To: David Hugh-Jones
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] R CMD check not finding my vignettes
>
> Can you send the tarball please, I can take a look,
> Uwe
>
>
> On 07.04.2017 12:09, David Hugh-Jones wrote:
> > Hi Uwe,
> >
> > Indeed yes, but my built tarball has got the files in inst/doc as shown.
> > If I then run 'R CMD check' on that tarball, I get the error quoted. Is
> > there something happening that I don't understand?
> >
> > Incidentally, the tarball also has files in the vignettes directory: (a)
> > the original .Rmd files and (b) HTML files. My original directory has
> > all of Rmd, HTML and PDF files in the vignettes directory, but for some
> > reason the PDFs don't get included when the tarball is built.
> >
> > Cheers,
> > David
> >
> > David
> >
> > On 7 April 2017 at 07:15, Uwe Ligges <lig...@statistik.tu-dortmund.de
> > <mailto:lig...@statistik.tu-dortmund.de>> wrote:
> >
> > I do not know devtools, but the vignette sources should be placed in
> > ./vignettes and then R CMD build will put the files into the
> > relevant places automatically.
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >
> >
> >
> > On 07.04.2017 07:55, David Hugh-Jones wrote:
> >
> >  Okay, so this got tumbleweeded... so should I file a bug?
> >
> > D
> >
> > On Thu, 6 Apr 2017 at 15:37, David Hugh-Jones
> > <davidhughjo...@gmail.com <mailto:davidhughjo...@gmail.com>>
> > wrote:
> >
> >
> > Before building my package, I manually place both pdf and
> > html versions of
> > my vignettes into inst/doc. I then build the package with
> > `devtools::check`.
> >
> > Listing of the resulting tarball:
> >
> > -rw-r--r--  0 david  staff1692  6 Apr 15:10
> > huxtable/inst/doc/design-principles.R
> >
> > -rw-r--r--  0 david  staff6697  6 Apr 15:10
> > huxtable/inst/doc/design-principles.Rmd
> >
> > -rw-r--r--  0 david  staff  899765  6 Apr 15:10
> > huxtable/inst/doc/design-principles.html
> >
> > -rw-r--r--  0 david  staff  213776  6 Apr 15:10
> > huxtable/inst/doc/design-principles.pdf
> >
> > -rw-r--r--  0 david  staff3009  6 Apr 15:10
> > huxtable/inst/doc/huxreg.R
> >
> > -rw-r--r--  0 david  staff5521  6 Apr 15:10
> > huxtable/inst/doc/huxreg.Rmd
> >
> > -rw-r--r--  0 david  staff  940955  6 Apr 15:10
> > huxtable/inst/doc/huxreg.html
> >
> > -rw-r--r--  0 david  staff  237771  6 Apr 15:10
> > huxtable/inst/doc/huxreg.pdf
> >
> > -rw-r--r--  0 david  staff   10473  6 Apr 15:11
> > huxtable/inst/doc/huxtable.R
> >
> > -rw-r--r--  0 david  staff   20552  6 Apr 15:11
> > huxtable/inst/doc/huxtable.Rmd
> >
> > -rw-r--r--  0 david  staff  925373  6 Apr 15:11
> > huxtable/inst/doc/huxtable.html
> >
> > -rw-r--r--  0 david  staff  284978  6 Apr 15:11
> > huxtable/inst/doc/huxtable.pdf
> >
> > However, R CMD check then complains:
> >
> > * checking package vignettes in ‘inst/doc’ ... WARNING
> > Package vignettes without corresponding PDF/HTML:
> >‘design-principles.Rmd’
> >‘huxreg.Rmd’
> >‘huxtable.Rmd’
> >
> > What gives?
> >
> > Cheers,
> > David
> >
> >
>
> __
> 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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Hi Uwe,

Indeed yes, but my built tarball has got the files in inst/doc as shown. If
I then run 'R CMD check' on that tarball, I get the error quoted. Is there
something happening that I don't understand?

Incidentally, the tarball also has files in the vignettes directory: (a)
the original .Rmd files and (b) HTML files. My original directory has all
of Rmd, HTML and PDF files in the vignettes directory, but for some reason
the PDFs don't get included when the tarball is built.

Cheers,
David

David

On 7 April 2017 at 07:15, Uwe Ligges <lig...@statistik.tu-dortmund.de>
wrote:

> I do not know devtools, but the vignette sources should be placed in
> ./vignettes and then R CMD build will put the files into the relevant
> places automatically.
>
> Best,
> Uwe Ligges
>
>
>
>
>
>
> On 07.04.2017 07:55, David Hugh-Jones wrote:
>
>>  Okay, so this got tumbleweeded... so should I file a bug?
>>
>> D
>>
>> On Thu, 6 Apr 2017 at 15:37, David Hugh-Jones <davidhughjo...@gmail.com>
>> wrote:
>>
>>
>>> Before building my package, I manually place both pdf and html versions
>>> of
>>> my vignettes into inst/doc. I then build the package with
>>> `devtools::check`.
>>>
>>> Listing of the resulting tarball:
>>>
>>> -rw-r--r--  0 david  staff1692  6 Apr 15:10
>>> huxtable/inst/doc/design-principles.R
>>>
>>> -rw-r--r--  0 david  staff6697  6 Apr 15:10
>>> huxtable/inst/doc/design-principles.Rmd
>>>
>>> -rw-r--r--  0 david  staff  899765  6 Apr 15:10
>>> huxtable/inst/doc/design-principles.html
>>>
>>> -rw-r--r--  0 david  staff  213776  6 Apr 15:10
>>> huxtable/inst/doc/design-principles.pdf
>>>
>>> -rw-r--r--  0 david  staff3009  6 Apr 15:10
>>> huxtable/inst/doc/huxreg.R
>>>
>>> -rw-r--r--  0 david  staff5521  6 Apr 15:10
>>> huxtable/inst/doc/huxreg.Rmd
>>>
>>> -rw-r--r--  0 david  staff  940955  6 Apr 15:10
>>> huxtable/inst/doc/huxreg.html
>>>
>>> -rw-r--r--  0 david  staff  237771  6 Apr 15:10
>>> huxtable/inst/doc/huxreg.pdf
>>>
>>> -rw-r--r--  0 david  staff   10473  6 Apr 15:11
>>> huxtable/inst/doc/huxtable.R
>>>
>>> -rw-r--r--  0 david  staff   20552  6 Apr 15:11
>>> huxtable/inst/doc/huxtable.Rmd
>>>
>>> -rw-r--r--  0 david  staff  925373  6 Apr 15:11
>>> huxtable/inst/doc/huxtable.html
>>>
>>> -rw-r--r--  0 david  staff  284978  6 Apr 15:11
>>> huxtable/inst/doc/huxtable.pdf
>>>
>>> However, R CMD check then complains:
>>>
>>> * checking package vignettes in ‘inst/doc’ ... WARNING
>>> Package vignettes without corresponding PDF/HTML:
>>>‘design-principles.Rmd’
>>>‘huxreg.Rmd’
>>>‘huxtable.Rmd’
>>>
>>> What gives?
>>>
>>> Cheers,
>>> David
>>>
>>>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

 Okay, so this got tumbleweeded... so should I file a bug?

D

On Thu, 6 Apr 2017 at 15:37, David Hugh-Jones <davidhughjo...@gmail.com>
wrote:

>
> Before building my package, I manually place both pdf and html versions of
> my vignettes into inst/doc. I then build the package with `devtools::check`.
>
> Listing of the resulting tarball:
>
> -rw-r--r--  0 david  staff1692  6 Apr 15:10
> huxtable/inst/doc/design-principles.R
>
> -rw-r--r--  0 david  staff6697  6 Apr 15:10
> huxtable/inst/doc/design-principles.Rmd
>
> -rw-r--r--  0 david  staff  899765  6 Apr 15:10
> huxtable/inst/doc/design-principles.html
>
> -rw-r--r--  0 david  staff  213776  6 Apr 15:10
> huxtable/inst/doc/design-principles.pdf
>
> -rw-r--r--  0 david  staff3009  6 Apr 15:10 huxtable/inst/doc/huxreg.R
>
> -rw-r--r--  0 david  staff5521  6 Apr 15:10
> huxtable/inst/doc/huxreg.Rmd
>
> -rw-r--r--  0 david  staff  940955  6 Apr 15:10
> huxtable/inst/doc/huxreg.html
>
> -rw-r--r--  0 david  staff  237771  6 Apr 15:10
> huxtable/inst/doc/huxreg.pdf
>
> -rw-r--r--  0 david  staff   10473  6 Apr 15:11
> huxtable/inst/doc/huxtable.R
>
> -rw-r--r--  0 david  staff   20552  6 Apr 15:11
> huxtable/inst/doc/huxtable.Rmd
>
> -rw-r--r--  0 david  staff  925373  6 Apr 15:11
> huxtable/inst/doc/huxtable.html
>
> -rw-r--r--  0 david  staff  284978  6 Apr 15:11
> huxtable/inst/doc/huxtable.pdf
>
> However, R CMD check then complains:
>
> * checking package vignettes in ‘inst/doc’ ... WARNING
> Package vignettes without corresponding PDF/HTML:
>‘design-principles.Rmd’
>‘huxreg.Rmd’
>‘huxtable.Rmd’
>
> What gives?
>
> Cheers,
> David
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] R CMD check not finding my vignettes

[David Hugh-Jones]

Before building my package, I manually place both pdf and html versions of
my vignettes into inst/doc. I then build the package with `devtools::check`.

Listing of the resulting tarball:

-rw-r--r--  0 david  staff1692  6 Apr 15:10
huxtable/inst/doc/design-principles.R

-rw-r--r--  0 david  staff6697  6 Apr 15:10
huxtable/inst/doc/design-principles.Rmd

-rw-r--r--  0 david  staff  899765  6 Apr 15:10
huxtable/inst/doc/design-principles.html

-rw-r--r--  0 david  staff  213776  6 Apr 15:10
huxtable/inst/doc/design-principles.pdf

-rw-r--r--  0 david  staff3009  6 Apr 15:10 huxtable/inst/doc/huxreg.R

-rw-r--r--  0 david  staff5521  6 Apr 15:10 huxtable/inst/doc/huxreg.Rmd

-rw-r--r--  0 david  staff  940955  6 Apr 15:10
huxtable/inst/doc/huxreg.html

-rw-r--r--  0 david  staff  237771  6 Apr 15:10 huxtable/inst/doc/huxreg.pdf

-rw-r--r--  0 david  staff   10473  6 Apr 15:11 huxtable/inst/doc/huxtable.R

-rw-r--r--  0 david  staff   20552  6 Apr 15:11
huxtable/inst/doc/huxtable.Rmd

-rw-r--r--  0 david  staff  925373  6 Apr 15:11
huxtable/inst/doc/huxtable.html

-rw-r--r--  0 david  staff  284978  6 Apr 15:11
huxtable/inst/doc/huxtable.pdf

However, R CMD check then complains:

* checking package vignettes in ‘inst/doc’ ... WARNING
Package vignettes without corresponding PDF/HTML:
   ‘design-principles.Rmd’
   ‘huxreg.Rmd’
   ‘huxtable.Rmd’

What gives?

Cheers,
David

[[alternative HTML version deleted]]

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