[Rd] setGeneric() gives "must supply skeleton" when checking package
r-devel,
In a development version of the CRAN package metrumrg, I write ...
require(reshape)
setGeneric('cast')
setOldClass(c('keyed','data.frame'))
setMethod('cast','keyed', function ...)
The result is satisfactory when sourcing the code directly, but when
checking the package (which has 'reshape' as a dependency in the
DESCRIPTION file) I get the following:
"Error in setGeneric("cast") : must supply a function skeleton for
???cast???, explicitly or via an existing function."
The help for setGeneric() seems to suggest that no function skeleton is
needed when creating a generic for a function defined in some other
package. I found one or two previous related posts, but no obvious
resolution.
Comments appreciated,
Tim Bergsma, PhD
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug: C-level and _set_rl_word_breaks
On 2013-01-31 21:52, Laurent Gautier wrote: On 2013-01-31 21:09, Duncan Murdoch wrote: On 13-01-30 9:48 PM, Laurent Gautier wrote: Hi, I filed a bug report in the tracker (id #15169) a short while ago, along with a patch, but I came back to it to see that there is relatively little movement or participation on the tracker so I thought I'd pitch it here (patch attached). The function `set_rl_word_breaks` in src/unix/sys-std.c relies on statically-allocated strings local to the function, making other C code using the readline library, such as a program embedding R and using readline as well, at risk of creating a segfault when trying to free `rl_basic_word_break_characters` or `rl_completer_word_break_characters` when changing them. The issue was noticed when embedding R in Python (rpy2); I had an ugly hack for a long time (less work than champion the inclusion of a patch in R) but the iPython developers pushed what could be demanded from the rpy2 with their "R magic" extension and so I wrote a patch (and they have made a brittle workaround in the meantime). The fix would be of interest to anyone embedding R in C and using readline (e.g., language interface developers if the language either has a console using readline - and chances are that it does - or an interface to readline). The patch attached is against today's R-dev and will likely apply to current R-2.15 branch. With the patch applied, R is building and is passing `make check`. It could be slightly expanded by handling cases where the calloc() or realloc() faills, although not an absolute priority (if allocating 200 bytes fails, the system might have bigger worries than keeping R from crashing). I suspect the reason your bug hasn't been dealt with in the 2 weeks since you posted it is that you don't show any code that illustrates the problem it causes. It is much easier to run some code and see that code that should be valid is causing a crash, than it is to develop code to illustrate it. Fair enough. Now I realize that this might be a part of R codebase that is hardly touched; while the problem makes sense to me after spending time on it, a demonstrating what it causes in a minimal example might be best). Easily illustrated bugs get solved before hard ones. I guess I had a free pass since I provide a solution to the bug. Your post here gives a lot more detail, but still no code. This isn't an area I'd work on (it seems to be a Unix-only bug), but you might attract someone else to look at it if you include a minimal self-contained trigger for it. I'll work on that. A minimal example to demonstrate the problem is now in the bug tracker. It shows that either a C-extension or a part of a application in which R is embedded crash R (segfault) by trying to change break delimiters. Best, Laurent Thanks, L. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setGeneric() gives "must supply skeleton" when checking package
On 02/02/2013 02:34 PM, Tim Bergsma wrote:
r-devel,
In a development version of the CRAN package metrumrg, I write ...
require(reshape)
setGeneric('cast')
setOldClass(c('keyed','data.frame'))
setMethod('cast','keyed', function ...)
The result is satisfactory when sourcing the code directly, but when
checking the package (which has 'reshape' as a dependency in the
DESCRIPTION file) I get the following:
"Error in setGeneric("cast") : must supply a function skeleton for
???cast???, explicitly or via an existing function."
You haven't mentioned your DESCRIPTION or NAMEPSACE file, but the right thing to
do is
DESCRIPTION:
Depends: reshape
NAMESPACE:
importFrom(reshape, cast)
R/somefile.R:
setGeneric("cast")
Perhaps your current setGeneric is being performed inside the namespace when
cast is not yet available (e.g., because it has not been imported)?
Martin Morgan
The help for setGeneric() seems to suggest that no function skeleton is
needed when creating a generic for a function defined in some other
package. I found one or two previous related posts, but no obvious
resolution.
Comments appreciated,
Tim Bergsma, PhD
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setGeneric() gives "must supply skeleton" when checking package
On 02/03/2013 09:36 AM, Martin Morgan wrote:
On 02/02/2013 02:34 PM, Tim Bergsma wrote:
r-devel,
In a development version of the CRAN package metrumrg, I write ...
require(reshape)
setGeneric('cast')
setOldClass(c('keyed','data.frame'))
setMethod('cast','keyed', function ...)
The result is satisfactory when sourcing the code directly, but when
checking the package (which has 'reshape' as a dependency in the
DESCRIPTION file) I get the following:
"Error in setGeneric("cast") : must supply a function skeleton for
???cast???, explicitly or via an existing function."
You haven't mentioned your DESCRIPTION or NAMEPSACE file, but the right thing to
do is
DESCRIPTION:
Depends: reshape
Should be Imports: reshape
NAMESPACE:
importFrom(reshape, cast)
R/somefile.R:
setGeneric("cast")
Perhaps your current setGeneric is being performed inside the namespace when
cast is not yet available (e.g., because it has not been imported)?
Martin Morgan
The help for setGeneric() seems to suggest that no function skeleton is
needed when creating a generic for a function defined in some other
package. I found one or two previous related posts, but no obvious
resolution.
Comments appreciated,
Tim Bergsma, PhD
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] best practice for packages using mclapply to avoid tcltk
As Peter pointed out earlier, this is better addressed by disabling the Tcl/Tk
event loop in forked processes.
Cheers,
Simon
On Feb 2, 2013, at 5:02 PM, Paul Johnson wrote:
> Dear R-devel friends:
>
> I'm back to bother you again about the conflict between mclapply and
> tcltk. I've been
> monitoring several packages that want to use mclapply to parallelize
> computations and
> need to figure out what should be done.
>
> It appears tcltk cannot be safely unloaded, so the best we can do is
> check for the presence of tcltk and stop if it is found before
> mclapply() is used.
>
> I wish you would please review my suggestion below. Maybe checkForTcltk()
> could be used in the parallel package. Otherwise, we are letting
> people run with scissors.
>
> There's a warning about this in ?mclapply
>
> It is _strongly discouraged_ to use these functions in GUI or
>embedded environments, because it leads to several processes
>sharing the same GUI which will likely cause chaos (and possibly
>crashes). Child processes should never use on-screen graphics
>devices.(Warning in ?mclapply)
>
> Bug report: (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15040 )
>
> By the way, what is "embedded environments" in ?mclapply
>
> ## I don't want to crash your system, but if you want to see a freeze-up:
> ## change 0 to 1 and run this:
> if (0){
> library(parallel)
> library(tcltk)
> example(mclapply)
> }
>
> ## What are packagers supposed to do if they want to call mclapply?
> ## It appears to me the best a package can do is scan for tcltk and
> ## stop. Here's a function that does so.
>
> checkForTcltk <- function(){
>if ("tcltk" %in% loadedNamespaces()){
>stop("This function cannot be used because the R tcltk
>package is loaded. It is necessary to Close R, and re-run
>the program making sure that tcltk is never loaded before
>this function is called.")
>}
> }
>
> ## put that to use.
> MCLApply <- function(){
>if (!require(parallel)) stop ("parallel wouldn't load")
>checkForTcltk()
>example(mclapply)
> }
>
> ## test that:
>
> checkForTcltk()
> MCLApply()
>
> library(tcltk)
> checkForTcltk()
>
>
> ## Why can't tcltk just be unloaded? I don't understand, but it is a deep
> ## problem.
>
> ## Consider the ominous warnings in R detach's help:
> ##
> ## "Unloading some namespaces has undesirable side effects: e.g.
> ## unloading ‘grid’ closes all graphics devices, and on most systems
> ## ‘tcltk’ cannot be reloaded once it has been unloaded and may crash
> ## R if this is attempted." (Note: section of ?detach).
> ##
> ## To be fair, that does not say unloading tcltk is fatal, but
> ## reloading it is fatal. And I've seen plenty of times when
> ## unloading it is fatal.
>
> ## Example 1. Crash on library.dynam.unload()
> detach("package:tcltk", unload = TRUE)
> library.dynam.unload("tcltk", system.file(package = "tcltk"))
>
> ## Output
> ## > library.dynam.unload("tcltk", system.file(package = "tcltk"))
> ## >
> ## *** caught segfault ***
> ## address 0x7f69c9d99580, cause 'memory not mapped'
>
> ## Possible actions:
> ## 1: abort (with core dump, if enabled)
> ## 2: normal R exit
> ## 3: exit R without saving workspace
> ## 4: exit R saving workspace
> ## Selection:
> ## Process R segmentation fault at Sat Feb 2 13:55:08 2013
>
>
> ## Example 2.
> library(tcltk)
> detach("package:tcltk", unload = TRUE)
> library.dynam.unload("tcltk", system.file(package = "tcltk"))
> example(mclapply)
>
> ## Output:
>
> ## > example(mclapply)
>
> ## *** caught segfault ***
> ## address 0x7f25ccbfe000, cause 'memory not mapped'
>
> ## Possible actions:
> ## 1: abort (with core dump, if enabled)
> ## 2: normal R exit
> ## 3: exit R without saving workspace
> ## 4: exit R saving workspace
> ## Selection:
>
>
> pj
>
> --
> Paul E. Johnson
> Professor, Political Science Assoc. Director
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org http://quant.ku.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] best practice for packages using mclapply to avoid tcltk
Hi Simon,
Sorry to be a bother, but is "disabling the Tcl/Tk event loop in the forked
processes" something that a package maintainer should do? If so, how?
Again, apologies if I've missed something obvious.
I maintain a package (Amelia) that has an optional tcltk GUI that folks can
use and we are in the process of integrating the parallel package into the
main algorithm. The package only loads tcltk if the user explicitly calls
the GUI. There's no (obvious) way for a user to run the main amelia()
function in parallel from the tcltk GUI, but the above bug can be triggered
by opening the GUI (which loads tcltk), closing it, then attempting to run
"amelia()" with multiple cores. To stop this, I've prevented anyone who has
"tcltk" loaded from running amelia() with multiple cores.
Obviously, I would prefer the status of tcltk in the user's environment not
to matter, so if there is some way to disable tcltk in the forked
processes, that would be great.
Cheers,
matt.
~~~
Matthew Blackwell
Assistant Professor of Political Science
University of Rochester
url: http://www.mattblackwell.org
On Sun, Feb 3, 2013 at 2:34 PM, Simon Urbanek
wrote:
> As Peter pointed out earlier, this is better addressed by disabling the
> Tcl/Tk event loop in forked processes.
>
> Cheers,
> Simon
>
> On Feb 2, 2013, at 5:02 PM, Paul Johnson wrote:
>
> > Dear R-devel friends:
> >
> > I'm back to bother you again about the conflict between mclapply and
> > tcltk. I've been
> > monitoring several packages that want to use mclapply to parallelize
> > computations and
> > need to figure out what should be done.
> >
> > It appears tcltk cannot be safely unloaded, so the best we can do is
> > check for the presence of tcltk and stop if it is found before
> > mclapply() is used.
> >
> > I wish you would please review my suggestion below. Maybe
> checkForTcltk()
> > could be used in the parallel package. Otherwise, we are letting
> > people run with scissors.
> >
> > There's a warning about this in ?mclapply
> >
> > It is _strongly discouraged_ to use these functions in GUI or
> >embedded environments, because it leads to several processes
> >sharing the same GUI which will likely cause chaos (and possibly
> >crashes). Child processes should never use on-screen graphics
> >devices.(Warning in ?mclapply)
> >
> > Bug report: (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15040)
> >
> > By the way, what is "embedded environments" in ?mclapply
> >
> > ## I don't want to crash your system, but if you want to see a freeze-up:
> > ## change 0 to 1 and run this:
> > if (0){
> > library(parallel)
> > library(tcltk)
> > example(mclapply)
> > }
> >
> > ## What are packagers supposed to do if they want to call mclapply?
> > ## It appears to me the best a package can do is scan for tcltk and
> > ## stop. Here's a function that does so.
> >
> > checkForTcltk <- function(){
> >if ("tcltk" %in% loadedNamespaces()){
> >stop("This function cannot be used because the R tcltk
> >package is loaded. It is necessary to Close R, and re-run
> >the program making sure that tcltk is never loaded before
> >this function is called.")
> >}
> > }
> >
> > ## put that to use.
> > MCLApply <- function(){
> >if (!require(parallel)) stop ("parallel wouldn't load")
> >checkForTcltk()
> >example(mclapply)
> > }
> >
> > ## test that:
> >
> > checkForTcltk()
> > MCLApply()
> >
> > library(tcltk)
> > checkForTcltk()
> >
> >
> > ## Why can't tcltk just be unloaded? I don't understand, but it is a deep
> > ## problem.
> >
> > ## Consider the ominous warnings in R detach's help:
> > ##
> > ## "Unloading some namespaces has undesirable side effects: e.g.
> > ## unloading grid closes all graphics devices, and on most systems
> > ## tcltk cannot be reloaded once it has been unloaded and may crash
> > ## R if this is attempted." (Note: section of ?detach).
> > ##
> > ## To be fair, that does not say unloading tcltk is fatal, but
> > ## reloading it is fatal. And I've seen plenty of times when
> > ## unloading it is fatal.
> >
> > ## Example 1. Crash on library.dynam.unload()
> > detach("package:tcltk", unload = TRUE)
> > library.dynam.unload("tcltk", system.file(package = "tcltk"))
> >
> > ## Output
> > ## > library.dynam.unload("tcltk", system.file(package = "tcltk"))
> > ## >
> > ## *** caught segfault ***
> > ## address 0x7f69c9d99580, cause 'memory not mapped'
> >
> > ## Possible actions:
> > ## 1: abort (with core dump, if enabled)
> > ## 2: normal R exit
> > ## 3: exit R without saving workspace
> > ## 4: exit R saving workspace
> > ## Selection:
> > ## Process R segmentation fault at Sat Feb 2 13:55:08 2013
> >
> >
> > ## Example 2.
> > library(tcltk)
> > detach("package:tcltk", unload = TRUE)
> > library.dynam.unload("tcltk", system.file(package = "tcltk"))
> > example(mclapply)
> >
> > ## Output:
> >
> > ## > example(mclapply)
> >
> > ## *** caught segfault ***
> > ## address 0x7f25ccbfe000, cause
Re: [Rd] Suggestions for 'diff.default'
Inspired by discussion in "Need very fast application of 'diff' - ideas?"
(around https://stat.ethz.ch/pipermail/r-help/2012-January/301873.html), I have
another suggestion.
Suggestion 3: Make 'diff.default' run faster.
For vector case (if suggestion 2 is not applied or if unclassed input is
treated specially), without resorting to C, I found that a speedup may be
gained by changing
r[-length(r):-(length(r)-lag+1L)]
with
`length<-`(r, length(r)-lag)
Another way, with similar idea, that triggers warning, is doing as follows.
{
for (i in seq_len(differences)) r <- r[i1] - r
length(r) <- xlen - lag * differences
}
Variables 'i1' and 'xlen' are as defined in function 'diff.default' in R.
--- On Tue, 29/1/13, Suharto Anggono Suharto Anggono
wrote:
> From: Suharto Anggono Suharto Anggono
> Subject: Re: Suggestions for 'diff.default'
> To: r-de...@lists.r-project.org
> Date: Tuesday, 29 January, 2013, 10:32 AM
>
>
> --- On Mon, 28/1/13, Suharto Anggono Suharto Anggono
>
> wrote:
>
> > From: Suharto Anggono Suharto Anggono
> > Subject: Suggestions for 'diff.default'
> > To: r-de...@lists.r-project.org
> > Date: Monday, 28 January, 2013, 5:31 PM
> > I have suggestions for function
> > 'diff.default' in R.
> >
> >
> > Suggestion 1: If the input is matrix, always return
> matrix,
> > even if empty.
> >
> > What happens in R 2.15.2:
> >
> > > rbind(1:2) # matrix
> > [,1] [,2]
> > [1,] 1 2
> > > diff(rbind(1:2)) # not matrix
> > integer(0)
> > > sessionInfo()
> > R version 2.15.2 (2012-10-26)
> > Platform: i386-w64-mingw32/i386 (32-bit)
> >
> > locale:
> > [1] LC_COLLATE=English_United States.1252
> > [2] LC_CTYPE=English_United States.1252
> > [3] LC_MONETARY=English_United States.1252
> > [4] LC_NUMERIC=C
> > [5] LC_TIME=English_United States.1252
> >
> > attached base packages:
> > [1] stats graphics grDevices
> > utils datasets
> > methods base
> >
> >
> > The documentation for 'diff' says, "If 'x' is a matrix
> then
> > the difference operations are carried out on each
> column
> > separately."
> > If the result is empty, I expect that the result still
> has
> > as many columns as the input.
> >
> >
> > Suggestion 2: Make 'diff.default' applicable more
> generally
> > by
> > (a) not performing 'unclass';
> > (b) generalizing (changing)
> > ismat <- is.matrix(x)
> > to become
> > ismat <- length(dim(x)) == 2L
> >
> >
> > If suggestion 1 is to be applied, if 'unclass' is not
> wanted
> > (point (a) in suggestion 2 is also to be applied),
> >
> > if (lag * differences >= xlen)
> > return(x[0L])
> >
> > can be changed to
> >
> > if (lag * differences >= xlen)
> > return(
> > if (ismat) x[0L, ,
> > drop = FALSE] - x[0L, , drop = FALSE] else
> > x[0L] - x[0L])
> >
> > It will handle class where subtraction (minus)
> operation
> > change class.
> Sorry, I wasn't careful enough. To obtain the correct class
> for the result, differencing should be done as many times as
> specified by argument 'differences'.
>
> I consider the case of
> diff(as.POSIXct(c("2012-01-01", "2012-02-01"), tz="UTC"),
> d=2)
> versus
> diff(diff(as.POSIXct(c("2012-01-01", "2012-02-01"),
> tz="UTC")))
> To be safe, maybe just compute as usual, even when it is
> known that the end result will be empty. It can be done like
> this.
>
> empty <- integer()
> if (ismat)
> for (i in seq_len(differences))
> r <- if (lag >=
> nrow(r))
>
> r[empty, , drop = FALSE] - r[empty, , drop = FALSE] else
> ...
> else
> for (i in seq_len(differences))
> r <- if (lag
> >= length(r))
>
> r[empty] - r[empty] else
> ...
>
> If that way is used, 'xlen' is no longer needed.
> >
> > Otherwise, if 'unclass' is wanted, maybe the handling
> of
> > empty result can be moved to be after 'unclass', to be
> > consistent with non-empty result.
> >
> >
> > If point (a) in suggestion 2 is applied, 'diff.default'
> can
> > handle input of class "Date" and "POSIXt". If, in
> addition,
> > point (b) in suggestion 2 is also applied,
> 'diff.default'
> > can handle data frame as input.
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
