Re: CRAN packages maintained by you

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CRAN packages maintained by you

Roger Koenker-3
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    [hidden email]            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 <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: CRAN packages maintained by you

Thomas Petzoldt
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()?


Many thanks for clarification,

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    [hidden email]            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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


--
Dr. Thomas Petzoldt
Technische Universitaet Dresden
Faculty of Environmental Sciences
Institute of Hydrobiology
01062 Dresden, Germany

Tel.: +49 351 463 34954
Fax:  +49 351 463 37108
E-Mail: [hidden email]
http://tu-dresden.de/Members/thomas.petzoldt

-- limnology and ecological modelling --

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: CRAN packages maintained by you

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().

(Hat tip to Duncan's very useful NEWS summary robot-blog which I read daily).

Dirk
 
 
| Many thanks for clarification,
|
| 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    [hidden email]            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 <[hidden email]> 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
| >
| > ______________________________________________
| > [hidden email] mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
|
|
| --
| Dr. Thomas Petzoldt
| Technische Universitaet Dresden
| Faculty of Environmental Sciences
| Institute of Hydrobiology
| 01062 Dresden, Germany
|
| Tel.: +49 351 463 34954
| Fax:  +49 351 463 37108
| E-Mail: [hidden email]
| http://tu-dresden.de/Members/thomas.petzoldt
|
| -- limnology and ecological modelling --
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: CRAN packages maintained by you

Thomas Petzoldt
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    [hidden email]            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 <[hidden email]> 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
> | >
> | > ______________________________________________
> | > [hidden email] mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-devel
> | >


--
Thomas Petzoldt
[hidden email]
http://tu-dresden.de/Members/thomas.petzoldt

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel