Re: [R-pkg-devel] apparent S3 methods note in R CMD check

2015-06-12 Thread Thomas Petzoldt

Dear Martin, dear package developers,

I had a very similar case three days ago in one of our packages. Our aim
was to provide an S3 method matplot.deSolve and an alternative and more
specific non-S3 function matplot.1D because the .1D follows the naming
scheme of other related functions.

The note of R 3.2.0 could be suppressed by (wrongly) declaring the
non-S3 variant as S3method, but finally I decided to use an
S4-compatibility approach instead:


setGeneric(matplot, function(x, ...) graphics::matplot(x, ...))
setOldClass(deSolve)

setMethod(matplot, list(x = deSolve), matplot.deSolve)


... with the downside that deSolve::matplot now masks graphics::matplot


So I would appreciate if matplot could be made a generic. Or is there
another way round?

Thomas


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

E-Mail: thomas.petzo...@tu-dresden.de
http://tu-dresden.de/Members/thomas.petzoldt

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


[R-pkg-devel] use of `dev.new` across platforms in RStudio

2015-06-12 Thread Alex Chubaty
Dear list members,

Use of platform-specific code to open new plot devices (e.g., `quartz`,
`x11`) is discouraged in favour of using `dev.new`; however, this does not
work in RStudio. A purported solution introduced in R 3.1.1 was to call
`dev.new(noRStudioGD = TRUE)`, which works on Windows, but not OSX and
Ubuntu. On these paltforms `dev.new` does not open a new plotting window,
but instead a PDF device writing to file Rplots.pdf.

How can I open a new plot window in my package in a CRAN-approved way that
works reliably across platforms when using RStudio? Perhaps this is an
issue to take up with RStudio and/or R-Devel directly, but I'd appreciate
any insights or suggestions any of you may have.

Thank you for your help,

Alex

[[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] apparent S3 methods note in R CMD check

2015-06-12 Thread Roebuck,Paul L
Actually, between this and other things coming from 'R CMD check' these
days,
I disagree that this is reasonable at all - it's a hack at best that only
fixes
this particular issue. Better would be to introduce lint-like directives
that
turn off certain R CMD check notes/warnings at different scopes
(e.g., #pylint: disable=some-message,another-one) rather than introduce
individual workarounds. Would give us an extensible version of the
--no-nanny
option Kevin wants.


On 6/12/15 5:38 AM, John Fox j...@mcmaster.ca wrote:

Dear Martin,

Thank you for addressing this issue. Introducing a nonS3method()
directive in NAMESPACE
seems a reasonable solution. It could replace export() for functions with
.s in their names.

Best,
 John

On Fri, 12 Jun 2015 09:55:18 +0200
 Martin Maechler maech...@stat.math.ethz.ch wrote:
  John Fox j...@mcmaster.ca
  on Wed, 10 Jun 2015 10:12:46 -0400 writes:
 
  Dear list members,
  One of the packages I maintain, effects, generates the following
note in R
  CMD check:
 
  * checking S3 generic/method consistency ... NOTE
  Found the following apparent S3 methods exported but not
registered:
  all.effects
 
  The offending function, all.effects(), is deprecated in favour of
  allEffects(), but I'd rather not get rid of it for backwards
compatibility.
  Is there any way to suppress the note without removing
all.effects()? 
 
  To be clear, all.effects() is *not* a method of all(), and is
defined as
 
  effects::all.effects
  function (...)
  {
   .Deprecated(allEffects)
   allEffects(...)
  }
 
 Dear John,
 this is a good question without an obvious answer for the
 moment.
 
 The check producing it is relatively new *and* has helped to
 detect problems in many packages and places,  but I would agree
 is a False Positive in this case.
 
 One reason for such a check is the following output {in R = 3.2.0},
 
   require(effects)
  Loading required package: effects
   methods(all)
  [1] all,ddiMatrix-method all,ldiMatrix-method
all,lsparseMatrix-method
  [4] all,Matrix-methodall,nsparseMatrix-method all.effects
   
  see '?methods' for accessing help and source code
  
 
 which wrongly does list your all.effects() among the all
 methods and indeed (even worse), it *is* taken as S3 method
 for all():
  
   ex - structure(FALSE, class=effects)
   all(ex)
  Error: $ operator is invalid for atomic vectors
  In addition: Warning message:
  'all.effects' is deprecated.
  Use 'allEffects' instead.
  See help(Deprecated)
   
 
 ---
 
 Now I agree .. and have e-talked about this with another R core
 member .. that it would be desirable for the package author to
 effectively declare the fact that such a function is not an S3
 method even though it looks like it at least if looked from far.
 
 So, ideally, you could have something like
 
  nonS3method(all.effects)
 
 somewhere in your package source ( in NAMESPACE or R/*.R )
 which would tell the package-checking code -- but *ALSO* all the other
S3
 method code that  all.effects should be treated as a regular R
 function.
 
 I would very much like such a feature in R, and for that reason,
 I'm cross posting this (as one of the famous exceptions that
 accompany real-life rules!!) to R-devel.
 
 There is one current work-around -- some would say hack -- in the R
sources
 for exceptions on a per package basis, and I will now activate
 that workaround for you.
 
 Martin


__
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