Re: [R-pkg-devel] .Fortran opinion
If you read further in Drew's posts (which I highly recommend) he says that C++/Rcpp isn't the best for wrapping Fortran calls, and that it is faster and cleaner to use C. I have a relatively detailed blog post on building packages with Fortran (or raw C) code; I hope you may find it useful in your case [1]. Thanks, Avi [1] https://www.avrahamadler.com/2018/12/09/the-need-for-speed-part-1-building-an-r-package-with-fortran/ On Sun, May 26, 2019 at 3:22 PM Neal Fultz wrote: > > I think the current best practice is to wrap the Fortran code in a C > helper, and invoke that using .Call - more information on that is available > in Hadley's book - http://adv-r.had.co.nz/C-interface.html > > It shouldn't be too much work, maybe another 10-20 lines of code, most of > which could probably autogenerated using Rcpp if you wanted to take that > route. > > On Sun, May 26, 2019 at 6:31 AM Berry Boessenkool < > berryboessenk...@hotmail.com> wrote: > > > > > Recently, users of my package rdwd have provided Fortran code for a nice > > extension of the package. > > According to the following site, calling .Fortran() is no longer > > recommended: > > https://github.com/wrathematics/Romp/blob/master/README.md#fortran > > > > Since this is my first time using native code, I'd highly appreciate any > > thoughts on the following question: > > How much additional work should I put into avoiding .Fortran() for > > long-term CRAN suitability? > > > > Thanks ahead, > > Berry > > > > PS: In case you want a look at the (two very short) Fortran routines: > > https://github.com/brry/rdwd/tree/master/src > > and their call in R: > > https://github.com/brry/rdwd/blob/master/R/readRadarFile.R#L119 > > > > > > [[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] .Fortran opinion
I think the current best practice is to wrap the Fortran code in a C helper, and invoke that using .Call - more information on that is available in Hadley's book - http://adv-r.had.co.nz/C-interface.html It shouldn't be too much work, maybe another 10-20 lines of code, most of which could probably autogenerated using Rcpp if you wanted to take that route. On Sun, May 26, 2019 at 6:31 AM Berry Boessenkool < berryboessenk...@hotmail.com> wrote: > > Recently, users of my package rdwd have provided Fortran code for a nice > extension of the package. > According to the following site, calling .Fortran() is no longer > recommended: > https://github.com/wrathematics/Romp/blob/master/README.md#fortran > > Since this is my first time using native code, I'd highly appreciate any > thoughts on the following question: > How much additional work should I put into avoiding .Fortran() for > long-term CRAN suitability? > > Thanks ahead, > Berry > > PS: In case you want a look at the (two very short) Fortran routines: > https://github.com/brry/rdwd/tree/master/src > and their call in R: > https://github.com/brry/rdwd/blob/master/R/readRadarFile.R#L119 > > > [[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
Re: [R-pkg-devel] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes
Thank
Thank you Martin for your help and for this solution, warnings
disappeared with this, and i've re-submitted the package.
Best,
Emmanuel
Le 26/05/2019 à 10:13, Martin Morgan a écrit :
Since ncdf4 (and emld) both use S3 class systems, it is sufficient to simply
declare
setOldClass("ncdf4")
some time prior to using setAs() .
Martin
On 5/24/19, 6:41 PM, "R-package-devel on behalf of Emmanuel Blondel (GMAIL)"
wrote:
Dear all, I write here as i'm in process to submit a revision of
/geometa/ package to CRAN in which i've enabled some coercing methods
between main metadata object ISOMetadata from geometa, and foreign
metadata objects (from emld / ncdf4 packages)
I've received a "pre-test archived" notification, because of the
folllowing warnings dealing with the coercing:
Warning: in method for 'coerce' with signature '"ISOMetadata","emld"': no definition for classes "ISOMetadata", "emld"
Warning: in method for 'coerce' with signature '"emld","ISOMetadata"': no definition for
classes "emld", "ISOMetadata"
Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"': no definition for
classes "ncdf4", "ISOMetadata"
Detail at:
https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log
I've found this thread that seems to discuss the same matter:
https://github.com/r-spatial/sf/issues/129 . I'm facing the same
situation where there is no good reason enough to add emld, ncdf4 as
Imports, but rather to keep them as Suggests, as they are only used in
these specific converters. In the doubt, i prefer asking here if there
is some good practice to deal with these warnings, eventually to avoid
it, or if this is considered by CRAN team as false positive.
Thanks a lot for your advice,
Best,
Emmanuel
[[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] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes
Since ncdf4 (and emld) both use S3 class systems, it is sufficient to simply
declare
setOldClass("ncdf4")
some time prior to using setAs() .
Martin
On 5/24/19, 6:41 PM, "R-package-devel on behalf of Emmanuel Blondel (GMAIL)"
wrote:
Dear all, I write here as i'm in process to submit a revision of
/geometa/ package to CRAN in which i've enabled some coercing methods
between main metadata object ISOMetadata from geometa, and foreign
metadata objects (from emld / ncdf4 packages)
I've received a "pre-test archived" notification, because of the
folllowing warnings dealing with the coercing:
Warning: in method for 'coerce' with signature '"ISOMetadata","emld"':
no definition for classes "ISOMetadata", "emld"
Warning: in method for 'coerce' with signature '"emld","ISOMetadata"':
no definition for classes "emld", "ISOMetadata"
Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"':
no definition for classes "ncdf4", "ISOMetadata"
Detail at:
https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log
I've found this thread that seems to discuss the same matter:
https://github.com/r-spatial/sf/issues/129 . I'm facing the same
situation where there is no good reason enough to add emld, ncdf4 as
Imports, but rather to keep them as Suggests, as they are only used in
these specific converters. In the doubt, i prefer asking here if there
is some good practice to deal with these warnings, eventually to avoid
it, or if this is considered by CRAN team as false positive.
Thanks a lot for your advice,
Best,
Emmanuel
[[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] Re : Advice on setAs - issue of "in method for 'coe
Hi, I can give you an advise: try to use (ISO) official code for the geometries and put it as characters. Sylvain Envoyé depuis Yahoo Mail pour Android Le sam., mai 25, 2019 à 0:41, Emmanuel Blondel (GMAIL) a écrit : Dear all, I write here as i'm in process to submit a revision of /geometa/ package to CRAN in which i've enabled some coercing methods between main metadata object ISOMetadata from geometa, and foreign metadata objects (from emld / ncdf4 packages) I've received a "pre-test archived" notification, because of the folllowing warnings dealing with the coercing: Warning: in method for 'coerce' with signature '"ISOMetadata","emld"': no definition for classes "ISOMetadata", "emld" Warning: in method for 'coerce' with signature '"emld","ISOMetadata"': no definition for classes "emld", "ISOMetadata" Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"': no definition for classes "ncdf4", "ISOMetadata" Detail at: https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log I've found this thread that seems to discuss the same matter: https://github.com/r-spatial/sf/issues/129 . I'm facing the same situation where there is no good reason enough to add emld, ncdf4 as Imports, but rather to keep them as Suggests, as they are only used in these specific converters. In the doubt, i prefer asking here if there is some good practice to deal with these warnings, eventually to avoid it, or if this is considered by CRAN team as false positive. Thanks a lot for your advice, Best, Emmanuel [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel Dear all, I write here as i'm in process to submit a revision of /geometa/ package to CRAN in which i've enabled some coercing methods between main metadata object ISOMetadata from geometa, and foreign metadata objects (from emld / ncdf4 packages) I've received a "pre-test archived" notification, because of the folllowing warnings dealing with the coercing: Warning: in method for 'coerce' with signature '"ISOMetadata","emld"': no definition for classes "ISOMetadata", "emld" Warning: in method for 'coerce' with signature '"emld","ISOMetadata"': no definition for classes "emld", "ISOMetadata" Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"': no definition for classes "ncdf4", "ISOMetadata" Detail at: https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log I've found this thread that seems to discuss the same matter: https://github.com/r-spatial/sf/issues/129 . I'm facing the same situation where there is no good reason enough to add emld, ncdf4 as Imports, but rather to keep them as Suggests, as they are only used in these specific converters. In the doubt, i prefer asking here if there is some good practice to deal with these warnings, eventually to avoid it, or if this is considered by CRAN team as false positive. Thanks a lot for your advice, Best, Emmanuel [[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
