Re: [Rd] R 3.2.2 64 bit compilation error on AIX
> Vinh Nguyen > on Thu, 8 Oct 2015 20:21:32 -0700 writes: > Ahh, sorry for not googling the error message. Found > [this](http://r.789695.n4.nabble.com/Error-compiling-R-2-10-1-on-AIX-td1017862.html) > post that suggests modifying /src/extra/tre/tre-internal.h > (https://r-forge.r-project.org/scm/viewvc.php/patches/aix_R210_tre.patch?view=markup&root=aix) > for AIX 64 bit. > Is it possible to add this information to the AIX section > of the R-admin manual? Thanks. Actually, I think we (R Core) should just apply that patch to the R/src/extras/tre/ sources. But this does not seem to be related to your original problem where compilation stopped during tools package building, or does it ? Martin Maechler, ETH Zurich > -- Vinh > On Thu, Oct 8, 2015 at 7:22 PM, Vinh Nguyen > wrote: >> One other note: I'm also using the latest src/main/dcf.c >> that was giving an issue on AIX previously; see >> [this](https://stat.ethz.ch/pipermail/r-devel/2015-September/071781.html) >> thread. >> >> Thanks. >> >> On Thu, Oct 8, 2015 at 6:51 PM, Vinh Nguyen >> wrote: >>> Please note that if I don't specify those variables, >>> then R 32 bit compiles fine. Thanks. >>> >>> -- Vinh > __ > 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] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe
On Fri, Oct 9, 2015 at 1:44 AM, Prof Brian Ripley wrote: > Hmm, look in MkRules.dist for the setting you failed to make Obviously > available in R-patched and R-devel only as we cannot foretell such changes. > >[snip] Yes, I see my error. For efficiency, I had copied in an old pre-filled Mkrules.local; penny wise and pound foolish. > Note what the posting guide says about not abusing the word 'crash'. My apologies for the word "crash." More accurate would have been "properly halted." Thank you very much, Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe
Hmm, look in MkRules.dist for the setting you failed to make Obviously available in R-patched and R-devel only as we cannot foretell such changes. On 09/10/2015 06:24, Avraham Adler wrote: According to the MikTex bug reports [1], MikTex 2.9 has removed texi2dvi.exe last week (on 2015-09-29) as "it was not compatible (anymore) with the original shell script texi2dvi (GNU Texinfo)." I found this out the hard way as I just (unknowingly) updated MikTex this evening, and then, while building R-devel_2015-10-08 on Windows7 64bit using the Rtools 3.3 toolchain (4.9.3 branch), had it crash Note what the posting guide says about not abusing the word 'crash'. during `make manuals` with: Output written on fullrefman.pdf (3468 pages, 9511515 bytes). Transcript written on fullrefman.log. creating doc/manual/version.texi texi2dvi --pdf --texinfo="@set UseExternalXrefs " R-FAQ.texi texi2dvi: not found make[1]: *** [R-FAQ.pdf] Error 127 make: *** [manuals] Error 2 Outside of trying to dig up an old (and now obsolete) version of the executable, what can be, or should be, done to build the manuals, or have we lost that ability? Thank you, Avi [1] http://sourceforge.net/p/miktex/bugs/2400/ -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe
According to the MikTex bug reports [1], MikTex 2.9 has removed texi2dvi.exe last week (on 2015-09-29) as "it was not compatible (anymore) with the original shell script texi2dvi (GNU Texinfo)." I found this out the hard way as I just (unknowingly) updated MikTex this evening, and then, while building R-devel_2015-10-08 on Windows7 64bit using the Rtools 3.3 toolchain (4.9.3 branch), had it crash during `make manuals` with: Output written on fullrefman.pdf (3468 pages, 9511515 bytes). Transcript written on fullrefman.log. creating doc/manual/version.texi texi2dvi --pdf --texinfo="@set UseExternalXrefs " R-FAQ.texi texi2dvi: not found make[1]: *** [R-FAQ.pdf] Error 127 make: *** [manuals] Error 2 Outside of trying to dig up an old (and now obsolete) version of the executable, what can be, or should be, done to build the manuals, or have we lost that ability? Thank you, Avi [1] http://sourceforge.net/p/miktex/bugs/2400/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.2.2 64 bit compilation error on AIX
Ahh, sorry for not googling the error message. Found [this](http://r.789695.n4.nabble.com/Error-compiling-R-2-10-1-on-AIX-td1017862.html) post that suggests modifying /src/extra/tre/tre-internal.h (https://r-forge.r-project.org/scm/viewvc.php/patches/aix_R210_tre.patch?view=markup&root=aix) for AIX 64 bit. Is it possible to add this information to the AIX section of the R-admin manual? Thanks. -- Vinh On Thu, Oct 8, 2015 at 7:22 PM, Vinh Nguyen wrote: > One other note: I'm also using the latest src/main/dcf.c that was > giving an issue on AIX previously; see > [this](https://stat.ethz.ch/pipermail/r-devel/2015-September/071781.html) > thread. > > Thanks. > > On Thu, Oct 8, 2015 at 6:51 PM, Vinh Nguyen wrote: >> Please note that if I don't specify those variables, then R 32 bit >> compiles fine. Thanks. >> >> -- Vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.2.2 64 bit compilation error on AIX
One other note: I'm also using the latest src/main/dcf.c that was giving an issue on AIX previously; see [this](https://stat.ethz.ch/pipermail/r-devel/2015-September/071781.html) thread. Thanks. On Thu, Oct 8, 2015 at 6:51 PM, Vinh Nguyen wrote: > Please note that if I don't specify those variables, then R 32 bit > compiles fine. Thanks. > > -- Vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.2.2 64 bit compilation error on AIX
Please note that if I don't specify those variables, then R 32 bit compiles fine. Thanks. -- Vinh On Thu, Oct 8, 2015 at 6:50 PM, Vinh Nguyen wrote: > Dear list, > > I'm following the instructions provided here to compile R 64 bit on > AIX 6.1. I did > > export OBJECT_MODE=64 > export CC="gcc -maix64 -pthread" > export CXX="g++ -maix64 -pthread" > export FC="gfortran -maix64 -pthread" > export F77="gfortran -maix64 -pthread" > export CFLAGS="-O2 -g -mcpu=power6" > export FFLAGS="-O2 -g -mcpu=power6" > export FCFLAGS="-O2 -g -mcpu=power6" > ./configure > make -j 16 > > and it errors out at > > gcc -maix64 -pthread -std=gnu99 -I../../../../include -DNDEBUG > -I../../../include -I../../../../src/include -DHAVE_CONFIG_H > -I../../../../src/main -I/usr/local/include -mminimal-toc-O2 -g > -mcpu=power6 -c gramRd.c -o gramRd.o > > gcc -maix64 -pthread -std=gnu99 -shared -Wl,-brtl -Wl,-G -Wl,-bexpall > -Wl,-bnoentry -lc -L/usr/local/lib -o tools.so text.o init.o Rmd5.o > md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -lm > -lintl > > make[6]: Entering directory '/sas/data04/vinh/R-3.2.2/src/library/tools/src' > > mkdir -p -- ../../../../library/tools/libs > > make[6]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools/src' > > make[5]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools/src' > > make[4]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools' > > make[4]: Entering directory '/sas/data04/vinh/R-3.2.2/src/library/tools' > > installing 'sysdata.rda' > > Error: Line starting 'Package: tools ...' is malformed! > > Execution halted > > ../../../share/make/basepkg.mk:150: recipe for target 'sysdata' failed > > make[4]: *** [sysdata] Error 1 > > make[4]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools' > > Makefile:30: recipe for target 'all' failed > > make[3]: *** [all] Error 2 > > make[3]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools' > > Makefile:36: recipe for target 'R' failed > > make[2]: *** [R] Error 1 > > make[2]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library' > > Makefile:28: recipe for target 'R' failed > > make[1]: *** [R] Error 1 > > make[1]: Leaving directory '/sas/data04/vinh/R-3.2.2/src' > > Makefile:59: recipe for target 'R' failed > > make: *** [R] Error 1 > > > > I tried going all the way back to R 2.15.3 and I still get this error. > Any suggestions for fixing this? Thanks. > > -- Vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.2.2 64 bit compilation error on AIX
Dear list, I'm following the instructions provided here to compile R 64 bit on AIX 6.1. I did export OBJECT_MODE=64 export CC="gcc -maix64 -pthread" export CXX="g++ -maix64 -pthread" export FC="gfortran -maix64 -pthread" export F77="gfortran -maix64 -pthread" export CFLAGS="-O2 -g -mcpu=power6" export FFLAGS="-O2 -g -mcpu=power6" export FCFLAGS="-O2 -g -mcpu=power6" ./configure make -j 16 and it errors out at gcc -maix64 -pthread -std=gnu99 -I../../../../include -DNDEBUG -I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I../../../../src/main -I/usr/local/include -mminimal-toc-O2 -g -mcpu=power6 -c gramRd.c -o gramRd.o gcc -maix64 -pthread -std=gnu99 -shared -Wl,-brtl -Wl,-G -Wl,-bexpall -Wl,-bnoentry -lc -L/usr/local/lib -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -lm -lintl make[6]: Entering directory '/sas/data04/vinh/R-3.2.2/src/library/tools/src' mkdir -p -- ../../../../library/tools/libs make[6]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools/src' make[5]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools/src' make[4]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools' make[4]: Entering directory '/sas/data04/vinh/R-3.2.2/src/library/tools' installing 'sysdata.rda' Error: Line starting 'Package: tools ...' is malformed! Execution halted ../../../share/make/basepkg.mk:150: recipe for target 'sysdata' failed make[4]: *** [sysdata] Error 1 make[4]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools' Makefile:30: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library/tools' Makefile:36: recipe for target 'R' failed make[2]: *** [R] Error 1 make[2]: Leaving directory '/sas/data04/vinh/R-3.2.2/src/library' Makefile:28: recipe for target 'R' failed make[1]: *** [R] Error 1 make[1]: Leaving directory '/sas/data04/vinh/R-3.2.2/src' Makefile:59: recipe for target 'R' failed make: *** [R] Error 1 I tried going all the way back to R 2.15.3 and I still get this error. Any suggestions for fixing this? Thanks. -- Vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-core package cross compilation help
On Thu, 2015-10-08 at 13:58 -0700, Sasikumar Kandhasamy wrote: > I am a beginner to R language and currently exploring R to use it for > machine learning use case. My requirement is to include R-core package in > my embedded linux box which runs on customized Monta Vista Linux with > kernel 2.6.32 and it has multi-core MIPS processor. > > I hope, there is NO pre-compiled R package for Monta vista linux and mips > processor. So, i am trying to do cross compilation with monta vista mips > compiler toolchain. > > Can you please help me with reference manuals(if any) on setting up the R > package for cross compilation? and also, given that we need only > statistical analytic model algorithms and we may not use graphical > interface, what is the recommendation on packages to be compiled? See the R Installation and Administration manual here: https://cran.r-project.org/doc/manuals/r-devel/R-admin.html Especially https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Simple-compilation and then, to consider machine learning applications in addition to R core, you probably want to look at the task view to consider packages: https://cran.r-project.org/web/views/MachineLearning.html questions on the packages in the task view should probably be directed to the package maintainers or e.g. r-help or one of the r-sig-* lists, as appropriate. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-core package cross compilation help
Hi, I am a beginner to R language and currently exploring R to use it for machine learning use case. My requirement is to include R-core package in my embedded linux box which runs on customized Monta Vista Linux with kernel 2.6.32 and it has multi-core MIPS processor. I hope, there is NO pre-compiled R package for Monta vista linux and mips processor. So, i am trying to do cross compilation with monta vista mips compiler toolchain. Can you please help me with reference manuals(if any) on setting up the R package for cross compilation? and also, given that we need only statistical analytic model algorithms and we may not use graphical interface, what is the recommendation on packages to be compiled? Thanks & Regards Sasi [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rank(, ties.method="last")
Hi,
I ran into a problem where I actually need rank(, ties.method="last"). It would
be great to have this feature in base and it's also simple to get (see below).
Thanks & cheers,
Marius
rank2 <- function (x, na.last = TRUE, ties.method = c("average",
"first", "last", # new "last"
"random", "max", "min"))
{
nas <- is.na(x)
nm <- names(x)
ties.method <- match.arg(ties.method)
if (is.factor(x))
x <- as.integer(x)
x <- x[!nas]
y <- switch(ties.method, average = , min = , max = .Internal(rank(x,
length(x), ties.method)), first = sort.list(sort.list(x)),
last = sort.list(sort.list(x, decreasing=TRUE),
decreasing=TRUE), # change
random = sort.list(order(x, stats::runif(sum(!nas)
if (!is.na(na.last) && any(nas)) {
yy <- NA
NAkeep <- (na.last == "keep")
if (NAkeep || na.last) {
yy[!nas] <- y
if (!NAkeep)
yy[nas] <- (length(y) + 1L):length(yy)
}
else {
len <- sum(nas)
yy[!nas] <- y + len
yy[nas] <- seq_len(len)
}
y <- yy
names(y) <- nm
}
else names(y) <- nm[!nas]
y
}
## MWE
x <- c(10, 11, 11, 12, 12, 13)
rank(x, ties.method="first")
rank2(x, ties.method="last")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] names treatment in optim()
Dear list,
A possible patch to correct the treatment of names consists in adding the
following lines
if(!is.null(names(par))) names(res$par) <- names(par)
if(!is.null(names(fn1(par names(res$value) <- names(fn1(par))
just before returning the variable res in optim. That is
optim <-
function(par, fn, gr = NULL, ...,
method = c("Nelder-Mead", "BFGS", "CG", "L-BFGS-B", "SANN",
"Brent"),
lower = -Inf, upper = Inf,
control = list(), hessian = FALSE)
{
…
if (hessian)
res$hessian <- .External2(C_optimhess, res$par, fn1, gr1, con)
if(!is.null(names(par))) names(res$par) <- names(par)
if(!is.null(names(fn1(par names(res$value) <- names(fn1(par))
res
}
Regards, Christophe
---
Christophe Dutang
LMM, UdM, Le Mans, France
web: http://dutangc.free.fr
> Le 17 sept. 2015 à 13:04, Christophe Dutang a écrit :
>
> Dear both,
>
> I have found that names are not treated in the same way in optim() depending
> on the optimization method (argument method).
>
> The example below shows the difference between the Brent method and the
> L-BFGS-B method.
>
> f <- function(x){ y <- x^2;names(y) <-"f(x)";y}
> optim(10, f, method="Brent", lower=-1, upper=10)$value
> optim(10, f, method="L-BFGS-B", lower=-1, upper=10)$value
>
> z <- 10
> names(z) <- "x"
> z
> optim(z, f, method="Brent", lower=-1, upper=10)$par
> optim(z, f, method="L-BFGS-B", lower=-1, upper=10)$par
>
>
> Do you obtain the same behavior? would you consider interesting to have the
> names passed to the components value and par?
>
> I’m using R version 3.2.2 (2015-08-14)
> Platform: x86_64-apple-darwin13.4.0 (64-bit)
> Running under: OS X 10.10.5 (Yosemite)
>
> locale:
> [1] fr_FR.UTF-8/fr_FR.UTF-8/fr_FR.UTF-8/C/fr_FR.UTF-8/fr_FR.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
>
>
> Kind regards, Christophe
>
> ---
> Christophe Dutang
> LMM, UdM, Le Mans, France
> web: http://dutangc.free.fr
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library() in .Rd Examples (Depends vs. Imports)?
On 08/10/2015 1:51 PM, Jonathan Greenberg wrote: I'm a little confused when documenting my code using Imports vs. Depends. If I have an example in my .Rd that uses a library that is listed under Imports, it doesn't work, but if it is listed under Depends, it does. What is the proper way to go about using examples that rely on an Imports? Should I just if(require(somepackage)) in the example? Or is there a more elegant way of doing this? The more elegant way is to use somepackage::somefunction(...). You should avoid using require(somepackage), because that modifies the user's search list; they may not want you to do that. Within your own package code you won't need the somepackage:: prefix if you import the function in your NAMESPACE file, but help page examples are executed in the user's context, so they can't see imports. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] library() in .Rd Examples (Depends vs. Imports)?
I'm a little confused when documenting my code using Imports vs. Depends. If I have an example in my .Rd that uses a library that is listed under Imports, it doesn't work, but if it is listed under Depends, it does. What is the proper way to go about using examples that rely on an Imports? Should I just if(require(somepackage)) in the example? Or is there a more elegant way of doing this? --j [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] authorship and citation
S Ellison posted: (quoting someone else, it appears) I read the CRAN policies twice, and there is no official guideline on how to compile the citation. And once again Dr Ellison is not attributing quotes: that is clearly covered by the posting guide. Including: Take care when you quote other people’s comments ... The original authorship and meaning should always be clear. The policies are about copyright and IP, not credited authorship. Hmm, people keep saying things like that, but it is not correct. The right to be identified as an author is an IP right: in some jurisdictions it is called a 'moral right' (and there are others). -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] authorship and citation
> > I read the CRAN policies twice, and there > > is no official guideline on how to compile the citation. The policies are about copyright and IP, not credited authorship. There's overlap but they are not the same thing. You can see whether someone is a copyright holder by referring to the license you had and whether there is any of their content remaining. But that might not mean they are package 'authors'. If you reuse code verbatim from another package's function, you _must_ note the copyright - but that does not necessarily make the original author of the code a co-author of your package (though I would expect to see at least an acknowledgement in the particular function's help page). And not all 'authors' need necessarily provide code - they could, for example, have developed the core maths the code implements. Of itself, that does not confer copyright in any part of the package code or help text, but it's very likely they'd deserve credit as co-authors. Common sense would suggest to me that if you are in doubt about whether someone should be on your author list (as opposed to copyright owner list) in a package's citation, you should probably ask them. And if you are considering removing an author, you should very definitely be in doubt because there was a reason they were there. The answers you get from different contributors might be different so it would not be surprising if packages differed in the extent to which they cited contributions or added acknowledgements. In essence, though, if everybody feels fairly treated by the citations within a package, there's no reason for anyone else to complain about it, and if someone feels they have not been properly credited they can - and should - contact the maintainer and say so. So ask before removing someone from your citation. If they say 'no', don’t remove them. S Ellison *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected failure when calling new() with unnamed arg and
Hi Martin,
Thanks and apologies for not seeing that. I had checked NEWS but not tried
it in R devel.
Thanks again.
Josh
On Thu, Oct 8, 2015 at 10:03 PM, Martin Maechler wrote:
> > Joshua Wiley
> > on Thu, 8 Oct 2015 12:19:16 +1100 writes:
>
> > Hi, I realize this is an old thread, but just wondering
> > whether a conclusion was ever reached on this issue? I'm
> > using formula(NULL) but it would be nice if default
> > initialization worked for formula classes as well.
>
> Well,
> yes "of course", it was fixed quite a while ago ..
> as I had ("almost") promissed (below).
>
> Fixed only for R-devel though, e.g., because it potentially
> requires package re-installation, etc.
>
> Martin
>
> > Cheers,
> > Josh
>
>
> > On Thu, May 14, 2015 at 8:13 AM, Hervé Pagès
> > wrote:
>
> >> Thanks Martin for looking into this. H.
> >>
> >>
> >> On 05/13/2015 03:57 AM, Martin Maechler wrote:
> >>
> >>> Hervé Pagès
> on Tue, 12 May 2015 15:18:42 -0700 writes:
>
> >>>
> >>> Hi,
>
> >>>
> >>> The man page for new() suggests that if 'a' is an object
> >>> with slots
> "slot1" and "slot2" and C is a class that extends the
> class of 'a', then the 2 following calls should be
> equivalent:
>
> >>>
> >>> new("C", a, ...)
> new("C", slot1=a@slot1, slot2=a@slot2, ...)
>
> >>>
> >>> This is generally the case but I just ran into a
> >>> situation where it's
> not. In the following example the former fails while
> the latter works:
>
> >>>
> >>> setClass("A", representation(slot1="numeric",
> >>> slot2="logical"))
> setClass("B", contains="A",
> representation(design="formula")) setClass("C",
> contains="B") a <- new("A", slot1=77, slot2=TRUE)
>
> >>>
> >>> new("C", a, design=x ~ y) # fails
> new("C", slot1=a@slot1, slot2=a@slot2, design=x ~ y) #
> works
>
> >>>
> >>> Note that new("B", a, design=x ~ y) works so the 3-level
> >>> class
> hierarchy is really needed in order to reproduce.
>
> >>>
> >>> Probably related to this, I also noted that new("B")
> >>> and/or new("C")
> return invalid objects:
>
> >>>
> >>> c <- new("C")
>
> >>>
> >>> validObject(c)
> # Error in validObject(c) : # invalid class “C” object:
> invalid object for slot "design" # in class "C": got
> class "S4", should be or extend class "formula"
>
> >>>
> >>> is(c@design, "formula")
> # [1] FALSE
>
> >>>
> >>> class(c@design)
> # [1] "S4"
>
> >>>
> >>> Note that 'c' can be fixed:
>
> >>>
> >>> c@design <- formula(NULL)
>
> >>>
> >>> validObject(c)
> # [1] TRUE
>
> >>>
> >>> Maybe something that the default "initialize" method
> >>> should take care
> of?
>
> >>>
> >>> Another singularity that is maybe at the root of all of
> >>> this is that
> the "formula" S4 class is virtual:
>
> >>>
> >>> showClass("formula")
> # Virtual Class "formula" [package "methods"]
> #
> # Slots:
> #
> # Name: .S3Class # Class: character
> #
> # Extends: "oldClass"
>
> >>>
> >>> so a bare call to new("formula") fails:
>
> >>>
> >>> new("formula")
> # Error in new("formula") : # trying to generate an
> object from a virtual class ("formula")
>
> >>>
> >>> Shouldn't new("formula") just return an "empty" S3
> >>> formula (like
> formula(NULL) does), in the same way that
> new("integer") returns an empty ordinary integer
> vector?
>
> >>>
> >>> Interesting .. and at least worth following.
> >>>
> >>> One problem and historical reason for the current setup
> >>> seems that the "formula" S3 class is not from 'base' but
> >>> 'stats' :
> >>>
> >>> R's source, src/library/methods/R/BasicClasses.R, lines
> >>> 524 ff has the following comment block
> >>>
> >>> | .OldClassesPrototypes is a list of S3 classes for
> >>> which prototype | objects are known & reasonable. The
> >>> classes will reappear in | .OldClassesList, but will
> >>> have been initialized first in | .InitBasicClasses. NB:
> >>> the methods package will NOT set up | prototypes for S3
> >>> classes except those in package base and for "ts" | (and
> >>> would rather not do those either). The package that
> >>> owns the | S3 class should have code to call setOldClass
> >>> in its | initialization.
> >>>
> >>> So, when John Chambers wrote this, he envisioned that
>
Re: [Rd] Unexpected failure when calling new() with unnamed arg and
> Joshua Wiley
> on Thu, 8 Oct 2015 12:19:16 +1100 writes:
> Hi, I realize this is an old thread, but just wondering
> whether a conclusion was ever reached on this issue? I'm
> using formula(NULL) but it would be nice if default
> initialization worked for formula classes as well.
Well,
yes "of course", it was fixed quite a while ago ..
as I had ("almost") promissed (below).
Fixed only for R-devel though, e.g., because it potentially
requires package re-installation, etc.
Martin
> Cheers,
> Josh
> On Thu, May 14, 2015 at 8:13 AM, Hervé Pagès
> wrote:
>> Thanks Martin for looking into this. H.
>>
>>
>> On 05/13/2015 03:57 AM, Martin Maechler wrote:
>>
>>> Hervé Pagès
on Tue, 12 May 2015 15:18:42 -0700 writes:
>>>
>>> Hi,
>>>
>>> The man page for new() suggests that if 'a' is an object
>>> with slots
"slot1" and "slot2" and C is a class that extends the
class of 'a', then the 2 following calls should be
equivalent:
>>>
>>> new("C", a, ...)
new("C", slot1=a@slot1, slot2=a@slot2, ...)
>>>
>>> This is generally the case but I just ran into a
>>> situation where it's
not. In the following example the former fails while
the latter works:
>>>
>>> setClass("A", representation(slot1="numeric",
>>> slot2="logical"))
setClass("B", contains="A",
representation(design="formula")) setClass("C",
contains="B") a <- new("A", slot1=77, slot2=TRUE)
>>>
>>> new("C", a, design=x ~ y) # fails
new("C", slot1=a@slot1, slot2=a@slot2, design=x ~ y) #
works
>>>
>>> Note that new("B", a, design=x ~ y) works so the 3-level
>>> class
hierarchy is really needed in order to reproduce.
>>>
>>> Probably related to this, I also noted that new("B")
>>> and/or new("C")
return invalid objects:
>>>
>>> c <- new("C")
>>>
>>> validObject(c)
# Error in validObject(c) : # invalid class “C” object:
invalid object for slot "design" # in class "C": got
class "S4", should be or extend class "formula"
>>>
>>> is(c@design, "formula")
# [1] FALSE
>>>
>>> class(c@design)
# [1] "S4"
>>>
>>> Note that 'c' can be fixed:
>>>
>>> c@design <- formula(NULL)
>>>
>>> validObject(c)
# [1] TRUE
>>>
>>> Maybe something that the default "initialize" method
>>> should take care
of?
>>>
>>> Another singularity that is maybe at the root of all of
>>> this is that
the "formula" S4 class is virtual:
>>>
>>> showClass("formula")
# Virtual Class "formula" [package "methods"]
#
# Slots:
#
# Name: .S3Class # Class: character
#
# Extends: "oldClass"
>>>
>>> so a bare call to new("formula") fails:
>>>
>>> new("formula")
# Error in new("formula") : # trying to generate an
object from a virtual class ("formula")
>>>
>>> Shouldn't new("formula") just return an "empty" S3
>>> formula (like
formula(NULL) does), in the same way that
new("integer") returns an empty ordinary integer
vector?
>>>
>>> Interesting .. and at least worth following.
>>>
>>> One problem and historical reason for the current setup
>>> seems that the "formula" S3 class is not from 'base' but
>>> 'stats' :
>>>
>>> R's source, src/library/methods/R/BasicClasses.R, lines
>>> 524 ff has the following comment block
>>>
>>> | .OldClassesPrototypes is a list of S3 classes for
>>> which prototype | objects are known & reasonable. The
>>> classes will reappear in | .OldClassesList, but will
>>> have been initialized first in | .InitBasicClasses. NB:
>>> the methods package will NOT set up | prototypes for S3
>>> classes except those in package base and for "ts" | (and
>>> would rather not do those either). The package that
>>> owns the | S3 class should have code to call setOldClass
>>> in its | initialization.
>>>
>>> So, when John Chambers wrote this, he envisioned that
>>> the 'stats' package would do "the correct thing" for its
>>> own classes. OTOH, as history went, the stats package
>>> was never allowed to depend on methods. There are many
>>> other S3 classes from 'stats' which also end up
>>> similarly, being defined via setOldClass() and that
>>> itself produces a VIRTUAL class. Also, another part of
>>> the (R source) comment above is no longer quite
>>> accura
