[Rd] problem with vignettes when S4 classes in packages overlap
Spencer Graves
spencer.graves at prodsyse.com
Wed Sep 19 04:02:49 CEST 2012
On 9/18/2012 5:53 PM, Duncan Murdoch wrote:
> On 12-09-18 7:50 PM, Spencer Graves wrote:
>> On 9/18/2012 4:23 PM, Duncan Murdoch wrote:
>>> On 12-09-18 5:40 PM, Paul Gilbert wrote:
>>>>
>>>> ( A similar problem is also reported by Sebastian P. Luque with
>>>> library(maptools)
>>>> library(trip)
>>>> in the vignette as below ).
>>>>
>>>> I am writing a vignette which loads RMySQL and RPostgreSQL. This
>>>> produces the warning:
>>>>
>>>> Loading required package: DBI
>>>> Warning in .simpleDuplicateClass(def, prev) :
>>>> A specification for class “dbObjectId” in package ‘RPostgreSQL’
>>>> seems
>>>> equivalent to one from package ‘RMySQL’ and is not turning on
>>>> duplicate
>>>> class definitions for this class
>>>>
>>>> This can be reproduced by running
>>>> R CMD Sweave --pdf Atest.Stex
>>>>
>>>> where the file Atest.Stex has the lines
>>>>
>>>> \documentclass{article}
>>>> \usepackage{Sweave}
>>>> \begin{document}
>>>> \begin{Scode}
>>>> library("RMySQL")
>>>> library("RPostgreSQL")
>>>> \end{Scode}
>>>> \end{document}
>>>>
>>>> These warnings only happen in a vignette. They are not produced if the
>>>> lines are entered in an R session.
>>>>
>>>> (Using R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows" on
>>>> Ubunt
>>>
>>> You'll get the warning in a regular session if you set
>>> options(warn=1). I think Sweave is probably doing this so that
>>> warnings show up around the time of the chunk they correspond to. It
>>> does it in the command line version, but not in the Sweave() function
>>> (which would save them up to the end).
>>>
>>> I don't know if the warning is something you should worry about or not.
>>
>>
>> On August 30, 2012, CRAN maintainers rejected the latest version
>> of "fda", and I understood them to say it was rejected because the
>> current CRAN policy did not accept packages reporting either "Notes" or
>> "Warnings". As part of my efforts to comply with this, I started the
>> thread on [Rd] subject: "if(--as-cran)?" I added a function "CRAN" to
>> "fda", and I thought someone had added a more general function to the
>> development version of R. Unfortunately, I can't find documentation of
>> that more general function now.
>
> I don't remember for sure, but I don't think your warning or note was
> the same as Paul's. Generally it's not a good idea to suppress
> warnings. Someone should fix things so there's no warning. I don't
> know if that should be RCore because the methods package is issuing a
> bogus warning, or the maintainer of one of the database packages, or
> Paul. (From his example, it doesn't look like it should be Paul,
> unless docs somewhere say that RMySQL and RPostgreSQL can't be used
> together.)
>
> In general, as a package user, I don't want people to be able to
> suppress checks on CRAN. I want things fixed.
>
> So I am pretty sure there won't ever be a reliable "CRAN-detector" put
> into R. It would devalue the brand.
Our primary use of the "CRAN" function is to reduce test time:
Some of our "\examples" ran over 10 seconds on CRAN, and the package was
rejected on that basis.
With now over 4,000 packages on CRAN, maintaining it is taxing
the commitments of our volunteer CRAN maintainers. I believe the world
would be better off if people like Brian Ripley, Kurt Hornik, and Uwe
Ligges could hire (more) competent systems administrators and buy (more)
hardware to manage the details, so Ripley, Hornik, Ligges and others
could spend more time developing new statistical algorithms and helping
others with their responses on this list.
Assuming money is part of the problem, Jim Ramsay suggested that
CRAN issue a pro forma invoice to CRAN package maintainers for, say, 100
Euros each. Maintainers would be asked to pay it if they have a grant
that would support that but would be invited to plead poverty if they
don't. This would be similar to the current page charges with some
journals, which are forgiven for authors who would have to pay out of
their own pockets. Ramsay said he would happily pay some reasonable
amount, but he needs an invoice.
The same goes for R-Forge: It's a great service to the R
Community -- benefiting the entirety of humanity through the improved
decisions that R facilitates. They, too, could offer a better service
if they had a larger budget, I think.
Best Wishes,
Spencer
>
> Duncan Murdoch
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Spencer Graves, PE, PhD
President and Chief Technology Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
web: www.structuremonitoring.com
More information about the R-devel
mailing list