need to alter for CRAN - Githubissues

dankelley commented 11 months ago

Dear maintainer,

Please see the problems shown on https://cran.r-project.org/web/checks/check_results_oce.html.

Please correct before 2023-12-11 to safely retain your package on CRAN.

Best,

k

dankelley commented 11 months ago

Here is the report. It looks easy to fix although I'll need to check that link to see if the stuff given after it is just a repeat. I'll try today because this is a super-busy time of year.

Whether I can find a test machine to check on whether my fix works is (as always) another question...

[gcc12](https://www.stats.ox.ac.uk/pub/bdr/gcc12/oce.out) Check Details Version: 1.8-1 Check: Rd files Result: NOTE checkRd: (-1) summary-argo-method.Rd:13-14: Lost braces 13 | \item{object}{an}{object of class \code{"argo"}, usually, a result of a | ^ Flavors: [r-devel-linux-x86_64-debian-clang](https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/oce-00check.html), [r-devel-linux-x86_64-debian-gcc](https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/oce-00check.html) Version: 1.8-1 Check: whether package can be installed Result: WARN Found the following significant warnings: amsr.cpp:106:65: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] bilinear_interp.cpp:28:43: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] gappy_index.cpp:25:82: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=] geod.cpp:17:92: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] geod.cpp:40:75: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] geod.cpp:42:75: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] geod.cpp:44:75: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] ldc_ad2cp_in_file.cpp:185:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:201:18: warning: too many arguments for format [-Wformat-extra-args] ldc_ad2cp_in_file.cpp:211:50: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:254:56: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:254:63: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:259:83: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:275:80: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:279:23: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:279:37: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:279:88: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long unsigned int’ [-Wformat=] ldc_ad2cp_in_file.cpp:295:75: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long unsigned int’ [-Wformat=] ldc_ad2cp_in_file.cpp:299:33: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:299:74: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:309:33: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:311:33: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:316:96: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:333:61: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:339:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_ad2cp_in_file.cpp:339:67: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:342:36: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:350:40: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:350:54: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:364:32: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:366:32: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:371:94: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:374:36: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:380:29: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:388:65: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:394:101: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:425:78: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:427:42: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long long int’ [-Wformat=] ldc_ad2cp_in_file.cpp:430:75: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long long int’ [-Wformat=] ldc_rdi_in_file.cpp:64:15: warning: too many arguments for format [-Wformat-extra-args] ldc_rdi_in_file.cpp:231:63: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:272:102: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:272:115: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:285:41: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=] ldc_rdi_in_file.cpp:285:52: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:285:65: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:291:96: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:291:109: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:298:96: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:298:109: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:314:66: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:323:56: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:331:79: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:331:92: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:342:105: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:342:118: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:348:102: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:348:115: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:354:45: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:354:109: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:369:69: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:394:35: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:394:50: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:394:62: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:394:79: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:425:60: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:441:49: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:441:61: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:441:68: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:455:49: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:471:47: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:474:52: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=] ldc_rdi_in_file.cpp:485:85: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:504:35: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:504:50: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:504:62: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:504:79: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:514:63: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:521:44: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] ldc_rdi_in_file.cpp:524:48: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=] ldc_rdi_in_file.cpp:525:95: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] map.c:259:15: warning: too many arguments for format [-Wformat-extra-args] map.c:379:15: warning: too many arguments for format [-Wformat-extra-args] run.cpp:15:69: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] trap.cpp:16:43: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘R_xlen_t’ {aka ‘long int’} [-Wformat=] See ‘/home/hornik/tmp/R.check/r-devel-gcc/Work/PKGS/oce.Rcheck/00install.out’ for details. * used C compiler: ‘gcc-13 (Debian 13.2.0-5) 13.2.0’ * used Fortran compiler: ‘GNU Fortran (Debian 13.2.0-5) 13.2.0’ * used C++ compiler: ‘g++-13 (Debian 13.2.0-5) 13.2.0’ Flavor: [r-devel-linux-x86_64-debian-gcc](https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/oce-00check.html)

dankelley commented 11 months ago

I will do the work in a new branch named cran-release-for-new-gcc.

Since rhub tests often take hours (often with PREPERROR failures that have nothing to do with oce), I will try using docker image to test locally. Here are the steps to do this. (Note that I will edit this comment in-place as I go through them.)

Install the docker app from https://docs.docker.com/desktop/install/mac-install/
Visit https://hub.docker.com/r/rhub/debian-clang to learn about the command in next item.
In the docker app, search for rhub/debian-clang (or is it rhub/debian-clang:latest?) and then click the 'pull' button??? or maybe in terminal, do docker pull rhub/debian-clang, which seems easier.
how to start?

... or maybe try as follows (from https://r-hub.github.io/rhub/articles/local-debugging.html)

local_check_linux(image="rhub/debian-clang-devel")

dankelley commented 11 months ago

I've spent a few hours trying to get docker to reproduce the error, but man it's a slow process ... and the images that have 'clang' in the title do not actually use clang in the building process, so it was a total waste of time. Sheesh.

Luckily, there are now notes being produced on windows R-devel CRAN test machines, and I see that I can also test it with devtools::check_win_devel(), so I'll be able to do this. No, the tests won't be local. But my time is not worth zero dollars and zero cents, and I will likely only need a few remote builds...

I have a lot of grading to do but I will take a break every once in a while to do more of this fiddly work. Since checklists on GH issues work poorly (often it forgets a few clicks) I'll make a checklist in the apple notes app, which is really quite convenient.

Expect to hear more from me later this week.

dankelley commented 11 months ago

I've fixed this up, and now this and Clark's fix for #2173 both pass remote-windows-devel tests, as shown at https://win-builder.r-project.org/C5M4pyKY2Ixb/ (a link that will only live a few days, by design).

dankelley commented 11 months ago

I am reopening this so I can record the following. I found that one of the github actions that gets run requires one C format, and that devtools::check_win_devel() requires another. The screenshot shows the present state (which I will change in 5 minutes). The top is the output from devtools::check_win_devel(), showing an error. But the bottom part is a git diff which (and you have to trust me on this) is the change I had to make for the R-CMD-check action named ubuntu-latest-devel to work.

So, we have a contradiction. I don't know how to know which is best.

dankelley commented 11 months ago

I give up. Below is a commit note. The recommended scheme does not work. Maybe my (OSX) toolchain is not right. But I don't want to have oce in a state where I cannot build it. I'm just dropping this feature of stating values in some of the error messages. Users won't see the errors unless things are wrong, and they can easily just look at the arguments they gave to the function.

commit fa9c55ae9a15f1f70474faff05af66d7b166893f Author: dankelley Date: Tue Nov 28 18:50:52 2023 -0400 give up on formatting NumericVector.size() I am just not sure how to do it, and the advice I've had in the email list doesn't seem to work. If I ever want to return to this, I think the name of this commit note ought to be enough, but below is a message from the thread, but that R_PRIdLEN_T concatenation led to an error. Maybe it's not defined in my toolchain. But I am out of time to mess with this. These are all occuring in rare circumstances of problems and the point is that instead of saying things like "lengths of x and y must match", these are stating those lengths. But the user can just check that, if provided with the non-match message. This is not worth potentially having some CRAN machines issuing warnings that might cause package rejection. Over the next day or two, I'll continue local, win_builder and R_CMD_CHECK tests, to try to find something that is quiet in all three cases. Then I'll submit oce. Time is running out and I have things to grade and exams coming up during the deadline period. ::R_error("size %" R_PRIdXLEN_T ", a.size()); ``` I think the best way to deal with these is to look at the lines and arguments identified by any of the compilers on any of the test platforms you have, and then based on reading the code and learning what the types really are (or are guaranteed to be) decide on how to fix. The presence and wording of the warnings may be compiler specific. In some cases even platform specific, because some C types have different size on different platforms, or map to different underlying types. So, if the line above was identified by the compiler, check the documentation for NumericVector::size(), which type does it guarantee to return. The compiler warning may give a hint (what the type is in your build), but indeed it wouldn't consult the documentation. If the type is R_xlen_t (I didn't check if it is), then you could do e.g. ::R_error("size %lld", (long long)a.size()); or better ::R_error("size %" R_PRIdXLEN_T ", a.size()); as discussed elsewhere in this thread. It is not a good idea to just use the type given in the warning, because that may not be portable. In this case, your compiler warning (on Linux) may have said "long int", which may have been how "ptrdiff_t" is defined on the platform by the compiler, which is probably how R_xlen_t is defined on your platform. But, it may be different elsewhere. On your second platform, the compiler warning may have said "long long int" (on Windows), which may have been how "ptrdiff_t" is defined there by the compiler, and on that platform, "long int" is different from "long long int", so the former didn't work. If you use the Winbuilder service maintained by Uwe Ligges, you will have the same setup as one of the platforms used for CRAN incoming checks. ```

dankelley commented 11 months ago

Since this has no problems on (a) my machine, (b) devtools::check_win_devel() or (c) in the 4 machines tested with R-CMD-CHECK, I am proceeding to run check_package.R from the source.

I have temporarily turned on the rhub checks in that source, because you have to indicate that you have tested there during the submission process. The rhub results are often useless, e.g., taking 2 hours to get to a so-called PREPERROR that occurs before it even tries to build oce, but the submission process wants that, so I'll do it.

@richardsc and @clayton33 -- this is a long way of saying that my plan is to try to submit oce to CRAN very soon. I don't want to get close to the deadline in case what ought to be a quick process ends up burning days ... for those are days when I will be grading things, and I get paid to do that, not to work around C++ compilers on machines to which I have no access, and which are being tweaked by CRAN folks on what seems to be a daily basis.

dankelley commented 11 months ago

The remote mac test shows as follows. I don't know whether to worry about this, but I note that the first two relate to source in oce, and the others (I think) do not.

I've never seen that warning on my intel box. Perhaps it's a feature of the M-series macs. @richardsc -- do you get that warning when you build on your M-series mac?

clang++ -arch arm64 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -o oce.so RcppExports.o ad2cp_ahrs.o adv_vector_time.o amsr.o approx.o bilinear_interp.o binmap.o bitwise.o coastline.o curl.o echosounder.o fillgap.o gappy_index.o geod.o get_bit.o gradient.o igrf12.o igrf13.o interp_barnes.o landsat.o ldc_ad2cp_in_file.o ldc_rdi_in_buffer.o ldc_rdi_in_file.o magdec.o map.o matrix_smooth.o oce_approx.o oce_convolve.o oce_filter.o ocecp.o registerDynamicSymbol.o run.o sfm_enu.o sontek_adp.o sw.o time.o trap.o trim.o -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/12.2.0 -L/opt/gfortran/lib -lgfortran -lemutls_w -lquadmath -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
ld: warning: could not create compact unwind for _igrf12syn_: registers 78 and 79 not saved contiguously in frame
ld: warning: could not create compact unwind for _igrf13syn_: registers 78 and 79 not saved contiguously in frame
ld: warning: could not create compact unwind for _md_driver_: registers 25 and 26 not saved contiguously in frame
ld: warning: could not create compact unwind for ___emutls_get_address: registers 23 and 24 not saved contiguously in frame

dankelley commented 11 months ago

NB. the revdepcheck tests were all OK, indicating that no package that depends on oce acquired errors (or warnings, I think) with the oce update.

dankelley commented 11 months ago

NB. rhub results will be at the following links. (I will alter this comment in-place, as results become available. That won't likely be complete until this afternoon.)

windows-ucrt -- no C++ errors or warnings, but I see as below. I think the two things might be related. Since I do not see these messages elsewhere, I'm going to assume it's just a quirkiness of that rhub machine setup.
- checking for non-standard things in the check directory ... NOTE Found the following files/directories: ''NULL''
- checking for detritus in the temp directory ... NOTE Found the following files/directories: 'lastMiKTeXException'
Ubuntu Linux 20.04.1 LTS, R-release, GCC -- no warnings or errors
Fedora Linux, R-devel, clang, gfortran There are warnings about int formats from various Rcpp source files, but not from oce itself.
Debian Linux, R-devel, GCC ASAN/UBSAN -- this format is quite different from the others, but I was able to check a few things (bilinear interpolation, etc) and there were no oce-specific warnings or errors.
Debian Linux, R-devel, clang, ISO-8859-15 locale -- no oce-related compiler warnings (but Rcpp ones, of course) in 67066 lines of output.

richardsc commented 11 months ago

@dankelley in reply to your comment https://github.com/dankelley/oce/issues/2172#issuecomment-1831533387:

I see the following warnings when I build (R4.3.0 on MacOS12.7.1):

ld: warning: could not create compact unwind for _igrf12syn_: registers 76 and 77 not saved contiguously in frame
ld: warning: could not create compact unwind for _igrf13syn_: registers 76 and 77 not saved contiguously in frame
ld: warning: could not create compact unwind for _md_driver_: registers 25 and 26 not saved contiguously in frame

dankelley commented 11 months ago

Hm, afraid of that. These are all for fortran code. I don't know any way to determine what the problem is. Therefore, my inclination is to ignore this and submit to CRAN. (Well, maybe I'll do some google searching on the message, but I do not want to alter the gravity code, which is the first two warnings.). Thanks for checking.

dankelley commented 11 months ago

This is a call-out to co-developers @richardsc and @clayton33: I am planning on releasing oce to CRAN very soon, perhaps on the weekend. The issue is that I don't want to get anywhere near the deadline they have set, because if there is a last-minute problem, oce could get booted from CRAN and getting back on might be hard, given that we violate rules on size and time.

Also, I'm a bit buried in teaching and that will get worse in the next 2 weeks.

So, please let me know if you think there is anything that absolutely needs to be fixed in oce. If there is, I can try to dedicate some time to that next week (in between grading assignments...).

Thanks!!

clayton33 commented 11 months ago

Nothing from me !

dankelley commented 10 months ago

commit f578e9d5b3837499809c487dc0c0b711209ce944 Author: dankelley kelley.dan@gmail.com Date: Fri Dec 1 06:23:55 2023 -0400

freeze code (run codemeta) in preparation for CRAN

dankelley commented 10 months ago

I am now running the check_package.R source file. This includes rhub checks that can take several hours to complete, but my guess is that by mid-afternoon, we will be clear for a CRAN submission today. Barring problems (and in light of other demands on my time), oce ought to be accepted before the deadline.

dankelley commented 10 months ago

The checks are all fine for

R version 4.2.3 (2023-03-15 ucrt)
R Under development (unstable) (2023-11-30 r85651 ucrt)

dankelley commented 10 months ago

The remote RHUB checks are as below. I'll check again later today. (Sometimes a check can take 2 to 4 hours.)

rhub::check_for_cran(email="Dan.Kelley@Dal.Ca", show_status=FALSE)

yields

Windows Server 2022, R-devel, 64 bit OK (just some notes of files left over from tex, which is nothing to do with oce)
Ubuntu Linux 20.04.1 LTS, R-release, GCC PREPERROR (unrelated to oce, which was fine)
Fedora Linux, R-devel, clang, gfortran PREPERROR (unrelated to oce, which was fine)
Debian Linux, R-devel, GCC ASAN/UBSAN PREPERROR (unrelated to oce, which was fine)

rhub::check(platform="debian-clang-devel", show_status=FALSE)

yields

Debian Linux, R-devel, clang, ISO-8859-15 locale OK for oce, with compiler warnings for Rcpp on int formats (but not for oce code)

dankelley commented 10 months ago

All those rhub checks are now done. (The slowest took almost 3 hours.). That means that I have done all the checks in the check_package.R file.

My plan is to submit it to CRAN this afternoon. Every time I do that, there are new things tests that I have to pledge to have done, so that might cause a delay until tomorrow. (I add those checks to check_package.R, which explains why it does so much.)

dankelley commented 10 months ago

I just submitted it. Below is the confirmation email I got from CRAN. Now we wait.

``` [This was generated from [CRAN.R-project.org/submit.html](http://cran.r-project.org/submit.html)] The following package was uploaded to CRAN: =========================================== Package Information: Package: oce Version: 1.8-2 Title: Analysis of Oceanographic Data Author(s): Dan Kelley [aut, cre] (), Clark Richards [aut] (), Chantelle Layton [ctb] (, curl() coauthor), British Geological Survey [ctb, cph] (magnetic-field subroutine) Maintainer: Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)> Depends: R (>= 2.15), gsw, methods, utils Suggests: automap, DBI, foreign, interp, knitr, lubridate, ncdf4, ocedata, rmarkdown, RSQLite, R.utils, sf, terra, testthat (>= 3.0.0), tiff, XML Description: Supports the analysis of Oceanographic data, including 'ADCP' measurements, measurements made with 'argo' floats, 'CTD' measurements, sectional data, sea-level time series, coastline and topographic data, etc. Provides specialized functions for calculating seawater properties such as potential temperature in either the 'UNESCO' or 'TEOS-10' equation of state. Produces graphical displays that conform to the conventions of the Oceanographic literature. This package is discussed extensively by Kelley (2018) "Oceanographic Analysis with R" . License: GPL (>= 2) Imports: Rcpp LinkingTo: Rcpp The maintainer confirms that he or she has read and agrees to the CRAN policies. Submitter's comment: # Submission of oce 1.8-2 As in previous CRAN submissions, we request an exception to the 10-minute rule, on account of the package size (300+ functions, covering 60k lines of R, 6k lines of C/C++ and 1k line of Fortran). A key reason for the submission is a requirement to ensure that Rprintf() and similar functions use properly-matching format codes for the various integer formats. I was notified that this had become a problem on CRAN machines on Nov 27. The NEWS.md file lists over additional changes that improve oce by extending capabilities and removing bugs. ## Local Tests R 4.3.2 on macOS Sonoma Beta 14.2 (23C5047e) revealed no ERRORs, no WARNINGs, and 2 NOTEs, one about the author name and the other about the package size. ## Remote Windows Checks Using devtools:::build_win_release() devtools:::build_win_oldrelease() devtools:::build_win_devel() identified no errors. ## Other checks The following checks passed without difficulty, except that some of the RHUB checks failed for reasons unrelated to the package (owing, it seems, to difficulties in the setup of the testing machines). ``` devtools::spell_check() urlchecker::url_check() devtools::check_win_release() devtools::check_win_devel() devtools::check_win_oldrelease() rhub::check_for_cran(email="[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)", show_status=FALSE) revdepcheck::revdep_reset() revdepcheck::revdep_check(num_workers=4) ``` ================================================= Original content of DESCRIPTION file: Package: oce Title: Analysis of Oceanographic Data Version: 1.8-2 Authors@R: c( person(given="Dan", family="Kelley", email="[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)", role=c("aut", "cre"), comment=c(ORCID="https://orcid.org/0000-0001-7808-5911")), person(given="Clark", family="Richards", email="[clark.richards@gmail.com](mailto:clark.richards@gmail.com)", role=c("aut"), comment=c(ORCID="https://orcid.org/0000-0002-7833-206X")), person(given="Chantelle", family="Layton", email="[chantelle.layton@dal.ca](mailto:chantelle.layton@dal.ca)", role=c("ctb"), comment=c(ORCID="https://orcid.org/0000-0002-3199-5763", "curl() coauthor")), person(given="British Geological Survey", role=c("ctb","cph"), comment="magnetic-field subroutine")) Maintainer: Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)> Depends: R (>= 2.15), gsw, methods, utils Suggests: automap, DBI, foreign, interp, knitr, lubridate, ncdf4, ocedata, rmarkdown, RSQLite, R.utils, sf, terra, testthat (>= 3.0.0), tiff, XML BugReports: https://github.com/dankelley/oce/issues Description: Supports the analysis of Oceanographic data, including 'ADCP' measurements, measurements made with 'argo' floats, 'CTD' measurements, sectional data, sea-level time series, coastline and topographic data, etc. Provides specialized functions for calculating seawater properties such as potential temperature in either the 'UNESCO' or 'TEOS-10' equation of state. Produces graphical displays that conform to the conventions of the Oceanographic literature. This package is discussed extensively by Kelley (2018) "Oceanographic Analysis with R" . License: GPL (>= 2) Encoding: UTF-8 URL: https://dankelley.github.io/oce/ LazyData: false Roxygen: list(markdown = TRUE) RoxygenNote: 7.2.3 BuildVignettes: true VignetteBuilder: knitr NeedsCompilation: yes LinkingTo: Rcpp Imports: Rcpp Packaged: 2023-12-01 19:20:04 UTC; kelley Config/testthat/edition: 3 Author: Dan Kelley [aut, cre] (), Clark Richards [aut] (), Chantelle Layton [ctb] (, curl() coauthor), British Geological Survey [ctb, cph] (magnetic-field subroutine) ```

dankelley commented 10 months ago

Oooh, CRAN is fast today. The package is already starting to get a foot in the door.

``` Dear maintainer, package oce_1.8-2.tar.gz has been auto-processed and is pending an automated reverse dependency check. This service will typically respond to you within the next day. For technical reasons you may receive a second copy of this message when a team member triggers a new check. Log dir: The files will be removed after roughly 7 days. Installation time in seconds: 132 Check time in seconds: 468 R Under development (unstable) (2023-11-30 r85651 ucrt) Pretests results: Windows: Status: OK Debian: Status: OK Last released version's CRAN status: OK: 2, NOTE: 6, WARNING: 5 See: CRAN Web: *** Strong rev. depends ***: argoFloats callsync dendroTools locaR morphomap seacarb skyscapeR soundecology SWMPr vprr Best regards, CRAN teams' auto-check service Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64 Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers Maintainer: 'Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)>' ```

dankelley commented 10 months ago

Another hurdle has been passed (see the details below), but I'll keep this issue open until multiple versions become available on CRAN. Problems can be discovered after things seem okay on several machines. They will let me know if so, but I like to keep an issue open until some common platforms get pre-built binaries.

``` Dear maintainer, thanks, package oce_1.8-2.tar.gz is on its way to CRAN. Best regards, CRAN teams' auto-check service Package check result: OK No changes to worse in reverse depends. ```

dankelley commented 10 months ago

Below is a checklist, with things checked off as 1.8-2 becomes available on a CRAN mirror. I'll check once in a while for updates.

[x] Package source
[x] Windows r-devel
[x] Windows r-release
[x] Windows r-oldrel
[x] macOS r-release (arm64)
[x] macOS r-oldrel (arm64)
[x] macOS r-release (x86_64)
[ ] macOS r-oldrel (x86_64)

dankelley commented 10 months ago

I'm not going to wait for the macOS r-oldrel , although I'll reopen this if I check again in a week and see that there are problems.

dankelley / oce

need to alter for CRAN #2172