[Rd] CRAN packages maintained by you

Thomas Petzoldt thomas.petzoldt at tu-dresden.de
Fri Sep 2 17:13:56 CEST 2016


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    rkoenker at 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.Hornik at 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 at r-project.org mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-devel
> | >


-- 
Thomas Petzoldt
thomas.petzoldt at tu-dresden.de
http://tu-dresden.de/Members/thomas.petzoldt



More information about the R-devel mailing list