Re: [R-pkg-devel] Modernizing legacy Fortran:, REAL(kind=8)
On 30.08.2023 at 11:58 Ivan Krylov wrote: On Wed, 30 Aug 2023 08:43:04 +0200 Thomas Petzoldt wrote: a) change REAL(kind=8) back to DOUBLE PRECISION that is again old style. It seems to be portable and is still widely used. I don't have a reference as good as the Fortran standard, but Steve Lionel said in Dr. Fortran [*] that DOUBLE PRECISION is still part of the standard fixed-form syntax. COMPLEX(KIND=8) This could be particularly problematic if you're trying to interoperate with C, but will probably not surface unless you use LTO: https://bugs.r-project.org/show_bug.cgi?id=18430 Unfortunately, there's no standard DOUBLE COMPLEX. Thank you, this helps. I had a look in Dr. Fortran myself and some other sites, but especially the COMPLEX definitions remain unclear. I tried now the following, because the included original Fortran codes follow slightly different standards: - replace COMPLEX(KIND=8) with DOUBLE COMPLEX in source files that use DOUBLE PRECISION otherwise - replace real(kind=8) with real(kind=kind(0.0d0)) in the more modern source files This is pragmatic and may not be the best way, but looks mostly consistent. Now I checked the package and everything was ok, but I was not able reproduce the warnings from the previous version. I assume that I have to set an environment variable to see the warnings, but which one? I use gfortran/gcc 13.2.1-1 on Fedora 38. Thanks! Thomas -- https://tu-dresden.de/Members/thomas.petzoldt __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Modernizing legacy Fortran:, REAL(kind=8)
Hi, some package maintainers including me got a reminder from Prof. Brian Ripley to modernize REAL and INTEGER declarations using the KIND option: On 29.08.2023 at 19:31 Prof Brian Ripley wrote: According to the Fortran standards, numerical values are just an enumeration, and what e.g. real(kind=4) means (or even if it is accepted) is implementation dependent. We see such constructs in packages [... line with packages deleted to avoid exposing the other packages and authors] Please change them to something portable (kind(1.0) or kind(1.0d0} are commonly used, as is c_double from iso_c_binding). Before 2023-09-26 to safely retain your package on CRAN (some of you have earlier deadlines for other issues). We use a lot of legacy code that though partly modernized due to similar requests, still uses a mix of DOUBLE PRECISION and a few REAL(KIND=8) and COMPLEX(KIND=8). As the code will still remain legacy style with respect to some other constructs, I wonder what to use to go a step forward, but remain as consistent as possible, which is of course a compromise. I see the following options: a) change REAL(kind=8) back to DOUBLE PRECISION that is again old style. It seems to be portable and is still widely used. b) just formally change the few occurrences to:REAL(kind=0.0d) as suggested. It is easy, but inconsistency remains. c) or, define "dp" as recommended in modern style guides and use it instead of REAL(kind=8) and the future also for DOUBLE PRECISION this way: integer,parameter::dp=kind(0.0d0) and then real(dp)::a,b,c However, this would need changes at many places, the mix between old and new constructswill generally get worse. Another question is, that with either of these, we may not be sure to use 8 byte double. Changing this could influence for precision and pointer arithmetics. Any recommendations? Thanks a lot! Thomas __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] preventing auto-update of R and c2d4u r-cran-* packages on Ubuntu 22.04
On 10.08.2023 at 17:56 Neal Fultz wrote: In the past, I've extracted the pre-built debian packages into the user's personal folder, instead of installing them via apt. It worked (but it was not fun), and was pretty manual. That might interact a bit better with some of the third party tools for dealing with dependencies in shiny apps, compared to system-wide installs; ymmv. Thank you for the suggestion. My implemented approach works indeed similar to this. After moving this discussion to R-SIG-Debian (https://stat.ethz.ch/pipermail/r-sig-debian/2023-August/thread.html), Dirk Eddelbuettel suggested five different approaches. I made indeed a snapshot (a local copy) of the complete "site-library" folder to another place of the file system (e.g. "site-library-snapshot"). In the .Renviron file of the shiny user, the environment variable R_LIBS_USER then points to this location. The base packages from "library" are conservative, so I decided to use them from the original position. Finally, an rmarkdown script provided by the shiny-server can report the value of .libPaths() and versions and locations of installed packages: installed.packages()[,2:3] This works well, except for a package that contained relative symbolic links to the file system. Thomas __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] preventing auto-update of R and c2d4u r-cran-* packages on Ubuntu 22.04
Hi Dirk, thank you very much dirk for the quick response. I was aware that r-package-devel may not be the optimal place ;-) but hoped to address the right audience between r-devel and r-help. Many thanks also for the suggestions, especially r2u and sorry for confusing the name of Michael. Thomas Am 09.08.2023 um 16:41 schrieb Dirk Eddelbuettel: On 9 August 2023 at 16:26, Thomas Petzoldt wrote: | I am running a couple of shiny servers with several apps that are based | around own CRAN packages. It worked stable for years, but due to the | growing number of packages, the compile time for regular manual package | installation and updates became inconvenient. | | Therefore, I have been very happy to use pre-compiled packages from the | c2d4u repository: deb | https://ppa.launchpadcontent.net/c2d4u.team/c2d4u4.0+/ubuntu/ jammy main These days you also have r2u which has all of CRAN ie 20k binaries (each, for two Ubuntu flavors). See https://eddelbuettel.github.io/r2u | This is indeed a great service, thanks to Dirk Edelbuettel, mark Rutter That would be Michael Rutter. | and the complete team! The downside is, that now the r-cran-* binaries | are installed automatically, together with the system update. I | experienced now repeated cases that crashed some of the shiny apps, | mainly due to conflicts between the binary packages and other packages | installed from sources. If you use r2u (as I do on a laptop, an ec2 server, all my CI testing for work and testing for months now) you get all packages and do not need to mix. Try r2u, it's good. | My question: what is best practise, to disallow automatic updates for | all r-cran-* packages? Uncommenting the complete package source in the | apt/sources.list.d/cd4u...list file? Fiddling around with | /etc/apt/preferences ? | | The ideal approach would be to put a plain textfile of all installed | r-cran packages somewhere to the system, where packages that are to be | upgraded (or oppositely: pinned) are just commented or outcommented. That is very Debian / Ubuntu specific question. Can I ask you to bring it to the dedicated list r-sig-debian ? From the top of my head I can think of setting package status 'hold' (a simpler per-package approach) or setting specific apt pinning values to not alter packages from specific repos, see the manual pages. But please ask on r-sig-debian. This list is for generic R packaging questions. Thanks, Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] preventing auto-update of R and c2d4u r-cran-* packages on Ubuntu 22.04
Hi, I am running a couple of shiny servers with several apps that are based around own CRAN packages. It worked stable for years, but due to the growing number of packages, the compile time for regular manual package installation and updates became inconvenient. Therefore, I have been very happy to use pre-compiled packages from the c2d4u repository: deb https://ppa.launchpadcontent.net/c2d4u.team/c2d4u4.0+/ubuntu/ jammy main This is indeed a great service, thanks to Dirk Edelbuettel, mark Rutter and the complete team! The downside is, that now the r-cran-* binaries are installed automatically, together with the system update. I experienced now repeated cases that crashed some of the shiny apps, mainly due to conflicts between the binary packages and other packages installed from sources. My question: what is best practise, to disallow automatic updates for all r-cran-* packages? Uncommenting the complete package source in the apt/sources.list.d/cd4u...list file? Fiddling around with /etc/apt/preferences ? The ideal approach would be to put a plain textfile of all installed r-cran packages somewhere to the system, where packages that are to be upgraded (or oppositely: pinned) are just commented or outcommented. Thanks in advance, Thomas __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help
Hi,
the NOTEs show that your examples require to much CPU time.
Solution: reduce CPU time of your examples by increasing efficiency of
your code, by simplification of the examples (e.g. with smaller samples
or toy data), or, if nothing else helps, by embracing examples with
\dontrun{} or \donttest{}.
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#index-_005cdontrun
As said, use this only if nothing else helps, because it reduces code
coverage of the tests: https://en.wikipedia.org/wiki/Code_coverage
Thomas
Am 21.09.2018 um 11:37 schrieb Rhys D Munden:
Hi,
received the below email about uploading a package, but I'm not sure how to
solve these problems.
Thanks
Rhys
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Changing License
Hi, we had a related discussion some time ago in the JSS editorial board. It was a long and partly emotional discussion of the pros and cons, but the good news was that if a code is MIT, it can be re-licensed as GPL, while it would not not be possible in the opposite direction (except by the original copyright holders). MIT is less political and more permissive than GPL, but its disadvantage is that someone can take your code, create derived work and then sell the derived work as closed source. Even the original developers may be excluded from derived work, or have to pay for it. The JSS board discussion ended with a request in https://www.jstatsoft.org/pages/view/authors that "Code needs to include the GNU General Public Licence (GPL), versions GPL-2 or GPL-3, or a GPL-compatible license for publication in JSS." where MIT or BSD can be considered as GPL compatible, while packages with some other licenses my need explicit double-licensing by the copyright holder, see also: https://en.wikipedia.org/wiki/License_compatibility "Many of the most common free-software licenses, especially the permissive licenses, such as the original MIT/X license, BSD licenses (in the three-clause and two-clause forms, though not the original four-clause form), MPL 2.0, and LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole (but the other license would not so apply)." I would therefore recommend GPL, and you don't make something wrong if you re-license derived work using MIT-licensed code under the GPL. Thomas PS: this is my personal conclusion, I am not a lawyer. -- Dr. Thomas Petzoldt http://tu-dresden.de/Members/thomas.petzoldt __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] registering native routines
Hi,
I assume you followed "Writing R Extension" and the examples given in
package deSolve (and maybe some other packages).
Am I right that this fixed the i386 notes, but not for x64?
Here I conclude that you tested it on Windows. This is relevant, because
I remember a recent discussion (maybe on this mailing list), that the
"register native routines" check can sometimes produce false positives
on Windows.
Would it be possible for you, to check your package on a recent Linux
system?
Thomas Petzoldt
Am 10.04.2018 um 13:19 schrieb Rampal S. Etienne:
Dear all,
I am using Fortran code with the deSolve package in my package called
"DDD". When checking my package I get the message:
checking compiled code ... NOTE
File 'DDD/libs/x64/DDD.dll':
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable symbol search.
Although it is "just" a note, I would like to solve this, but after
quite some googling, I cannot find a solution.
I have tried
tools::package_native_routine_registration_skeleton('.')
but this produces nothing, or only an empty file when I specify the
argument con. I put the following R-init_DDD.c in the src folder and
useDynLib("DDD",.registration = TRUE) in the namespace file. #include
#include #include // for NULL #include
/* .Fortran calls */ extern void
F77_NAME(fill1d)(double *vec, int *DIMP, double *parms, int *II); extern
void F77_NAME(initmod)(void (*steadyparms)(int *, double *)); extern
void F77_NAME(runmod)(int *neq, double *t, double *Conc, double *dConc,
double *yout, int *ip); static const R_FortranMethodDef FortranEntries[]
= { {"fill1d", (DL_FUNC) _NAME(fill1d), 4}, {"initmod", (DL_FUNC)
_NAME(initmod), 1}, {"runmod", (DL_FUNC) _NAME(runmod), 6},
{NULL, NULL, 0} }; void R_init_DDD(DllInfo *dll) {
R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE); }
Note that I only get the message for x64, but I don't get it for i386,
which I did before. So somehow, this is only an issue on 64-bit? How do
I fix this?
Regards,
Rampal
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] S4 generic with variable naming of arguments
Dear colleagues,
after testing one of my packages with students, I'm trying to improve
the user interface, to make it even simpler and more robust. The package
uses S4 classes and I was very happy with this, but my aim is now to
allow non-named arguments with different ordering, depending on their
class and with and 'speaking argument names', not simply x and y.
It looks to me as this could be a FAQ and please excuse if I overlooked
something, but I still wonder. Let's assume a generic like this:
foo <- function(formula, data, grouping, ...)
It is of course easy in S4 write methods that allow either
'foo(y ~ x, df)' or 'foo(data = df, grouping = g)'
but I want to allow also 'foo(df, g)'
This works easily in S3 (see below), but [how] can this also be done
with S4 to avoid mixture of class systems in the package?
Thanks a lot!
Thomas
### Example ##
foo <- function(formula, data, grouping = NULL, ...) UseMethod("foo")
foo.formula <- function(formula, data, ...) {
cat("formula method\n")
}
foo.data.frame <- function(data, grouping, ...) {
cat("data method\n")
}
foo.default <- function(data, ...)
cat("method for class", class(data), "not yet implemented\n")
df <- data.frame(x=1:10, y=runif(10), groups=rep(c("a", "b"), 5))
foo(y~x, df)# easy in S4
foo(df, grouping="groups") # easy in S3, but how in S4?
foo(1)
##
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] apparent S3 methods note in R CMD check
Dear Martin, dear package developers, I had a very similar case three days ago in one of our packages. Our aim was to provide an S3 method matplot.deSolve and an alternative and more specific non-S3 function matplot.1D because the .1D follows the naming scheme of other related functions. The note of R 3.2.0 could be suppressed by (wrongly) declaring the non-S3 variant as S3method, but finally I decided to use an S4-compatibility approach instead: setGeneric(matplot, function(x, ...) graphics::matplot(x, ...)) setOldClass(deSolve) setMethod(matplot, list(x = deSolve), matplot.deSolve) ... with the downside that deSolve::matplot now masks graphics::matplot So I would appreciate if matplot could be made a generic. Or is there another way round? Thomas -- Dr. Thomas Petzoldt Technische Universitaet Dresden Faculty of Environmental Sciences Institute of Hydrobiology 01062 Dresden, Germany E-Mail: thomas.petzo...@tu-dresden.de http://tu-dresden.de/Members/thomas.petzoldt __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
