Am 02.09.2016 um 16:02 schrieb Dirk Eddelbuettel:
On 2 September 2016 at 14:54, Thomas Petzoldt wrote: | Hi, | | I have the same problem and, at a first look, the issues reported by the | CRAN checks seemed easy to fix. However, after checking it again locally | and on http://win-builder.r-project.org it appeared that GCC 4.9.3 | (Windows, Rtools 3.4), same also on win-builder reports even more | issues, especially legacy Fortran (mainly Roger's #2 and #3), but also | | "warning: ISO C forbids conversion of object pointer to function pointer | type" | | The latter results from using pointers returned by R_ExternalPtrAddr() | for calling user-defined functions in DLLs, cf. the following thread | from the very beginning: | https://stat.ethz.ch/pipermail/r-devel/2004-September/030792.html | | What is now expected to do? | | 1. Is it really the intention to start a complete rewrite of all legacy | Fortran code? | | 2. Is there now a better way for calling user functions than | R_ExternalPtrAddr()? See this commit (where I apologize for referring to GitHub as the non-canonical source, but it presents things in pretty enough manner) by Brian Ripley just a few days ago: https://github.com/wch/r-source/commit/a528a69b98d3e763c39cfabf9b4a9e398651177c So R 3.4.0 will have R_MakeExternalPtrFn() and R_ExternalPtrAddrFn().
Thank you very much for this hint, sounds very promising! I was indeed looking for something like this in the R docs+sources, but didn't expect that it is that hot. Now I found it now also in the canonical svn sources ;)
I am little bit concerned, how fast this should be forced by CRAN because of back-compatibility, and if compiler derivatives are worth the effort for this ...
Remains issue #1 with "Obsolescent features" of legacy Fortran. While updating my Fedora test system, it seems that there are many other packages around that use this sort of old-style, and well tested (!!!) Fortran ...
Thomas [...]
| Am 28.08.2016 um 23:48 schrieb Roger Koenker: | > Hi Kurt, | > | > I have started to look into this, and I need some guidance about how to | > prioritize my repairs. There are basically 4 categories of warnings from | > gfortran’s pedantic critique of my packages: | > | > 1. Some errant tab characters it doesn’t like, | > 2. Too many or too few continue statements | > 3. Horrible (and obsolescent) arithmetic and computed gotos | > 4. undeclared doubles and dubious conversions | > | > The last category seems relatively easy to fix and is potentially | > important, but the others seem more difficult to fix and altogether | > less important. The goto issues are all in code that has been written | > long ago by others and imported, e.g. Peyton and Ng’s cholesky.f. | > I’m very reluctant to mess with any of those gotos. The fact that | > they were declared obsolete long ago doesn’t mean that gfortran | > has any intention of not supporting these constructs in the future, | > does it? | > | > Before devoting more time and energy, which is in short supply | > lately, I like to hear what others are thinking/doing about all this, | > so I’ll copy this to r-devel. | > | > All the best, | > Roger | > | > url: www.econ.uiuc.edu/~roger Roger Koenker | > email rkoen...@uiuc.edu Department of Economics | > vox: 217-333-4558 University of Illinois | > fax: 217-244-6678 Urbana, IL 61801 | > | > | >> On Aug 28, 2016, at 2:36 AM, Kurt Hornik <kurt.hor...@wu.ac.at> wrote: | >> | >> | >> Dear maintainers, | >> | >> This concerns the CRAN packages | > | > ---- | >> | >> Using gfortran with options -Wall -pedantic to compile your package | >> Fortran code finds important problems, see your package check pages for | >> more information. | >> | >> Can you please fix these problems as quickly as possible? | >> | >> Best | >> -k | > | > ______________________________________________ | > R-devel@r-project.org mailing list | > https://stat.ethz.ch/mailman/listinfo/r-devel | >
-- Thomas Petzoldt thomas.petzo...@tu-dresden.de http://tu-dresden.de/Members/thomas.petzoldt ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
