[R-pkg-devel] ω, α, η, ² in .Rd files
hi,
i'm trying to include some greek characters in my package documentation,
but am having difficulty getting it to work on windows. it works find on
macOS, linux, but throws errors on windows:
https://win-builder.r-project.org/guwReC6lhQaU/00check.log
so far i have tried:
ω
\u03C9
\omega
\eqn{\omega}
\symbol{"03C9}
\enc{ω}{omega}
i have `Encoding: UTF-8` specified in my DESCRIPTION
i have read:
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Encoding-issues
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Encoding
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Insertions
any tips on how to get these symbols into documentation on windows? i'd
even by happy with it just saying 'omega' on windows (which is what i
thought \enc{}{} was supposed to do).
apparently i'm missing something.
with thanks
jonathon
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ω, α, η, ² in .Rd files
hi uwe,
On 10/2/17 23:40, Uwe Ligges wrote:
On 10.02.2017 03:19, Jonathon Love wrote:
hi,
i'm trying to include some greek characters in my package documentation,
but am having difficulty getting it to work on windows. it works find on
macOS, linux, but throws errors on windows:
https://win-builder.r-project.org/guwReC6lhQaU/00check.log
so far i have tried:
ω
\u03C9
\omega
\eqn{\omega}
\symbol{"03C9}
\enc{ω}{omega}
The latter is right in principle, but two issues:
1- you use it in an .R file which should no assume a special encoding.
I do not use roxygen2, hence don't know how it can work at all, I'd
simply do it in the Rd file directly.
2- Thge LaTeX version on winbuilder cannot deal with an UTF-8 omega
symbol. Hence I'd rather write
\eqn{\omega}{omega}
or to square it:
\eqn{\omega^2}{omega^2}
thanks for explaining this
unfortunately this doesn't work with the html or plain-text help (i
assume it does work with the PDF manuals). in the html/plain text help,
it always puts the plain ascii 'omega', rather than the actual symbol.
so it's seeming like it's not possible to have special chars in the html
or plain-text help, without upsetting the winbuilder?
if i have to use the plain ascii 'omega', 'eta', 'alpha', it won't be
the end of the world.
with thanks
jonathon
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ω, α, η, ² in .Rd files
hi duncan,
On 11/2/17 01:44, Duncan Murdoch wrote:
On 10/02/2017 8:52 AM, Jonathon Love wrote:
hi uwe,
On 10/2/17 23:40, Uwe Ligges wrote:
On 10.02.2017 03:19, Jonathon Love wrote:
hi,
i'm trying to include some greek characters in my package
documentation,
but am having difficulty getting it to work on windows. it works
find on
macOS, linux, but throws errors on windows:
https://win-builder.r-project.org/guwReC6lhQaU/00check.log
so far i have tried:
ω
\u03C9
\omega
\eqn{\omega}
\symbol{"03C9}
\enc{ω}{omega}
The latter is right in principle, but two issues:
1- you use it in an .R file which should no assume a special encoding.
I do not use roxygen2, hence don't know how it can work at all, I'd
simply do it in the Rd file directly.
2- Thge LaTeX version on winbuilder cannot deal with an UTF-8 omega
symbol. Hence I'd rather write
\eqn{\omega}{omega}
or to square it:
\eqn{\omega^2}{omega^2}
thanks for explaining this
unfortunately this doesn't work with the html or plain-text help (i
assume it does work with the PDF manuals). in the html/plain text help,
it always puts the plain ascii 'omega', rather than the actual symbol.
so it's seeming like it's not possible to have special chars in the html
or plain-text help, without upsetting the winbuilder?
if i have to use the plain ascii 'omega', 'eta', 'alpha', it won't be
the end of the world.
I suspect you are making things harder for yourself by using Roxygen2.
As Uwe and the manual say, .R files need to be plain ASCII to be
portable. You can include Unicode escapes in strings.
yup, although if the encoding of the comments in the .R files are
completely misunderstood by system, it shouldn't make any difference to
the resultant package. Or is there a way that it could interfere?
of course, the CRAN checks are unlikely to appreciate this subtlety, so
i guess i'm on the hook there.
Perhaps Roxygen2 has some way to process Unicode escapes in comments;
you'll have to ask its authors. If you include raw UTF-8 characters
in the comments, they'll be processed differently in UTF-8 locales
versus others. So you might get away with doing this if Roxygen2
always runs in a UTF-8 locale, but on Windows you will see problems.
yup, i'd reached these conclusions - but always helpful to have someone
else spell things out.
with thanks
jonathon
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ω, α, η, ² in .Rd files
hi duncan, yup, although if the encoding of the comments in the .R files are completely misunderstood by system, it shouldn't make any difference to the resultant package. Or is there a way that it could interfere? Roxygen2 will take the comments and write out .Rd files. Those files need to be written in ASCII, or the declared encoding of the package, not of the locale where Roxygen2 was run. (R and CRAN know nothing about Roxygen2, they just look at the Rd files as though they were written by you.) So I think it should be possible for all of this to work: If you write your comments in UTF-8 and declare that as the encoding of the package, then Roxygen2 should read the .R files as UTF-8 files, and write out UTF-8 Rd files, regardless of the locale. But encodings of strings go through several translations internally in R, so there may be some step there that loses the original intent. And Roxygen2 may be just ignoring encodings, which would almost certainly go badly. yup, this all works as you describe. the only wrinkle is that the CRAN checks on windows don't like non-ascii characters appearing in the .R files (which they would if one puts special chars in one's roxygen annotations). cheers jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] UseR! Session: Navigating the jungle of R packages.
hi, first up let me apologise for breaking the thread. i subscribed to this list after the initial email went out. i'm not completely sure if the original post was to prompt a discussion here, but now there's a discussion, i'm jumping in! i'm a psychologist, and one of the challenges is the number of packages required to do what is "standard practice", and getting them all to work together. to do an ANOVA (the bread and butter of psych research) with all it's assumption checks, contrasts, corrections, etc. requires in the order of seven packages. our solution to this is to create an "uber" package, which makes use of all these things behind a single function call (with many arguments), which is what our jmv package is: https://www.jamovi.org/jmv/ we represent an extreme, we even handle plots, but there are other examples of more intermediate solutions: afex, psych, etc. i appreciate this is somewhat at odds with (what i perceive to be) the R ethos, which is giving people very fine control over the intermediate parts of one's analysis, but it is another approach to making it easier for people to find appropriate tools for their field. for me, the key is being "goal-centred", "what is a person in my field trying to achieve?" rather than "analysis-centred"; "this package provides analysis X" ... but i appreciate this is likely an unpopular position. i'll definitely be attending this session at use!R, and happy to espouse more unpopular views cheers jonathon Navigating the Jungle of R Packages The R ecosystem has many packages in various collections, especially CRAN, Bioconductor, and GitHub. While this richness of choice speaks to the popularity and importance of R, the large number of contributed packages makes it difficult for users to find appropriate tools for their work. A session on this subject has been approved for UseR! in Brussels. The tentative structure is three short introductory presentations, followed by discussion or planning work to improve the tools available to help users find the best R package and function for their needs. The currently proposed topics are - wrapper packages that allow diverse tools that perform similar functions to be accessed by unified calls - collaborative mechanisms to create and update Task Views - search and sort tools to find packages. At the time of writing we have tentative presenters for the topics, but welcome others. We hope these presentations at useR! 2017 will be part of a larger discussion that will contribute to an increased team effort after the conference to improve the the support for R users in these areas. John Nash, Julia Silge, Spencer Graves __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Library not loaded ‘libgdal.dylib’ when building package on travis (osx)
hi, On 29/4/17 21:29, Patrick Schratz wrote: Nope, still an open issue. I also do not have any ideas left what I could try next. Tried the export hints (e.g. bash profile) given in 'brew info gdal2' and checked with my local configuration but I do not see what the possible issue could be here. On 29. Apr 2017, 13:24 +0200, Alexandre Courtiol , wrote: Did you already sort out your issue? On 28 April 2017 at 17:19, Patrick Schratz mailto:patrick.schr...@gmail.com)> wrote: Hi everyone, the following error gives me headaches. When building my package on Travis CI (OS X build), I get the following error: Building with: R CMD build 4.64s$ R CMD build . * checking for file ‘./DESCRIPTION’ ... OK * preparing ‘RQGIS’: * checking DESCRIPTION meta-information ... OK * installing the package to build vignettes --- * installing *source* package ‘RQGIS’ ... ** R ** data *** moving datasets to lazyload DB ** inst ** byte-compile and prepare package for lazy loading Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/Users/travis/R/Library/rgdal/libs/rgdal.so': dlopen(/Users/travis/R/Library/rgdal/libs/rgdal.so, 6): Library not loaded: /Builds/unix/recipes/build/gdal-2.1.3-obj/libgdal.dylib Referenced from: /Users/travis/R/Library/rgdal/libs/rgdal.so Reason: image not found it looks to me that rgdal.so is looking for libgdal.dylib in /Builds/unix/recipes/build/build/gdal02.1.3-obj you can confirm this with the command: otool -L /Users/travis/R/Library/rgdal/libs/rgdal.so it will list where it's expecting to find libgdal.dylib my guess is that the root of the issue is that the libgdal.dylib that rgdal.so linked against, thinks that it lives at /Builds/unix/recipes/build/build/gdal02.1.3-obj you can confirm this with: otool -L /Builds/unix/recipes/build/gdal-2.1.3-obj/libgdal.dylib you can change where .so's and .dylibs think they live, and where they think their dependencies live with the install_name_tool tool. i can walk you through this off-list if you need. cheers jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R package test breakage catch 22
hi, i currently face the following situation: my package, package A, depends on package B. i have unit tests in package A which expect results, which are in part as a result of calculations from package B. package B has made some changes, which leads to slightly different results being calculated, and now package A tests fail. now it turns out that the CRAN submission process has picked up that the new B, causes tests to fail on A, and so B can't be accepted by CRAN. now i can update my tests so they expect the *new* values, but obviously these will fail and won't be accepted by CRAN, because the new B isn't on CRAN yet. i can't update A because of old B, and B can't be updated because of old A. how does one solve this catch-22? with thanks jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] package installation fails due to missing package not listed in NAMESPACE
hi, i'm receiving failures on the winbuilder, with it complaining that ggplot2 can not be found: https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out now there are some mentions of ggplot2 in our code (but none in our NAMESPACE, we always use the full namespace when calling functions: `ggplot2::ggplot()`), allowing people to pass in ggplot2 themes and for them to be handled correctly, but packages that build on jmvcore don't *need* to use ggplot2. so we've been able to avoid adding it as an import, which is great, because ggplot2 brings quite a few dependencies. our code works as intended, passes all tests with `R CMD check --as-cran jmvcore`, etc. however the win-builder is pinging us. is there a way around this? with thanks jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package installation fails due to missing package not listed in NAMESPACE
yes, sorry, crucial piece of information i forgot to mention. ggplot2 *is* in suggests. with thanks jonathon On 16/5/17 21:21, Thierry Onkelinx wrote: > Dear Jonathon, > > Is ggplot2 listed in the DESCRIPTION file? It needs to be at least in > the Suggests: > > Best regards, > > Thierry > > ir. Thierry Onkelinx > Instituut voor natuur- en bosonderzoek / Research Institute for Nature > and Forest > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > Kliniekstraat 25 > 1070 Anderlecht > Belgium > > To call in the statistician after the experiment is done may be no > more than asking him to perform a post-mortem examination: he may be > able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does > not ensure that a reasonable answer can be extracted from a given body > of data. ~ John Tukey > > 2017-05-16 13:12 GMT+02:00 Jonathon Love <mailto:j...@thon.cc>>: > > hi, > > i'm receiving failures on the winbuilder, with it complaining that > ggplot2 can not be found: > > > https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out > > <https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out> > > now there are some mentions of ggplot2 in our code (but none in > our NAMESPACE, we always use the full namespace when calling > functions: `ggplot2::ggplot()`), allowing people to pass in > ggplot2 themes and for them to be handled correctly, but packages > that build on jmvcore don't *need* to use ggplot2. so we've been > able to avoid adding it as an import, which is great, because > ggplot2 brings quite a few dependencies. > > our code works as intended, passes all tests with `R CMD check > --as-cran jmvcore`, etc. > > however the win-builder is pinging us. > > is there a way around this? > > with thanks > > jonathon > > __ > 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> > > [[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 installation fails due to missing package not listed in NAMESPACE
hi,
this doesn't seem to make any difference.
but we kinda want the opposite of this. we want the install process to
know that ggplot2 isn't required.
with thanks
jonathon
On 16/5/17 21:34, Thierry Onkelinx wrote:
> Try adding requireNamespace("ggplot2") in the function that rely on
> ggplot2.
>
> ir. Thierry Onkelinx
> Instituut voor natuur- en bosonderzoek / Research Institute for Nature
> and Forest
> team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
> Kliniekstraat 25
> 1070 Anderlecht
> Belgium
>
> To call in the statistician after the experiment is done may be no
> more than asking him to perform a post-mortem examination: he may be
> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does
> not ensure that a reasonable answer can be extracted from a given body
> of data. ~ John Tukey
>
> 2017-05-16 13:22 GMT+02:00 Jonathon Love <mailto:j...@thon.cc>>:
>
> yes, sorry, crucial piece of information i forgot to mention.
>
> ggplot2 *is* in suggests.
>
> with thanks
>
> jonathon
>
>
> On 16/5/17 21:21, Thierry Onkelinx wrote:
> > Dear Jonathon,
> >
> > Is ggplot2 listed in the DESCRIPTION file? It needs to be at
> least in
> > the Suggests:
> >
> > Best regards,
> >
> > Thierry
> >
> > ir. Thierry Onkelinx
> > Instituut voor natuur- en bosonderzoek / Research Institute for
> Nature
> > and Forest
> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality
> Assurance
> > Kliniekstraat 25
> > 1070 Anderlecht
> > Belgium
> >
> > To call in the statistician after the experiment is done may be no
> > more than asking him to perform a post-mortem examination: he may be
> > able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
> > The plural of anecdote is not data. ~ Roger Brinner
> > The combination of some data and an aching desire for an answer does
> > not ensure that a reasonable answer can be extracted from a
> given body
> > of data. ~ John Tukey
> >
> > 2017-05-16 13:12 GMT+02:00 Jonathon Love > <mailto:j...@thon.cc <mailto:j...@thon.cc>>>:
> >
> > hi,
> >
> > i'm receiving failures on the winbuilder, with it
> complaining that
> > ggplot2 can not be found:
> >
> >
>
> https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out
>
> <https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out>
> >
>
> <https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out
>
> <https://win-builder.r-project.org/incoming_pretest/170516_125043_jmvcore_055/00install.out>>
> >
> > now there are some mentions of ggplot2 in our code (but none in
> > our NAMESPACE, we always use the full namespace when calling
> > functions: `ggplot2::ggplot()`), allowing people to pass in
> > ggplot2 themes and for them to be handled correctly, but
> packages
> > that build on jmvcore don't *need* to use ggplot2. so we've been
> > able to avoid adding it as an import, which is great, because
> > ggplot2 brings quite a few dependencies.
> >
> > our code works as intended, passes all tests with `R CMD check
> > --as-cran jmvcore`, etc.
> >
> > however the win-builder is pinging us.
> >
> > is there a way around this?
> >
> > with thanks
> >
> > jonathon
> >
> > __
> > R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
> > <mailto: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>
> > <https://stat.ethz.ch/mailman/listinfo/r-package-devel
> <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
> <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 installation fails due to missing package not listed in NAMESPACE
awesome! works a treat.
with thanks
jonathon
On 16/5/17 21:53, Duncan Murdoch wrote:
On 16/05/2017 7:34 AM, Thierry Onkelinx wrote:
Try adding requireNamespace("ggplot2") in the function that rely on
ggplot2.
That's not enough, even though it might fool the test (I haven't
checked). Those functions need to condition on the result, i.e.
something like
if (requireNamespace("ggplot2")) ggplot2::ggplot()
else ... (optional warning that you need it) ...
Duncan Murdoch
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for
Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able
to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of
data.
~ John Tukey
2017-05-16 13:22 GMT+02:00 Jonathon Love :
yes, sorry, crucial piece of information i forgot to mention.
ggplot2 *is* in suggests.
with thanks
jonathon
On 16/5/17 21:21, Thierry Onkelinx wrote:
Dear Jonathon,
Is ggplot2 listed in the DESCRIPTION file? It needs to be at least in
the Suggests:
Best regards,
Thierry
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature
and Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given body
of data. ~ John Tukey
2017-05-16 13:12 GMT+02:00 Jonathon Love mailto:j...@thon.cc>>:
hi,
i'm receiving failures on the winbuilder, with it complaining that
ggplot2 can not be found:
https://win-builder.r-project.org/incoming_pretest/170516_
125043_jmvcore_055/00install.out
<https://win-builder.r-project.org/incoming_pretest/
170516_125043_jmvcore_055/00install.out>
now there are some mentions of ggplot2 in our code (but none in
our NAMESPACE, we always use the full namespace when calling
functions: `ggplot2::ggplot()`), allowing people to pass in
ggplot2 themes and for them to be handled correctly, but packages
that build on jmvcore don't *need* to use ggplot2. so we've been
able to avoid adding it as an import, which is great, because
ggplot2 brings quite a few dependencies.
our code works as intended, passes all tests with `R CMD check
--as-cran jmvcore`, etc.
however the win-builder is pinging us.
is there a way around this?
with thanks
jonathon
__
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>
[[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] unusually slow tests on win-builder
hi, i've uploaded a version of my package to the win-builder service, but it is reporting that one of my tests takes > 10 seconds to run. examining the log here: https://win-builder.r-project.org/BvR4nreDE9qP/00check.log the win-builder is taking 24 and 28 seconds to run this test. on my local machine, this same test runs in 600ms can anyone shed any light on this? why is the win-builder so slow? with thanks jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] unusually slow tests on win-builder
hi dason, yes, it looks like it's taking 10 seconds. 10 seconds still seems unusually long, and a lot longer than 600ms. any other suggestions as to what might be going on here? with thanks jonathon On 5/6/17 22:36, Dason Kurkiewicz wrote: The relevant output is below: * checking examples ... ** running examples for arch 'i386' ... [24s] NOTE Examples with CPU or elapsed time > 10s user system elapsed cfa 8.05 0.36 10.08 ** running examples for arch 'x64' ... [28s] NOTE Examples with CPU or elapsed time > 10s user system elapsed cfa 10.62 0.23 12 * checking for unstated dependencies in 'tests' ... OK * checking tests ... ** running tests for arch 'i386' ... [25s] OK Running 'testthat.R' [24s] ** running tests for arch 'x64' ... [32s] OK Running 'testthat.R' [31s] I'm not sure why you're saying it's taking too long to run your tests when the output is telling you that it's your examples that are taking too long to run. It's also not taking 24 and 28 seconds - I believe that is just a timestamp telling you that it's producing that note 24 and 28 seconds into the check but I could be wrong. Either way the relevant output for how long the examples take look like: user system elapsed cfa 8.05 0.36 10.08 That which tells you total it took 10.08 seconds to run the examples for arch 'i386'. -Dason Kurkiewicz On Mon, Jun 5, 2017 at 8:23 AM, Jonathon Love wrote: hi, i've uploaded a version of my package to the win-builder service, but it is reporting that one of my tests takes > 10 seconds to run. examining the log here: https://win-builder.r-project.org/BvR4nreDE9qP/00check.log the win-builder is taking 24 and 28 seconds to run this test. on my local machine, this same test runs in 600ms can anyone shed any light on this? why is the win-builder so slow? with thanks jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] unusually slow tests on win-builder
So your windows installation of R-3.4.0 can solve this in 600ms? Or is yoiur another OS? ah, yes, another OS. it turns out on windows this takes 6 seconds. the issue is that we only load imports on demand (not in our NAMESPACE), there's a behemoth dependency chain that that analysis invokes, and package loading appears to be *quite a bit* slower on windows than macOS/linux. with thanks jonathon For winbuilder, it could be it was heavily loaded, but even then it should never take more than twice as long as on an idling machine. Then winbuilder has server CPUs with lots of cores hence operates at a lower frequency, altogether not more than 3-4 times the the time you got can be expected. Best, Uwe Ligges any other suggestions as to what might be going on here? with thanks jonathon On 5/6/17 22:36, Dason Kurkiewicz wrote: The relevant output is below: * checking examples ... ** running examples for arch 'i386' ... [24s] NOTE Examples with CPU or elapsed time > 10s user system elapsed cfa 8.05 0.36 10.08 ** running examples for arch 'x64' ... [28s] NOTE Examples with CPU or elapsed time > 10s user system elapsed cfa 10.62 0.23 12 * checking for unstated dependencies in 'tests' ... OK * checking tests ... ** running tests for arch 'i386' ... [25s] OK Running 'testthat.R' [24s] ** running tests for arch 'x64' ... [32s] OK Running 'testthat.R' [31s] I'm not sure why you're saying it's taking too long to run your tests when the output is telling you that it's your examples that are taking too long to run. It's also not taking 24 and 28 seconds - I believe that is just a timestamp telling you that it's producing that note 24 and 28 seconds into the check but I could be wrong. Either way the relevant output for how long the examples take look like: user system elapsed cfa 8.05 0.36 10.08 That which tells you total it took 10.08 seconds to run the examples for arch 'i386'. -Dason Kurkiewicz On Mon, Jun 5, 2017 at 8:23 AM, Jonathon Love wrote: hi, i've uploaded a version of my package to the win-builder service, but it is reporting that one of my tests takes > 10 seconds to run. examining the log here: https://win-builder.r-project.org/BvR4nreDE9qP/00check.log the win-builder is taking 24 and 28 seconds to run this test. on my local machine, this same test runs in 600ms can anyone shed any light on this? why is the win-builder so slow? with thanks jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN stable download url?
hi, i'm bundling some R packages to go into a flatpak/flathub application. for that it is necessary to provide the download URLs for all the required dependencies in advance - including R packages. this works, *except* when an R package version transitions from being the current version, to being archived. the current version will be, say: https://cran.r-project.org/src/contrib/yaml_2.1.16.tar.gz then when yaml 2.1.17 comes out (which it just has), that url will return a 404, and has become: https://cran.r-project.org/src/contrib/Archive/yaml/yaml_2.1.16.tar.gz this means everything breaks when a new version of an R package comes out. does anyone know if a stable url exists for R packages? with thanks jonathon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
