Re: [R-pkg-devel] Windows binary package not at mirrors
On 2024-06-23 2:18 a.m., Agner Fog wrote: On 23/06/2024 00.15, Duncan Murdoch wrote: As far as I know, CRAN doesn't push changes to the mirrors, the mirrors pull changes from CRAN. So if you are seeing that message, the problem is likely with the mirror you're using. Which mirror is that? All of them. I tried many different mirrors. What version of R are you using? I see the binary in the 4.4 binaries here: https://cloud.r-project.org/bin/windows/contrib/4.4/BiasedUrn_2.0.12.zip and here: https://cloud.r-project.org/bin/windows/contrib/4.3/BiasedUrn_2.0.12.zip CRAN only builds Windows binaries for the devel version, the current release, and the previous release, so nothing older than 4.3.0 will get it. Duncan Murdoch On 2024-06-22 3:36 a.m., Agner Fog wrote: I received this message 3 days ago: Your package BiasedUrn_2.0.12.tar.gz has been built for Windows and will be published within 24 hours in the corresponding CRAN directory. However, when I try to load the package, I get this message: Do you want to install from sources the package which needs compilation? If I say yes, it compiles the package on my computer, provided that I have installed the compiler. If I say no, I get the previous version of the package. The Windows binary is at https://cran.r-project.org/web/packages/BiasedUrn/index.html , but not at the mirrors. Is the Windows binary version of my package delayed, or has it not been sent to the mirrors? __ 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] Windows binary package not at mirrors
On 23/06/2024 09.56, Duncan Murdoch wrote: CRAN only builds Windows binaries for the devel version, the current release, and the previous release, so nothing older than 4.3.0 will get it. Thank you. Updating R helped. BTW, I don't think we need so many mirrors. They were needed only a long time ago when network bandwidth was much lower than it is today. - Agner __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows binary package not at mirrors
On 2024-06-23 5:44 a.m., Agner Fog wrote: On 23/06/2024 09.56, Duncan Murdoch wrote: CRAN only builds Windows binaries for the devel version, the current release, and the previous release, so nothing older than 4.3.0 will get it. Thank you. Updating R helped. BTW, I don't think we need so many mirrors. They were needed only a long time ago when network bandwidth was much lower than it is today. I think you are probably right, but they don't cost CRAN very much, and most of them don't cost the operators very much either. One exception is the one run by Posit: because it is cloud based, I think they spend quite a lot of money on it. (I don't know the exact number, but I suspect it is in the tens of thousands of dollars per year.) The fact that they spend so much on it means that it is very reliable, and it's the one I use almost all the time. But it's also a vulnerability: if Posit decided that they could better spend their money elsewhere, they could shut it down. So I'm quite happy that there are a lot of other ones available. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows binary package not at mirrors
Duncan Murdoch wrote on 2024-06-23 13:04: […] One exception is the one run by Posit: because it is cloud based, I think they spend quite a lot of money on it. […] it means that it is very reliable, and it's the one I use almost all the time. I agree. It is also helpful for developers of packages because they can use badges based on METACRAN’s data (which itself evaluates the Posit mirror) to get an idea about the number of downloads (total and of the current version per month). Example: https://github.com/Detlew/PowerTOST/blob/master/README.md Helmut Schütz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows binary package not at mirrors
Also, I think the system should recommend to the user to update RStudio when a package is not available for the installed version. The current message does not tell the cause of the problem. It just says: Do you want to install from sources the package which needs compilation? - Agner __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows binary package not at mirrors
On 2024-06-23 8:01 a.m., Agner Fog wrote: Also, I think the system should recommend to the user to update RStudio when a package is not available for the installed version. The current message does not tell the cause of the problem. It just says: Do you want to install from sources the package which needs compilation? Updating RStudio wouldn't help, that needs an R update, but it seems like a possibly useful suggestion. What would be your suggested wording? Should it depend on R trying to figure out if the current version is old? Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Windows binary package not at mirrors
It is probably checking the version anyway. If a binary package is available for a later version, then it may say something like: "The latest version of the binary package does not match your currently installed version of R. You may update R, or you may compile the package for the installed version of R, or you may use an older version of the package. Do you want to compile the package?" - Agner On 23/06/2024 14.48, Duncan Murdoch wrote: On 2024-06-23 8:01 a.m., Agner Fog wrote: Also, I think the system should recommend to the user to update RStudio when a package is not available for the installed version. The current message does not tell the cause of the problem. It just says: Do you want to install from sources the package which needs compilation? Updating RStudio wouldn't help, that needs an R update, but it seems like a possibly useful suggestion. What would be your suggested wording? Should it depend on R trying to figure out if the current version is old? Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] "Writing R Extensions" manual needs update [was: Error handling in C code]
Jarrod Hadfield wrote: > Using Rf_error() rather than error() fixed the problem. Not sure why the > problem was only flagged on Debian, but it > seems to have been triggered by R_NO_REMAP being defined (which will be > default in R 4.5.0). I had the same problem. A lot of functions in my package 'BiasedUrn' had to be changed to the Rf_ prefix names. It took me a long time to figure out because I couldn't find proper documentation anywhere. Apparently, the remapped function names can no longer be used. The consequences of this change are far-reaching: /all /existing packages containing C++ code must be modified to use the Rf_ function names for /all /R API function calls. This change is not properly documented. The "Writing R Extensions" manual still lists the remapped function names without Rf_ prefix. This manual needs to be updated to replace all remapped function names with the Rf_ prefix names. I also think that it needs to add instructions on how to fix legacy C++ code, including a list of the function names that need to be changed. I cannot see where the change in R_NO_REMAP is documented. I don't know why R_NO_REMAP is currently defined in Debian but not in Windows, but the consequence is that the "Writing R Extensions" manual must be updated now, and not wait for R version 4.5.0. I think there should be a way to enable the remapped function names for the sake of compatibility with legacy code. What should we do with old packages where the maintainer is no longer contactable or is somebody less competent than the original programmer? Does it work to #undef R_NO_REMAP before #include ? Let me suggest a simple solution: Define a preprocessing macro R_FORCE_REMAP which can override R_NO_REMAP. Legacy C++ code can then be fixed by adding a Makevars file with -DR_FORCE_REMAP You may also reconsider the decision to add R_NO_REMAP as standard. I have written to the maintainers and asked them to change the "Writing R Extensions" manual, but got no reponse. - Agner [[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] "Writing R Extensions" manual needs update [was: Error handling in C code]
On 6/24/24 08:25, Agner Fog wrote: Jarrod Hadfield wrote: Using Rf_error() rather than error() fixed the problem. Not sure why the problem was only flagged on Debian, but it seems to have been triggered by R_NO_REMAP being defined (which will be default in R 4.5.0). I had the same problem. A lot of functions in my package 'BiasedUrn' had to be changed to the Rf_ prefix names. It took me a long time to figure out because I couldn't find proper documentation anywhere. Apparently, the remapped function names can no longer be used. The consequences of this change are far-reaching: /all /existing packages containing C++ code must be modified to use the Rf_ function names for /all /R API function calls. This change is not properly documented. The "Writing R Extensions" manual still lists the remapped function names without Rf_ prefix. This manual needs to be updated to replace all remapped function names with the Rf_ prefix names. I also think that it needs to add instructions on how to fix legacy C++ code, including a list of the function names that need to be changed. I cannot see where the change in R_NO_REMAP is documented. I don't know why R_NO_REMAP is currently defined in Debian but not in Windows, but the consequence is that the "Writing R Extensions" manual must be updated now, and not wait for R version 4.5.0. I think there should be a way to enable the remapped function names for the sake of compatibility with legacy code. What should we do with old packages where the maintainer is no longer contactable or is somebody less competent than the original programmer? Does it work to #undef R_NO_REMAP before #include ? Let me suggest a simple solution: Define a preprocessing macro R_FORCE_REMAP which can override R_NO_REMAP. Legacy C++ code can then be fixed by adding a Makevars file with -DR_FORCE_REMAP You may also reconsider the decision to add R_NO_REMAP as standard. I have written to the maintainers and asked them to change the "Writing R Extensions" manual, but got no reponse. In principle it is the NEWS file that gives hints about important changes and then one can find the details in Writing R Extensions. The NEWS file as of mid-April says that "R CMD check --as-cran" will compile C++ code with -DR_NO_REMAP. And then in Writing R Extensions, one can read about what is R_NO_REMAP and that this has been planned to become the default in the future. It is an important thing to do for the maintainability of the package space: the situation with name clashes with system headers (typically appearing just on some platforms) has only been getting worse. Best Tomas - Agner [[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
