[Rd] Licensing concerns in porting S-Plus code to R libraries
I used S-Plus for many years, and developed lots of code for my research. When I switched to R a few years ago, I ported most of my S-Plus code over to R for my own use. Now that some of this code is quite polished, I would like to make it available as an R package on CRAN. Some of my S-Plus code, however, was based on Insightful S-Plus functions; for instance, I took a Trellis function, and modified to suit my needs. In some cases the modifications are minor (e.g., adding extra functionality, changing colors), while in other cases I've made substantial changes (e.g., a new function that just uses the techniques of the internal function). Furthermore, in porting the code to R, I of course had to make further changes (e.g., Trellis functions for lattice/grid functions, new C code to replace internal S-Plus routines to which I did not have the source code). I wondering if anyone can provide some guidance here as to what I can release without running afoul of any user agreement that may have come with S-Plus long ago. I'm assuming other package developers, especially those that were S-Plus users long ago, have encountered this issue and can advise me on what to do. Many thanks, Chris Green [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Licensing concerns in porting S-Plus code to R libraries
On 12-10-15 8:38 PM, Chris Green wrote: I used S-Plus for many years, and developed lots of code for my research. When I switched to R a few years ago, I ported most of my S-Plus code over to R for my own use. Now that some of this code is quite polished, I would like to make it available as an R package on CRAN. Some of my S-Plus code, however, was based on Insightful S-Plus functions; for instance, I took a Trellis function, and modified to suit my needs. In some cases the modifications are minor (e.g., adding extra functionality, changing colors), while in other cases I've made substantial changes (e.g., a new function that just uses the techniques of the internal function). Furthermore, in porting the code to R, I of course had to make further changes (e.g., Trellis functions for lattice/grid functions, new C code to replace internal S-Plus routines to which I did not have the source code). I wondering if anyone can provide some guidance here as to what I can release without running afoul of any user agreement that may have come with S-Plus long ago. I'm assuming other package developers, especially those that were S-Plus users long ago, have encountered this issue and can advise me on what to do. For the functions that just use the same techniques but are new code, you probably don't need to worry. But for the ones that include non-trivial amounts of S-PLUS code, you probably need permission from the copyright holder to release them. I would write to Tibco (the current owners of S-PLUS) and ask permission to release your functions under the GPL. Include copyright notices for them as well as for yourself. You should include copies of the functions that are based on their work, so they know how much you are asking for. You can also offer to release them under some other open license, if they'd prefer that. I have no idea how receptive they'll be to this offer, but I think it's worth a try. If they say no, then you should rewrite (or better still, get someone else to rewrite, based on your specs) those functions that use their code so they're all new. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] possible bug in print.bibentry
bsseq is a Bioconductor package. I think the main issue here is that
CITATION has a volume field, like
bibentry("Article",
title = "{BSmooth: from whole genome bisulfite sequencing
reads to differentially methylated regions}",
author = personList(
person(c("Kasper", "D."), "Hansen"),
person("Benjamin", "Langmead"),
person(c("Rafael", "A."), "Irizarry")),
journal = "Genome Biology",
year = 2012,
volume = "13",
pages = "R83",
textVersion =
paste("KD Hansen, B Langmead, and RA Irizarry.",
"BSmooth: from whole genome bisulfite sequencing reads
to differentially methylated regions.",
"Genome Biology, 13:R83 (2012)")
)
When I do
> print(citation("bsseq"), style = "latex")
Hansen KD, Langmead B and Irizarry RA (2012).
``BSmooth: from whole genome bisulfite sequencing reads to
differentially methylated regions.''
\emph{Genome Biology}, \bold{13}, pp. R83.
the output uses \bold, which is not recognized by my Latex
installation. I believe it should be using \textbf.
Kasper
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Do *not* pass '...' to NextMethod() - it'll do it for you; missing documentation, a bug or just me?
Hi,
although I've done S3 dispatching for more than a decade now, I think
I managed to overlook/avoid the following pitfall when using
NextMethod():
If you explicitly pass argument '...' to NextMethod(), you will
effectively pass those argument twice to the "next" method!
EXAMPLE:
foo0 <- function(...) UseMethod("foo0");
foo1 <- function(...) UseMethod("foo1");
foo2 <- function(...) UseMethod("foo2");
foo2.A <- foo1.A <- foo0.A <- function(object, a=1, b=2, c=3, d=4, ...) {
str(c(list(object=object, a=a, b=b, c=c, d=d), list(...)));
}
## CORRECT: Don't pass arguments '...', but all other
## *named* arguments that you wish to be changed in the call.
foo0.B <- function(object, ..., b=-2) {
NextMethod("foo0", object=object, b=b);
}
## INCORRECT: Passing arguments '...' explicitly will *duplicated* them.
foo1.B <- function(object, ..., b=-2) {
NextMethod("foo1", object=object, ..., b=b);
}
## INCORRECT: As an illustration, *triplication* of arguments '...'.
foo2.B <- function(object, ..., b=-2) {
NextMethod("foo2", object=object, ..., ..., b=b);
}
objB <- structure(NA, class=c("B", "A"));
foo0(objB, "???", "!!!");
## Gives:
## List of 5
## $ object:Classes 'B', 'A' logi NA
## $ a : chr "???"
## $ b : num -2
## $ c : chr "!!!"
## $ d : num 4
foo1(objB, "???", "!!!");
## Gives:
## List of 6
## $ object:Classes 'B', 'A' logi NA
## $ a : chr "???"
## $ b : num -2
## $ c : chr "!!!"
## $ d : chr "???"
## $ : chr "!!!"
foo2(objB, "???", "!!!");
## Gives:
## List of 8
## $ object:Classes 'B', 'A' logi NA
## $ a : chr "???"
## $ b : num -2
## $ c : chr "!!!"
## $ d : chr "???"
## $ : chr "!!!"
## $ : chr "???"
## $ : chr "!!!"
This behavior does not seem to be documented (at least not
explicitly), cf. help("NextMethod", package="base") and Section
'NextMethod' in 'R Language Definition'. I don't have the 'White
Book', so I don't know what that is saying about this.
I can reproduce this on Windows, OSX and Linux and various versions of
R, e.g. R v2.10.0, R v2.15.1 patched, R devel.
Is this a bug, should it be detected as a user error, should it be
documented, or is this already old news?
Thanks,
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Do *not* pass '...' to NextMethod() - it'll do it for you; missing documentation, a bug or just me?
On Oct 16, 2012, at 9:53 PM, Henrik Bengtsson wrote:
> Hi,
>
> although I've done S3 dispatching for more than a decade now, I think
> I managed to overlook/avoid the following pitfall when using
> NextMethod():
>
> If you explicitly pass argument '...' to NextMethod(), you will
> effectively pass those argument twice to the "next" method!
>
>
> EXAMPLE:
>
> foo0 <- function(...) UseMethod("foo0");
> foo1 <- function(...) UseMethod("foo1");
> foo2 <- function(...) UseMethod("foo2");
>
> foo2.A <- foo1.A <- foo0.A <- function(object, a=1, b=2, c=3, d=4, ...) {
> str(c(list(object=object, a=a, b=b, c=c, d=d), list(...)));
> }
>
> ## CORRECT: Don't pass arguments '...', but all other
> ## *named* arguments that you wish to be changed in the call.
> foo0.B <- function(object, ..., b=-2) {
> NextMethod("foo0", object=object, b=b);
> }
>
> ## INCORRECT: Passing arguments '...' explicitly will *duplicated* them.
> foo1.B <- function(object, ..., b=-2) {
> NextMethod("foo1", object=object, ..., b=b);
> }
>
> ## INCORRECT: As an illustration, *triplication* of arguments '...'.
> foo2.B <- function(object, ..., b=-2) {
> NextMethod("foo2", object=object, ..., ..., b=b);
> }
>
> objB <- structure(NA, class=c("B", "A"));
>
> foo0(objB, "???", "!!!");
> ## Gives:
> ## List of 5
> ## $ object:Classes 'B', 'A' logi NA
> ## $ a : chr "???"
> ## $ b : num -2
> ## $ c : chr "!!!"
> ## $ d : num 4
>
> foo1(objB, "???", "!!!");
> ## Gives:
> ## List of 6
> ## $ object:Classes 'B', 'A' logi NA
> ## $ a : chr "???"
> ## $ b : num -2
> ## $ c : chr "!!!"
> ## $ d : chr "???"
> ## $ : chr "!!!"
>
> foo2(objB, "???", "!!!");
> ## Gives:
> ## List of 8
> ## $ object:Classes 'B', 'A' logi NA
> ## $ a : chr "???"
> ## $ b : num -2
> ## $ c : chr "!!!"
> ## $ d : chr "???"
> ## $ : chr "!!!"
> ## $ : chr "???"
> ## $ : chr "!!!"
>
> This behavior does not seem to be documented (at least not
> explicitly),
I would argue it does:
"Normally ‘NextMethod’ is used with only one argument, ‘generic’, but if
further arguments are supplied these modify the call to the next method."
The whole point of NextMethod is that it starts off with the full call
*including* ... from the function - by calling NextMethod you are modifying
that call, so by adding unnamed arguments you will append them.
And the ... override is explicitly documented: "Any named arguments matched to
‘...’ are handled specially: they either replace existing arguments of the same
name or are appended to the argument list." Try foo1(objB, c="foo", "bla") in
your example - it illustrates the difference.
Also why would you pass ... when you don't do it for UseMethod?
Cheers,
Simon
> cf. help("NextMethod", package="base") and Section
> 'NextMethod' in 'R Language Definition'. I don't have the 'White
> Book', so I don't know what that is saying about this.
>
> I can reproduce this on Windows, OSX and Linux and various versions of
> R, e.g. R v2.10.0, R v2.15.1 patched, R devel.
>
> Is this a bug, should it be detected as a user error, should it be
> documented, or is this already old news?
>
> Thanks,
>
> Henrik
>
> __
> 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] Do *not* pass '...' to NextMethod() - it'll do it for you; missing documentation, a bug or just me?
Hi Simon,
thanks for the prompt reply. Comments below...
On Tue, Oct 16, 2012 at 7:35 PM, Simon Urbanek
wrote:
>
> On Oct 16, 2012, at 9:53 PM, Henrik Bengtsson wrote:
>
>> Hi,
>>
>> although I've done S3 dispatching for more than a decade now, I think
>> I managed to overlook/avoid the following pitfall when using
>> NextMethod():
>>
>> If you explicitly pass argument '...' to NextMethod(), you will
>> effectively pass those argument twice to the "next" method!
>>
>>
>> EXAMPLE:
>>
>> foo0 <- function(...) UseMethod("foo0");
>> foo1 <- function(...) UseMethod("foo1");
>> foo2 <- function(...) UseMethod("foo2");
>>
>> foo2.A <- foo1.A <- foo0.A <- function(object, a=1, b=2, c=3, d=4, ...) {
>> str(c(list(object=object, a=a, b=b, c=c, d=d), list(...)));
>> }
>>
>> ## CORRECT: Don't pass arguments '...', but all other
>> ## *named* arguments that you wish to be changed in the call.
>> foo0.B <- function(object, ..., b=-2) {
>> NextMethod("foo0", object=object, b=b);
>> }
>>
>> ## INCORRECT: Passing arguments '...' explicitly will *duplicated* them.
>> foo1.B <- function(object, ..., b=-2) {
>> NextMethod("foo1", object=object, ..., b=b);
>> }
>>
>> ## INCORRECT: As an illustration, *triplication* of arguments '...'.
>> foo2.B <- function(object, ..., b=-2) {
>> NextMethod("foo2", object=object, ..., ..., b=b);
>> }
>>
>> objB <- structure(NA, class=c("B", "A"));
>>
>> foo0(objB, "???", "!!!");
>> ## Gives:
>> ## List of 5
>> ## $ object:Classes 'B', 'A' logi NA
>> ## $ a : chr "???"
>> ## $ b : num -2
>> ## $ c : chr "!!!"
>> ## $ d : num 4
>>
>> foo1(objB, "???", "!!!");
>> ## Gives:
>> ## List of 6
>> ## $ object:Classes 'B', 'A' logi NA
>> ## $ a : chr "???"
>> ## $ b : num -2
>> ## $ c : chr "!!!"
>> ## $ d : chr "???"
>> ## $ : chr "!!!"
>>
>> foo2(objB, "???", "!!!");
>> ## Gives:
>> ## List of 8
>> ## $ object:Classes 'B', 'A' logi NA
>> ## $ a : chr "???"
>> ## $ b : num -2
>> ## $ c : chr "!!!"
>> ## $ d : chr "???"
>> ## $ : chr "!!!"
>> ## $ : chr "???"
>> ## $ : chr "!!!"
Just to give further practical motivation for the latter case:
foo1.C <- function(object, ..., c=-3) {
NextMethod("foo1", object=object, ..., c=c);
}
objC <- structure(NA, class=c("C", "B", "A"));
foo1(objC, "???", "!!!")
## List of 11
## $ object:Classes 'C', 'B', 'A' logi NA
## $ a : chr "???"
## $ b : num -2
## $ c : num -3
## $ d : chr "!!!"
## $ : chr "???"
## $ : chr "!!!"
## $ : chr "???"
## $ : chr "!!!"
## $ : chr "???"
## $ : chr "!!!"
>>
>> This behavior does not seem to be documented (at least not
>> explicitly),
>
> I would argue it does:
> "Normally ‘NextMethod’ is used with only one argument, ‘generic’, but if
> further arguments are supplied these modify the call to the next method."
> The whole point of NextMethod is that it starts off with the full call
> *including* ... from the function - by calling NextMethod you are modifying
> that call, so by adding unnamed arguments you will append them.
Maybe it's possible to make help("NextMethod") more explicit about
this? It's a bit tricky because there are two different '...'; one for
NextMethod() and one for the S3 function that calls NextMethod().
What about:
\item{...}{\emph{further} arguments to be passed to the next method.
Named arguments will override same-name arguments to the function
containing NextMethod, otherwise they will be appended. Non-named
arguments (including those passed as \code{...}) will be appended.}
instead of as now:
\item{...}{further arguments to be passed to the next method.},
and adding the following note to the Details section of help("NextMethod"):
NextMethod invokes the next method (determined by the class vector,
either of the object supplied to the generic, or of the first argument
to the function containing NextMethod if a method was invoked
directly). Normally NextMethod is used with only one argument,
generic, but if further arguments are supplied these _modify_ the call
to the next method. Note, if the function containing NextMethod has
an argument '...', it is likely a mistake to pass it explicitly to
NextMethod, because such will be \emph{appended} to the set of
arguments passed to this function (already containing '...') and
therefore result in duplicated entries.
>
> And the ... override is explicitly documented: "Any named arguments matched
> to ‘...’ are handled specially: they either replace existing arguments of the
> same name or are appended to the argument list." Try foo1(objB, c="foo",
> "bla") in your example - it illustrates the difference.
Yes, that part I understood, but thanks for the clarification.
>
> Also why would you pass ... when you don't do it for UseMethod?
Yes, I tried to make that analogue as well, but however I looked at
'...' and UseMethod()/NextMethod() I saw multiple interpretations.
Maybe less so now after
