Re: [R-pkg-devel] "non-ASCII input" and "--data-compress" ignored
Hello, Ivan et al.:
I tried escaping "%" every time it occurred without success, but
adding "\encoding{UTF-8}" as the 4th line of nuclearWeaponStates.Rd
eliminated that problem.
Sadly, I tried "R CMD build --resave-data=best Ecdat", "R CMD
build --resave-data Ecdat", "R CMD build Ecdat --resave-data", and "R
CMD build Ecdat --resave-data=best", all without success. I also noted
that .travis.yml contains "r_build_args: --resave-data", which I
remember adding some time ago to fix this problem. And Travis reported
this problem as well. This suggests to me that a change was introduced
with R 4.0.0 that disabled this option.
I also tried loading and resaving all the files in the data
directory. This seemed to achieve some additional compression on
average, but I still got, "Note: significantly better compression could
be obtained by using "R CMD build --resave-data". I then tried load and
saveRDS on each one individually, but at least the first of the
resulting *.rda files was corrupted, so I restored what I had before.
Anyway, Ivan's suggestion fixed the UTF-8 problem and Travis
confirmed that it can't make "--resave-data" work, either ;-) If a CRAN
maintainer complains about the compression problem, I can report what I
tried and see what they suggest.
Thanks again,
Spencer Graves
On 2020-07-17 04:10, Ivan Krylov wrote:
On Fri, 17 Jul 2020 02:02:36 -0500
Spencer Graves wrote:
If I copy this URL into a browser and back out again, I get
the following:
https://www.americansecurityproject.org/ASP%20Reports/Ref%200072%20-%20North%20Korea%E2%80%99s%20Nuclear%20Program%20.pdf
However, if I use this inside "\href", "R CMD check" doesn't
recognize the close curly bracket because of the presence of the
non-ASCII characters.
WRE section 2.3 [*] provides an example of \href with RFC3986
percent-encoding. Since % is a comment character in Rd, the percent
signs have to be escaped with backslashes:
\href{https://www.americansecurityproject.org/ASP\%20Reports/Ref\%200072\%20-\%20North\%20Korea\%E2\%80\%99s\%20Nuclear\%20Program\%20.pdf}{Derek
Bolton (2012) North Korea's Nuclear Program}
This only works correctly in R >= 3.1.3, but results in correct output
in both HTML and PDF formats.
Alternatively, it should be possible to declare the encoding of the Rd
file using \encoding{UTF-8} (WRE 2.14 [**]), but in my tests (R 3.6.3,
could have been fixed in later versions) it results in a broken link in
Rd2pdf output.
I'm getting, " Note: significantly better compression could be
obtained by using R CMD build --resave-data". I get this message
even though I use "R CMD build --data-compress Ecdat". I also tried
"R CMD build Ecdat --data-compress" and got the same result.
The note offers you to try adding --resave-data to R CMD build, not
--data-compress. What happens if you use --resave-data=best?
--data-compress doesn't seem to be an R CMD build option; at least
it's not mentioned in R CMD build --help.
WRE 1.1.6 [***] provides an example of --data-compress as an option of
R CMD INSTALL (not build).
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
On Fri, 17 Jul 2020 11:25:40 +0200 Fabio Sigrist wrote: > Found '_exit', possibly from '_exit' (C) > Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) > Found 'exit', possibly from 'exit' (C), 'stop' (Fortran) > Found 'printf', possibly from 'printf' (C) A curious thing is that it seems to only happen on Windows. I tried searching objdump -D output for the offending functions by means of a Perl5 one-liner [1] and found that the functions are all called by various bits of libgcc, OpenMP, C and C++ runtimes. This is probably caused by linking your R package with -static-libstdc++ (which is set in CMakeLists.txt if(WIN32 AND MINGW)). > Note that the shared library is compiled using install.libs.R (this > is a deliberate choice) Some of the things it does aren't very portable (e.g. manually setting most -W flags is discouraged). In particular, I had to manually remove -Wno-error=cast-function-type from CMakeLists.txt to build the package with GCC 6.3.0-18+deb9u1, despite it passing the version check (>=4.8.2). -- Best regards, Ivan [1] objdump -D lib_gpboost.dll | \ perl -lnE' $fn = $1 if /^[0-9a-f]+ +<([^>]+)>:/; say $fn if /call.*<\Q$call\E/ ' -s -- -call=abort | c++filt __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
On 17 July 2020 at 14:58, Benjamin Christoffersen wrote:
| Quick guess. After changing
| > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread -O3 -Wextra
-Wall -Wno-unknown-pragmas -Wno-return-type -Wno-ignored-attributes
-Wno-cast-function-type -Wno-error=cast-function-type")
|
| to
| > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread -O3 -Wextra
-Wall")
|
| I managed to `R CMD INSTALL` the package with gcc-8 on Ubuntu. Then
| doing `cd ~/R/x86_64-pc-linux-gnu-library/3.6/gpboost/libs/` and
| - nm *.so -C | grep exit
| - nm *.so -C | grep abort
| - nm *.so -C | grep printf
|
| yields nothing. However, doing `nm *.so -C | grep assert` yields
| U __assert_fail@@GLIBC_2.2.5
|
| and doing `grep "assert" -nr .` shows that `assert` is being called.
| Thus, is everything build with `-NDEBUG`? See
| https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#DOCF76
Very nice catch!
Given the package (and underlying library) has a joint repo, it is pretty
easy to search directly at GitHub too, and it looks like all the required
legwork has been done to #ifdef printf() statements and alike.
Now, I had to do the same work for packages of mine too in the past, and I
don't recall the test output "crossing". So if it really were only assert
coming back in via -NDEBUG then the tests for printf would NOT be triggered.
So something else must likely be hiding. Which is ... difficult to check in
a codebase that includes duplicate copies of Eigen, LighGBM, ... and more.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
Quick guess. After changing
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread -O3 -Wextra -Wall
> -Wno-unknown-pragmas -Wno-return-type -Wno-ignored-attributes
> -Wno-cast-function-type -Wno-error=cast-function-type")
to
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread -O3 -Wextra
> -Wall")
I managed to `R CMD INSTALL` the package with gcc-8 on Ubuntu. Then
doing `cd ~/R/x86_64-pc-linux-gnu-library/3.6/gpboost/libs/` and
- nm *.so -C | grep exit
- nm *.so -C | grep abort
- nm *.so -C | grep printf
yields nothing. However, doing `nm *.so -C | grep assert` yields
U __assert_fail@@GLIBC_2.2.5
and doing `grep "assert" -nr .` shows that `assert` is being called.
Thus, is everything build with `-NDEBUG`? See
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#DOCF76
Den fre. 17. jul. 2020 kl. 14.52 skrev Spencer Graves
:
>
>Can you run the checks only on the subdirectory containing the
> compiled code? If yes, then you can run it only on half of that
> directory and identify it with a binary search.
>
>
>Some years ago, I found a particularly difficult bug that way.
> If I recall correctly, I made a copy of the package, deleted half of the
> *.Rd files, etc., until I identified which *.Rd file. Then I deleted
> ~half of the contents of that *.Rd file until I isolated the problem.
> It was neither easy nor fun, but it was what I did to find and then fix
> the problem.
>
>
>Hope this helps,
>Spencer
>
>
> On 2020-07-17 07:34, Marcin Jurek wrote:
> > So maybe you tried that already but I noticed that sometimes when I do the
> > check on the package directory rather than on the tarball I get similar
> > errors. I don't know if that's the problem but it should be a quick thing
> > to try.
> >
> > On Fri, Jul 17, 2020 at 5:05 AM Fabio Sigrist
> > wrote:
> >
> >> Dear all,
> >>
> >> I am trying to get an R package with C++ code on CRAN and I have one NOTE
> >> remaining, for which I can't find a solution:
> >>
> >> Note: information on .o files for x64 is not available
> >>File
> >> 'd:/RCompile/CRANincoming/R-devel/lib/gpboost/libs/x64/lib_gpboost.dll':
> >> Found '_exit', possibly from '_exit' (C)
> >> Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> >> Found 'exit', possibly from 'exit' (C), 'stop' (Fortran)
> >> Found 'printf', possibly from 'printf' (C)
> >>
> >> As much as I search through my code, I can't find the place / headers where
> >> these calls / symbols originate. Also, I have no idea how to add
> >> information on .o files (apart from the shared library, there are no .o
> >> files). The .tar.gz file for the package can be found on
> >> https://github.com/fabsig/GPBoost/blob/master/gpboost_0.2.0.tar.gz. Note
> >> that the shared library is compiled using install.libs.R (this is a
> >> deliberate choice) and the flag "GPB_R_BUILD" is set when compiling for the
> >> R package (I have tried to put "#ifndef GPB_R_BUILD" around all headers
> >> that could cause the problems with exit / abort calls, but apparently I
> >> have not been able to find all).
> >>
> >> Any help is greatly appreciated.
> >>
> >> Best regards,
> >> Fabio Sigrist
> >>
> >> [[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
On 17 July 2020 at 11:25, Fabio Sigrist wrote: | I am trying to get an R package with C++ code on CRAN and I have one NOTE | remaining, for which I can't find a solution: | | Note: information on .o files for x64 is not available | File | 'd:/RCompile/CRANincoming/R-devel/lib/gpboost/libs/x64/lib_gpboost.dll': | Found '_exit', possibly from '_exit' (C) | Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) | Found 'exit', possibly from 'exit' (C), 'stop' (Fortran) | Found 'printf', possibly from 'printf' (C) | | As much as I search through my code, I can't find the place / headers where | these calls / symbols originate. Also, I have no idea how to add | information on .o files (apart from the shared library, there are no .o | files). The .tar.gz file for the package can be found on | https://github.com/fabsig/GPBoost/blob/master/gpboost_0.2.0.tar.gz. Note | that the shared library is compiled using install.libs.R (this is a | deliberate choice) and the flag "GPB_R_BUILD" is set when compiling for the | R package (I have tried to put "#ifndef GPB_R_BUILD" around all headers | that could cause the problems with exit / abort calls, but apparently I | have not been able to find all). You will have to look harder. The external library, likely written without knowledge of these (useful for R, otherwise arbitrary) constraint is likely to contain exit(), (f)printf(), puts(), ... or alike. If you want your package on CRAN, you need to change this. That's the price. Code called from R cannot abort the session, and needs to communicate via R's output streams. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
Can you run the checks only on the subdirectory containing the compiled code? If yes, then you can run it only on half of that directory and identify it with a binary search. Some years ago, I found a particularly difficult bug that way. If I recall correctly, I made a copy of the package, deleted half of the *.Rd files, etc., until I identified which *.Rd file. Then I deleted ~half of the contents of that *.Rd file until I isolated the problem. It was neither easy nor fun, but it was what I did to find and then fix the problem. Hope this helps, Spencer On 2020-07-17 07:34, Marcin Jurek wrote: So maybe you tried that already but I noticed that sometimes when I do the check on the package directory rather than on the tarball I get similar errors. I don't know if that's the problem but it should be a quick thing to try. On Fri, Jul 17, 2020 at 5:05 AM Fabio Sigrist wrote: Dear all, I am trying to get an R package with C++ code on CRAN and I have one NOTE remaining, for which I can't find a solution: Note: information on .o files for x64 is not available File 'd:/RCompile/CRANincoming/R-devel/lib/gpboost/libs/x64/lib_gpboost.dll': Found '_exit', possibly from '_exit' (C) Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) Found 'exit', possibly from 'exit' (C), 'stop' (Fortran) Found 'printf', possibly from 'printf' (C) As much as I search through my code, I can't find the place / headers where these calls / symbols originate. Also, I have no idea how to add information on .o files (apart from the shared library, there are no .o files). The .tar.gz file for the package can be found on https://github.com/fabsig/GPBoost/blob/master/gpboost_0.2.0.tar.gz. Note that the shared library is compiled using install.libs.R (this is a deliberate choice) and the flag "GPB_R_BUILD" is set when compiling for the R package (I have tried to put "#ifndef GPB_R_BUILD" around all headers that could cause the problems with exit / abort calls, but apparently I have not been able to find all). Any help is greatly appreciated. Best regards, Fabio Sigrist [[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
Re: [R-pkg-devel] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
So maybe you tried that already but I noticed that sometimes when I do the check on the package directory rather than on the tarball I get similar errors. I don't know if that's the problem but it should be a quick thing to try. On Fri, Jul 17, 2020 at 5:05 AM Fabio Sigrist wrote: > Dear all, > > I am trying to get an R package with C++ code on CRAN and I have one NOTE > remaining, for which I can't find a solution: > > Note: information on .o files for x64 is not available > File > 'd:/RCompile/CRANincoming/R-devel/lib/gpboost/libs/x64/lib_gpboost.dll': > Found '_exit', possibly from '_exit' (C) > Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) > Found 'exit', possibly from 'exit' (C), 'stop' (Fortran) > Found 'printf', possibly from 'printf' (C) > > As much as I search through my code, I can't find the place / headers where > these calls / symbols originate. Also, I have no idea how to add > information on .o files (apart from the shared library, there are no .o > files). The .tar.gz file for the package can be found on > https://github.com/fabsig/GPBoost/blob/master/gpboost_0.2.0.tar.gz. Note > that the shared library is compiled using install.libs.R (this is a > deliberate choice) and the flag "GPB_R_BUILD" is set when compiling for the > R package (I have tried to put "#ifndef GPB_R_BUILD" around all headers > that could cause the problems with exit / abort calls, but apparently I > have not been able to find all). > > Any help is greatly appreciated. > > Best regards, > Fabio Sigrist > > [[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] Note: information on .o files is not available / Found '_exit', possibly from '_exit' (C)
Dear all, I am trying to get an R package with C++ code on CRAN and I have one NOTE remaining, for which I can't find a solution: Note: information on .o files for x64 is not available File 'd:/RCompile/CRANincoming/R-devel/lib/gpboost/libs/x64/lib_gpboost.dll': Found '_exit', possibly from '_exit' (C) Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) Found 'exit', possibly from 'exit' (C), 'stop' (Fortran) Found 'printf', possibly from 'printf' (C) As much as I search through my code, I can't find the place / headers where these calls / symbols originate. Also, I have no idea how to add information on .o files (apart from the shared library, there are no .o files). The .tar.gz file for the package can be found on https://github.com/fabsig/GPBoost/blob/master/gpboost_0.2.0.tar.gz. Note that the shared library is compiled using install.libs.R (this is a deliberate choice) and the flag "GPB_R_BUILD" is set when compiling for the R package (I have tried to put "#ifndef GPB_R_BUILD" around all headers that could cause the problems with exit / abort calls, but apparently I have not been able to find all). Any help is greatly appreciated. Best regards, Fabio Sigrist [[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] "non-ASCII input" and "--data-compress" ignored
On Fri, 17 Jul 2020 02:02:36 -0500
Spencer Graves wrote:
> If I copy this URL into a browser and back out again, I get
> the following:
>
>
> https://www.americansecurityproject.org/ASP%20Reports/Ref%200072%20-%20North%20Korea%E2%80%99s%20Nuclear%20Program%20.pdf
>
>
> However, if I use this inside "\href", "R CMD check" doesn't
> recognize the close curly bracket because of the presence of the
> non-ASCII characters.
WRE section 2.3 [*] provides an example of \href with RFC3986
percent-encoding. Since % is a comment character in Rd, the percent
signs have to be escaped with backslashes:
\href{https://www.americansecurityproject.org/ASP\%20Reports/Ref\%200072\%20-\%20North\%20Korea\%E2\%80\%99s\%20Nuclear\%20Program\%20.pdf}{Derek
Bolton (2012) North Korea's Nuclear Program}
This only works correctly in R >= 3.1.3, but results in correct output
in both HTML and PDF formats.
Alternatively, it should be possible to declare the encoding of the Rd
file using \encoding{UTF-8} (WRE 2.14 [**]), but in my tests (R 3.6.3,
could have been fixed in later versions) it results in a broken link in
Rd2pdf output.
> I'm getting, " Note: significantly better compression could be
> obtained by using R CMD build --resave-data". I get this message
> even though I use "R CMD build --data-compress Ecdat". I also tried
> "R CMD build Ecdat --data-compress" and got the same result.
The note offers you to try adding --resave-data to R CMD build, not
--data-compress. What happens if you use --resave-data=best?
--data-compress doesn't seem to be an R CMD build option; at least
it's not mentioned in R CMD build --help.
WRE 1.1.6 [***] provides an example of --data-compress as an option of
R CMD INSTALL (not build).
--
Best regards,
Ivan
P.S.
> [[alternative HTML version deleted]]
Please don't post in HTML.
[*]
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Marking-text
[**]
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Encoding
[***]
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Data-in-packages
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Interpret feedback: not write testthat-tests in examples
If you do want to communicate around tests a bit more, without cluttering the manual, you might find the covrpage package interesting https://yonicd.github.io/covrpage/ It creates a README in the tests folder, with test results, and it can create a vignette with the same content. On dj., jul. 16, 2020 at 19:40, Henrik Bengtsson wrote: If the point of having, say, stopifnot(add(1, 2) == sum(c(1, 2)) is to make it explicit to the reader that your add() function gives the same results as sum(), then I argue that is valid to use in an example. I'm pretty sure I've used that in some of my examples. For the purpose, there should be no reason why you can't use other "assert" functions for this purpose, e.g. testthat::expect_equal(add(1, 2), sum(c(1, 2)) Now, if the point of your "assert" statement is only to validate your package/code, then I agree it should not be in the example code because it adds clutter. Such validation should be in a package test. So, if the former, I suggest you reply to the CRAN Team and explain this. /Henrik On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek wrote: > > Dear R package developers, > > I would enjoy some help regarding some feedback I got on my package from a > CRAN volunteer, as I am unsure how to interpret this correctly. > > This is the feedback I got (I added '[do]'): > > > Please [do] not write testthat-tests in your examples. > > I wonder if this is about using `testthat` or using tests in general. > > To simplify the context, say I wrote a package with a function called `add`, > that adds two numbers. My example code would then be something like this: > > ``` > library(testthat) > > expect_equal(add(1, 2), 3) > ``` > > The first interpretation is about using `testthat`: maybe I should use base R > (`stopifnot`) or another testing library (`testit`) or hand-craft it myself? > > The second interpretation is about using tests in example code. I like to > actively demonstrate that my code works as expected. I checked the policies > regarding examples, and I could not find a rule that I should refrain from > doing so. > > What is the correct response to this feedback? > > Thanks for your guidance, Richel Bilderbeek > > __ > 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] "non-ASCII input" and "--data-compress" ignored
Hello:
I'm getting two warnings that I don't know how to fix on both
4.0.2 under macOS 10.15.5 and 4.0.0 under TRAVIS-CI; the email from
Travis CI is copied below.
NON-ASCII INPUT:
* checking Rd files ... WARNING
man/nuclearWeaponStates.Rd: non-ASCII input and no declared encoding
problem found in ‘nuclearWeaponStates.Rd’
I'm virtually certain this comes from the following:
\href{https://www.americansecurityproject.org/ASP Reports/Ref 0072 -
North Korea’s Nuclear Program .pdf}{Derek Bolton (2012) North Korea's
Nuclear Program} (2012-08, American Security Program, accessed 2020-07-15)
If you look carefully, you see spaces and a right single quote in
the URL. If I copy this URL into a browser and back out again, I get
the following:
https://www.americansecurityproject.org/ASP%20Reports/Ref%200072%20-%20North%20Korea%E2%80%99s%20Nuclear%20Program%20.pdf
However, if I use this inside "\href", "R CMD check" doesn't
recognize the close curly bracket because of the presence of the
non-ASCII characters. I could leave out the URL, but that would degrade
the quality of the documentation.
"--DATA-COMPRESS" IGNORED
I'm getting, " Note: significantly better compression could be
obtained by using R CMD build --resave-data". I get this message even
though I use "R CMD build --data-compress Ecdat". I also tried "R CMD
build Ecdat --data-compress" and got the same result.
Suggestions?
Thanks,
Spencer Graves
sessionInfo()
R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.5
Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.2
Forwarded Message
Subject:Broken: sbgraves237/Ecdat#33 (master - a049665)
Date: Fri, 17 Jul 2020 06:05:20 +
From: Travis CI
To: spencer.gra...@effectivedefense.org
sbgraves237
/
Ecdat
branch iconmaster
build has failed
Build #33 was broken
arrow to build time
clock icon5 mins and 5 secs
sbgraves237 avatarsbgraves237
a049665 CHANGESET →
fix nuclearWeaponStates so it now has all the desired data
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
Unsubscribe
from build emails from the sbgraves237/Ecdat repository.
To unsubscribe from *all* build emails, please update your settings
.
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
