Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Christian, Herve --
In the end, I think you're being caught by partial matching in
function arguments:
> f <- function(x1) cat("x1:", x1, "\n")
> f(x="hello")
x1: hello
In the functional call x gets matched to x1. In your initialization
method for SubSubClassB2, nameB gets matched to nameB2 and so not
passed as ... in the callNextMethod.
The apparently extra calls to initialize with the wrong arguments come
about because of the validity methods -- validity gets checked by
coercing derived objects to their superclass, which involves a call to
'new' (hence initialize) followed by copying appropriate slots.
The funny effect where class(object) seems to trigger construction of
a new object is lazy evaluation -- the 'object' argument to
setValidity is not evaluated until needed, i.e., until class(object)
(anything would trigger this, including force(object)); only then do
you see the attempt to create the new object of the previous
paragraph.
Without partial matching issues, the use of callNextMethod as here:
setMethod("initialize", "SubSubClassB2",
function(.Object, nameB2="MyNameB2", ...) {
if (nameB2 == "") nameB2 <- "DefaultNameB2";
callNextMethod(.Object, nameB2=nameB2, ...)
}
)
is fine (though weird to have a prototype, a named argument, and a
conditional assignment!).
With
setMethod("initialize", "SubSubClassB2",
function(.Object, ...) {
.Object <- callNextMethod()
if ([EMAIL PROTECTED] == "") [EMAIL PROTECTED] <- "DefaultNameB2"
.Object
}
)
as suggested by Herve, the "SubClassB" initializer matches the nameB
argument to 'new' to the nameB argument of the initialize method for
SubClassB.
Simplifying the code to illustrate the problem was very helpful. It
would have been better to not present the validity methods (this might
have been a different thread), to remove the cat statements, to remove
unnecessary slots and classes (SubSubClassB1) and to name classes,
slots, and argument values in an easier to remember way (e.g., classes
A, B, C, slots a, b, c)
Hope that helps.
Martin
cstrato <[EMAIL PROTECTED]> writes:
> Dear Herve
>
> Thank you once again for taking your time, I appreciate it very much.
> I followed your advice and kept only the minimum code, which I believe
> is necessary. I have even removed SubClassA, so the inheritance tree is:
>
>BaseClass <- SubClassB <- SubSubClassB1
> <- SubClassB <- SubSubClassB2
>
> The source code is shown below and the examples are:
> > subsubB1 <- new("SubSubClassB1", filename="MyFileNameB1",
> nameB="MyNameB")
> > subsubB2 <- new("SubSubClassB2", filename="MyFileNameB2",
> nameB="MyNameB")
>
> Although SubSubClassB1 and SubSubClassB2 differ only slightly, the results
> for "subsubB1" are correct, while "subsubB2" gives a wrong result, see:
> > subsubB2 <- new("SubSubClassB2", filename="MyFileNameB2",
> nameB="MyNameB")
> > subsubB2
> An object of class "SubSubClassB2"
> Slot "nameB2":
> [1] "MyNameB"
>
> Slot "nameB":
> [1] ""
>
> Slot "filename":
> [1] "MyFileNameB2"
>
> Only, when adding "nameB2="MyNameB2", I get the correct result, see:
> > subsubB2 <- new("SubSubClassB2", filename="MyFileNameB2",
> nameB="MyNameB",nameB2="MyNameB2")
> > subsubB2
> An object of class "SubSubClassB2"
> Slot "nameB2":
> [1] "MyNameB2"
>
> Slot "nameB":
> [1] "MyNameB"
>
> Slot "filename":
> [1] "MyFileNameB2"
>
> It is not clear to me why omitting "nameB2" results in the wrong assignemt
> of the value for "nameB" to "nameB2"?
>
> When running both examples, the sequence of initialization and validation
> method is also completely different.
> For "SubSubClassB1" I get the correct and expected sequence of events:
> > subsubB1 <- new("SubSubClassB1", filename="MyFileNameB1",
> nameB="MyNameB")
> --initialize:SubSubClassB1
> --initialize:SubClassB
> --initialize:BaseClass
> --setValidity:BaseClass
> --setValidity:SubClassB
> --setValidity:SubSubClassB1
>
> In contrast, for "SubSubClassB2" I get the following sequence of events:
> > subsubB2 <- new("SubSubClassB2", filename="MyFileNameB2",
> nameB="MyNameB")
> --initialize:SubSubClassB2
> --initialize:SubClassB
> --initialize:BaseClass
> --setValidity:BaseClass
> --initialize:SubClassB
> --initialize:BaseClass
> --setValidity:BaseClass
> --setValidity:SubClassB
> --setValidity:SubClassB
> --initialize:SubClassB
> --initialize:BaseClass
> --setValidity:BaseClass
> --setValidity:SubClassB
> --setValidity:SubSubClassB2
>
> Furthermore, the slot "filename" is first initialized correctly to
> "filename=MyFileNameB2", but then it is twice initialized incorrectly
> to "filename=ERROR_FileName", indicating that it may not have been
> initialized at all. I do not understand this behavior, why is this so?
>
> I really hope that this time the code below is acceptable to you.
> Thank you for your help.
> Best regards
> Christian
>
> # - - - - - - - - - - - - - - - -
[Rd] R-Forge?
Hello! I have recently found RForge.net (http://www.rforge.net/) by Simon Urbanek and found out today that the site is accepting subscriptions. Great! However, browsing a bit on the site I found a link to another forge: R-Forge (http://r-forge.r-project.org/). Is/will the last one be the "offcial" forge for R packages, given that it has domain r-project.org? Regards, Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] getConnection is not found in R depending on the Linux flavour (RedHat or Debian) - dyn.load problems
Hello R developers,
I am working on the "seqinr" package and I encounter a tricky problem
using a C
function.
We defined a C fonction called "getzlibsock" which is dedicated to
compressed
socket connections. This function is using the R internal C function
called "getConnection(int)" in order to get information about the socket
previously opened with the dedicated R functions.
The program works fine on several platform:
-Unix (SunOS),
-MacOS and
-Linux (some).
However, on Linux, an error occurs depending on the installation.
I tried to play with the Makevars file by specifing lots of path and
library
without succees
On Red Hat Linux it works fine, but on Debian the dynamic library can
not be
loaded:
Library is working fine with Linux Red Hat:
-
R.2.4.0
Linux ccali24 2.4.21-32.0.1.ELsmp #1 SMP Wed May 25 15:42:26 CDT 2005
i686 i686 i386 GNU/Linux
RedHat
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with:
../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
Compiling the dynamic library:
Makevars:
PKG_CFLAGS = -ansi -DUSE_TYPE_CHECKING_STRICT
R CMD SHLIB -o test.so *.c
gcc -I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/usr/local/include -ansi -DUSE_TYPE_CHECKING_STRICT -fpic -g -O2
-std=gnu99 -c alignment.c -o alignment.o
gcc -I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/usr/local/include -ansi -DUSE_TYPE_CHECKING_STRICT -fpic -g -O2
-std=gnu99 -c getzlibsock.c -o getzlibsock.o
gcc -I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/usr/local/include -ansi -DUSE_TYPE_CHECKING_STRICT -fpic -g -O2
-std=gnu99 -c kaks.c -o kaks.o
gcc -I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/usr/local/include -ansi -DUSE_TYPE_CHECKING_STRICT -fpic -g -O2
-std=gnu99 -c util.c -o util.o
gcc -I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/afs/in2p3.fr/home/throng/biometr/R_dir/install//lib/R/include
-I/usr/local/include -ansi -DUSE_TYPE_CHECKING_STRICT -fpic -g -O2
-std=gnu99 -c zsockr.c -o zsockr.o
gcc -shared -L/usr/local/lib -o test.so alignment.o getzlibsock.o kaks.o
util.o zsockr.o
Note that the dll libR.so is not asked not the path to the dll
Loading the dynamic library:
R version 2.4.0 (2006-10-03)
Copyright (C) 2006 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> dyn.load("test.so")
>
Problem in library with Linux Debian
--
( both binary distribution of R and version builded from sources):
a) with the binary version
R version 2.4.1 (2006-12-18)
This the binary distribution obtained via apt-get
Linux pcstef 2.6.15-1-686-smp #2 SMP Mon Mar 6 15:34:50 UTC 2006 i686
GNU/Linux
Debian
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Configured with:
../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
Compiling the dynamic library:
Makevars:
PKG_CFLAGS = -ansi -DUSE_TYPE_CHECKING_STRICT
PKG_LIBS = -lR -lz
rm *o
R CMD SHLIB -o test.so *.c
gcc -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include -ansi
-DUSE_TYPE_CHECKING_STRICT -fpic -g -O2 -c alignment.c -o alignment.o
gcc -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include -ansi
-DUSE_TYPE_CHECKING_STRICT -fpic -g -O2 -c getzlibsock.c -o getzlibsock.o
gcc -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include -ansi
-DUSE_TYPE_CHECKING_STRICT -fpic -g -O2 -c kaks.c -o kaks.o
gcc -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include -ansi
-DUSE_TYPE_CHECKING_STRICT -fpic -g -O2 -c util.c -o util.o
gcc -std=gnu99 -I/usr/share/R/i
Re: [Rd] R-Forge?
On Fri, 6 Apr 2007, Gregor Gorjanc wrote: > Hello! > > I have recently found RForge.net (http://www.rforge.net/) by Simon > Urbanek and found out today that the site is accepting subscriptions. > Great! However, browsing a bit on the site I found a link to another > forge: R-Forge (http://r-forge.r-project.org/). > > Is/will the last one be the "offcial" forge for R packages, given that > it has domain r-project.org? Yes, we're currently still testing the functionality and improving the documentation, but an article for R News that announces the functionality is under preparation. There is already a user's manual available on the main page which explains how you can register and set up your project etc. Just as Simon's site this already offers an SVN and nightly builds in a CRAN-style repository, and additionally there is the whole GForge system with other features such as project forums, mailing lists etc. Best, Z > Regards, Gregor > > __ > 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] R-Forge?
> > I have recently found RForge.net (http://www.rforge.net/) by Simon > > Urbanek and found out today that the site is accepting subscriptions. > > Great! However, browsing a bit on the site I found a link to another > > forge: R-Forge (http://r-forge.r-project.org/). > > > > Is/will the last one be the "offcial" forge for R packages, given that > > it has domain r-project.org? > > Yes, we're currently still testing the functionality and improving the > documentation, but an article for R News that announces the functionality > is under preparation. There is already a user's manual available on the > main page which explains how you can register and set up your project etc. > Just as Simon's site this already offers an SVN and nightly builds in a > CRAN-style repository, and additionally there is the whole GForge system > with other features such as project forums, mailing lists etc. Is it possible to use r-forge just for the nightly builds? (ie. with svn hosted elsewhere) That would be really handy. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge?
On 4/6/07, Stefan Theussl <[EMAIL PROTECTED]> wrote:
> hadley wickham wrote:
> >> > I have recently found RForge.net (http://www.rforge.net/) by Simon
> >> > Urbanek and found out today that the site is accepting subscriptions.
> >> > Great! However, browsing a bit on the site I found a link to another
> >> > forge: R-Forge (http://r-forge.r-project.org/).
> >> >
> >> > Is/will the last one be the "offcial" forge for R packages, given that
> >> > it has domain r-project.org?
> >>
> >> Yes, we're currently still testing the functionality and improving the
> >> documentation, but an article for R News that announces the
> >> functionality
> >> is under preparation. There is already a user's manual available on the
> >> main page which explains how you can register and set up your project
> >> etc.
> >> Just as Simon's site this already offers an SVN and nightly builds in a
> >> CRAN-style repository, and additionally there is the whole GForge system
> >> with other features such as project forums, mailing lists etc.
> >
> > Is it possible to use r-forge just for the nightly builds? (ie. with
> > svn hosted elsewhere) That would be really handy.
> >
> > Hadley
> We have never thought about it, but this would be technically difficult.
>
> But you may migrate your svn (or the part which contains the package) to
> R-Forge and have the advantage of daily build and checked packages with
> the possibility to install it directly from R-Forge:
> |install.packages("/packagename/",repos="http://r-forge.r-project.org";)|
I guess I'm not really comfortable moving my code to an external
repository completely out of my control. It would be really
convenient to be able to upload a source package, and have it built,
with out R CMD check being enforced.
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear Herve, dear Martin,
First I want to thank Herve very much for your continuous efforts. You can
not imagine, how relieved I was that you mangaged to reproduce this
behavior.
Just when I wanted to send my reply to Herve, I received Martin's comments:
As you mention, there were two problems in my example:
1. partial matching:
Thank you for your explanation, now I hope that I understand the behavior.
However, as Herve correctly mentioned, this is only a side issue.
2. lazy evaluation and validity methods:
This is the real problem, that I try to solve since three weeks, and I am
afraid, that I still do not know how to solve it.
Following Herve's example, I have managed to reduce my own example so that
it is only slightly larger than his example, however, now I had to expand
it again to make my point, see the final code below.
(For the moment I stick with my naming of the classes)
The result I get is the following:
> subsubB2 <- new("SubSubClassB2", filename="MyFileNameB2",
nameB="MyNameB")
--initialize:SubSubClassB2--
--initialize:SubClassB--
--initialize:BaseClass--
BaseClass:init:filename = MyFileNameB2
--setValidity:BaseClass--
--initialize:SubClassB--
--initialize:BaseClass--
BaseClass:init:filename = ERROR_FileName
--setValidity:BaseClass--
--setValidity:SubClassB--
--setValidity:SubClassB--
--setValidity:SubSubClassB2--
SubSubClassB2:val:filename = MyFileNameB2
Although the final output gives the correct result "filename =
MyFileNameB2",
in the interim code, filename is set to "filename = ERROR_FileName".
In my real package the line "filename <- ERROR_FileName" is replaced by
a function. To take advantage of inheritance, I have defined "filename"
in BaseClass, and I want to check for its validity only once in BaseClass.
With the current information I have to re-evaluate my code in order to
avoid "lazy evaluation", since this might be the problem.
Thank you both for your extensive help.
Best regards
Christian
# - - - - - - - - - - - - - - - BEGIN - - - - - - - - - - - - - - - -
setClass("BaseClass",
representation(filename = "character", "VIRTUAL"),
prototype(filename = "DefaultFileName")
)
setClass("SubClassB",
representation(nameB = "character"),
contains=c("BaseClass"),
prototype(nameB = "NameB")
)
setClass("SubSubClassB2",
representation(nameB2 = "character"),
contains=c("SubClassB"),
prototype(nameB2 = "NameB2")
)
setMethod("initialize", "BaseClass",
function(.Object, filename="", ...) {
cat("--initialize:BaseClass--\n")
if (filename == "" || nchar(filename) == 0) filename <-
"ERROR_FileName"
cat("BaseClass:init:filename = ", filename, "\n", sep="")
.Object <- callNextMethod(.Object, filename=filename, ...)
[EMAIL PROTECTED] <- filename
.Object
}
)
setValidity("BaseClass",
function(object) {
cat("--setValidity:BaseClass--\n")
msg <- NULL
str <- [EMAIL PROTECTED]
if (!(is.character([EMAIL PROTECTED])))
msg <- cat("missing filename\n")
if (is.null(msg)) TRUE else msg
}
)
setMethod("initialize", "SubClassB",
function(.Object, nameB="", ...) {
cat("--initialize:SubClassB--\n")
.Object <- callNextMethod(.Object, nameB=nameB, ...)
}
)
setValidity("SubClassB",
function(object) {
cat("--setValidity:SubClassB--\n")
TRUE
}
)
setMethod("initialize", "SubSubClassB2",
function(.Object, ...) {
cat("--initialize:SubSubClassB2--\n")
.Object <- callNextMethod(.Object, ...)
}
)
setValidity("SubSubClassB2",
function(object) {
cat("--setValidity:SubSubClassB2--\n")
cat("SubSubClassB2:val:filename = ", [EMAIL PROTECTED], "\n", sep="")
TRUE
}
)
# - - - - - - - - - - - - - - - END - - - - - - - - - - - - - - - - -
Martin Morgan wrote:
> Christian, Herve --
>
> In the end, I think you're being caught by partial matching in
> function arguments:
>
>
>> f <- function(x1) cat("x1:", x1, "\n")
>> f(x="hello")
>>
> x1: hello
>
> In the functional call x gets matched to x1. In your initialization
> method for SubSubClassB2, nameB gets matched to nameB2 and so not
> passed as ... in the callNextMethod.
>
> The apparently extra calls to initialize with the wrong arguments come
> about because of the validity methods -- validity gets checked by
> coercing derived objects to their superclass, which involves a call to
> 'new' (hence initialize) followed by copying appropriate slots.
>
> The funny effect where class(object) seems to trigger construction of
> a new object is lazy evaluation -- the 'object' argument to
> setValidity is not evaluated until needed, i.e., until class(object)
> (anything would trigger this, including force(object)); only then do
> you see the attempt to create the new object of the previous
> paragraph.
>
> Without partial matching issues, the use of callNe
Re: [Rd] R-Forge?
On Apr 6, 2007, at 12:22 PM, hadley wickham wrote:
> On 4/6/07, Stefan Theussl <[EMAIL PROTECTED]> wrote:
>> hadley wickham wrote:
> I have recently found RForge.net (http://www.rforge.net/) by Simon
> Urbanek and found out today that the site is accepting
> subscriptions.
> Great! However, browsing a bit on the site I found a link to
> another
> forge: R-Forge (http://r-forge.r-project.org/).
>
> Is/will the last one be the "offcial" forge for R packages,
> given that
> it has domain r-project.org?
Yes, we're currently still testing the functionality and
improving the
documentation, but an article for R News that announces the
functionality
is under preparation. There is already a user's manual available
on the
main page which explains how you can register and set up your
project
etc.
Just as Simon's site this already offers an SVN and nightly
builds in a
CRAN-style repository, and additionally there is the whole
GForge system
with other features such as project forums, mailing lists etc.
>>>
>>> Is it possible to use r-forge just for the nightly builds? (ie.
>>> with
>>> svn hosted elsewhere) That would be really handy.
>>>
>>> Hadley
>> We have never thought about it, but this would be technically
>> difficult.
>>
>> But you may migrate your svn (or the part which contains the
>> package) to
>> R-Forge and have the advantage of daily build and checked packages
>> with
>> the possibility to install it directly from R-Forge:
>> |install.packages("/packagename/",repos="http://r-forge.r-
>> project.org")|
>
> I guess I'm not really comfortable moving my code to an external
> repository completely out of my control. It would be really
> convenient to be able to upload a source package, and have it built,
> with out R CMD check being enforced.
>
I see the whole point of using external repository (like either
rforge) in having fully-backed SVN repository on server-grade
hardware. If you already have a SVN repository, why won't you use a
post-commit script on the same machine to do the build and check?
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Martin,
Martin Morgan wrote:
> The funny effect where class(object) seems to trigger construction of
> a new object is lazy evaluation -- the 'object' argument to
> setValidity is not evaluated until needed, i.e., until class(object)
> (anything would trigger this, including force(object)); only then do
> you see the attempt to create the new object of the previous
> paragraph.
The fact that you can't predict the number of times the "initialize"
method will be called is problematic. Here is a simple example
where "initialize-A" increments a global counter to keep track of the
number of A-objects:
A.GLOBALS <- new.env(parent=emptyenv())
A.GLOBALS[["nobjs"]] <- 0L
setClass("A",
representation(a="character"),
prototype(a="a0")
)
setMethod("initialize", "A",
function(.Object, ...) {
cat("--initialize:A--\n")
A.GLOBALS[["nobjs"]] <- A.GLOBALS[["nobjs"]] + 1
cat("A-object #", A.GLOBALS[["nobjs"]], "\n", sep="")
callNextMethod()
}
)
setValidity("A",
function(object) {
cat("--setValidity:A--\n")
tmp <- class(object)
TRUE
}
)
setClass("B",
contains="A",
representation(b = "character")
)
setMethod("initialize", "B",
function(.Object, ...) {
cat("--initialize:B--\n")
callNextMethod()
}
)
setValidity("B",
function(object) {
cat("--setValidity:B--\n")
TRUE
}
)
Let's try it:
> b1 <- new("B")
--initialize:B--
--initialize:A--
A-object #1
> A.GLOBALS[["nobjs"]]
[1] 1
> b1 <- new("B", b="hello")
--initialize:B--
--initialize:A--
A-object #2
--setValidity:A--
--initialize:A--
A-object #3
--setValidity:B--
> A.GLOBALS[["nobjs"]]
[1] 3
Shouldn't the "initializing" ("constructor" in other languages) code be executed
exactly 1 time per object instanciation? Something that the programmer can
simply
rely on, whatever this code contains and whatever the internal subtilities of
the
programming lamguage are?
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge?
On 4/6/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 4/6/07, Stefan Theussl <[EMAIL PROTECTED]> wrote:
> > hadley wickham wrote:
> > >> > I have recently found RForge.net (http://www.rforge.net/) by Simon
> > >> > Urbanek and found out today that the site is accepting subscriptions.
> > >> > Great! However, browsing a bit on the site I found a link to another
> > >> > forge: R-Forge (http://r-forge.r-project.org/).
> > >> >
> > >> > Is/will the last one be the "offcial" forge for R packages, given that
> > >> > it has domain r-project.org?
> > >>
> > >> Yes, we're currently still testing the functionality and improving the
> > >> documentation, but an article for R News that announces the
> > >> functionality
> > >> is under preparation. There is already a user's manual available on the
> > >> main page which explains how you can register and set up your project
> > >> etc.
> > >> Just as Simon's site this already offers an SVN and nightly builds in a
> > >> CRAN-style repository, and additionally there is the whole GForge system
> > >> with other features such as project forums, mailing lists etc.
> > >
> > > Is it possible to use r-forge just for the nightly builds? (ie. with
> > > svn hosted elsewhere) That would be really handy.
> > >
> > > Hadley
> > We have never thought about it, but this would be technically difficult.
> >
> > But you may migrate your svn (or the part which contains the package) to
> > R-Forge and have the advantage of daily build and checked packages with
> > the possibility to install it directly from R-Forge:
> > |install.packages("/packagename/",repos="http://r-forge.r-project.org";)|
>
> I guess I'm not really comfortable moving my code to an external
> repository completely out of my control. It would be really
> convenient to be able to upload a source package, and have it built,
> with out R CMD check being enforced.
If you are comfortable with mirroring, I recently discovered the
svnsync tool (new in subversion 1.4). It will mirror a subversion
repository in its entirety (including commit history). It requires a
hook script to be present in the target repository (so needs
cooperation from the admin), but otherwise, once you set it up, a one
line cron job will synchronize it.
A quick description is available here:
http://code.google.com/support/bin/answer.py?answer=56682&topic=10386
and the subversion book has more detail.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge?
On 4/6/07, Simon Urbanek <[EMAIL PROTECTED]> wrote:
>
> On Apr 6, 2007, at 12:22 PM, hadley wickham wrote:
>
> > On 4/6/07, Stefan Theussl <[EMAIL PROTECTED]> wrote:
> >> hadley wickham wrote:
> > I have recently found RForge.net (http://www.rforge.net/) by Simon
> > Urbanek and found out today that the site is accepting
> > subscriptions.
> > Great! However, browsing a bit on the site I found a link to
> > another
> > forge: R-Forge (http://r-forge.r-project.org/).
> >
> > Is/will the last one be the "offcial" forge for R packages,
> > given that
> > it has domain r-project.org?
>
> Yes, we're currently still testing the functionality and
> improving the
> documentation, but an article for R News that announces the
> functionality
> is under preparation. There is already a user's manual available
> on the
> main page which explains how you can register and set up your
> project
> etc.
> Just as Simon's site this already offers an SVN and nightly
> builds in a
> CRAN-style repository, and additionally there is the whole
> GForge system
> with other features such as project forums, mailing lists etc.
> >>>
> >>> Is it possible to use r-forge just for the nightly builds? (ie.
> >>> with
> >>> svn hosted elsewhere) That would be really handy.
> >>>
> >>> Hadley
> >> We have never thought about it, but this would be technically
> >> difficult.
> >>
> >> But you may migrate your svn (or the part which contains the
> >> package) to
> >> R-Forge and have the advantage of daily build and checked packages
> >> with
> >> the possibility to install it directly from R-Forge:
> >> |install.packages("/packagename/",repos="http://r-forge.r-
> >> project.org")|
> >
> > I guess I'm not really comfortable moving my code to an external
> > repository completely out of my control. It would be really
> > convenient to be able to upload a source package, and have it built,
> > with out R CMD check being enforced.
> >
>
> I see the whole point of using external repository (like either
> rforge) in having fully-backed SVN repository on server-grade
> hardware. If you already have a SVN repository, why won't you use a
> post-commit script on the same machine to do the build and check?
The svn server is the easy bit - you can get that at any number of
hosts. Cross-platform R builds are much trickier, and is the unique
thing that the r-forge sites offer. If I could have some one else
deal with the package building for linux, mac and windows for test
packages I would be a very happy man.
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?
Dear Herve
Although I am currently learning to use S4 classes, and thus I am
probably not the person
to comment on S4 classes, I completely agree with you.
Coming from C++ (most of my code is C++), this is what I have
intuitively expected,
although I was not able to formulate it. I am glad that you did.
At the moment I try to find out if there is a possibility to circumvent
this problem.
I do not know if there is a possibility to set an object to NULL
initially, and then
call: "if (!is.null(object)) do something"
Best regards
Christian
Herve Pages wrote:
> Martin,
>
> Martin Morgan wrote:
>
>> The funny effect where class(object) seems to trigger construction of
>> a new object is lazy evaluation -- the 'object' argument to
>> setValidity is not evaluated until needed, i.e., until class(object)
>> (anything would trigger this, including force(object)); only then do
>> you see the attempt to create the new object of the previous
>> paragraph.
>>
>
> The fact that you can't predict the number of times the "initialize"
> method will be called is problematic. Here is a simple example
> where "initialize-A" increments a global counter to keep track of the
> number of A-objects:
>
> A.GLOBALS <- new.env(parent=emptyenv())
> A.GLOBALS[["nobjs"]] <- 0L
>
> setClass("A",
> representation(a="character"),
> prototype(a="a0")
> )
> setMethod("initialize", "A",
> function(.Object, ...) {
> cat("--initialize:A--\n")
> A.GLOBALS[["nobjs"]] <- A.GLOBALS[["nobjs"]] + 1
> cat("A-object #", A.GLOBALS[["nobjs"]], "\n", sep="")
> callNextMethod()
> }
> )
> setValidity("A",
> function(object) {
> cat("--setValidity:A--\n")
> tmp <- class(object)
> TRUE
> }
> )
>
> setClass("B",
> contains="A",
> representation(b = "character")
> )
> setMethod("initialize", "B",
> function(.Object, ...) {
> cat("--initialize:B--\n")
> callNextMethod()
> }
> )
> setValidity("B",
> function(object) {
> cat("--setValidity:B--\n")
> TRUE
> }
> )
>
> Let's try it:
>
> > b1 <- new("B")
> --initialize:B--
> --initialize:A--
> A-object #1
> > A.GLOBALS[["nobjs"]]
> [1] 1
>
> > b1 <- new("B", b="hello")
> --initialize:B--
> --initialize:A--
> A-object #2
> --setValidity:A--
> --initialize:A--
> A-object #3
> --setValidity:B--
> > A.GLOBALS[["nobjs"]]
> [1] 3
>
> Shouldn't the "initializing" ("constructor" in other languages) code be
> executed
> exactly 1 time per object instanciation? Something that the programmer can
> simply
> rely on, whatever this code contains and whatever the internal subtilities of
> the
> programming lamguage are?
>
> Cheers,
> H.
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge?
hadley wickham wrote:
> On 4/6/07, Simon Urbanek <[EMAIL PROTECTED]> wrote:
>> On Apr 6, 2007, at 12:22 PM, hadley wickham wrote:
>>
>>> On 4/6/07, Stefan Theussl <[EMAIL PROTECTED]> wrote:
hadley wickham wrote:
>>> I have recently found RForge.net (http://www.rforge.net/) by Simon
>>> Urbanek and found out today that the site is accepting
>>> subscriptions.
>>> Great! However, browsing a bit on the site I found a link to
>>> another
>>> forge: R-Forge (http://r-forge.r-project.org/).
>>>
>>> Is/will the last one be the "offcial" forge for R packages,
>>> given that
>>> it has domain r-project.org?
>> Yes, we're currently still testing the functionality and
>> improving the
>> documentation, but an article for R News that announces the
>> functionality
>> is under preparation. There is already a user's manual available
>> on the
>> main page which explains how you can register and set up your
>> project
>> etc.
>> Just as Simon's site this already offers an SVN and nightly
>> builds in a
>> CRAN-style repository, and additionally there is the whole
>> GForge system
>> with other features such as project forums, mailing lists etc.
> Is it possible to use r-forge just for the nightly builds? (ie.
> with
> svn hosted elsewhere) That would be really handy.
>
> Hadley
We have never thought about it, but this would be technically
difficult.
But you may migrate your svn (or the part which contains the
package) to
R-Forge and have the advantage of daily build and checked packages
with
the possibility to install it directly from R-Forge:
|install.packages("/packagename/",repos="http://r-forge.r-
project.org")|
>>> I guess I'm not really comfortable moving my code to an external
>>> repository completely out of my control. It would be really
>>> convenient to be able to upload a source package, and have it built,
>>> with out R CMD check being enforced.
>>>
>> I see the whole point of using external repository (like either
>> rforge) in having fully-backed SVN repository on server-grade
>> hardware. If you already have a SVN repository, why won't you use a
>> post-commit script on the same machine to do the build and check?
>
> The svn server is the easy bit - you can get that at any number of
> hosts. Cross-platform R builds are much trickier, and is the unique
> thing that the r-forge sites offer. If I could have some one else
> deal with the package building for linux, mac and windows for test
> packages I would be a very happy man.
At least for Windows it is there:
http://129.217.207.166
Uwe Ligges
> Hadley
>
> __
> 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
[Rd] corrections to R-exts
Hi,
a couple of minor fixes to R-exts.texi:
In
@subsection Setting R callbacks
which describes Rinterface.h,
The @example block correctly has
extern int (*ptr_R_ReadConsole)(char *, unsigned char *, int, int);
extern int (*ptr_R_ShowFiles)(int, char **, char **, char *,
Rboolean, char *);
Just below that, these are described incorrectly as:
deftypefun int R_ReadConsole (char [EMAIL PROTECTED], char [EMAIL PROTECTED], @
int @var{buflen}, int @var{hist})
(missing 'unsigned')
@deftypefun void R_ShowFiles (int @var{nfile}, char [EMAIL PROTECTED], [...]
(return type 'void' instead of 'int')
Also, the paragraph on R_ReadConsole ends with:
"The return value is 0 on success and >0 on failure."
This is wrong.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] wishlist: additional argument in R_tryEval (Rinternals.h)
Hi,
R_tryEval, exported in Rinternals.h but not part of the API, is
currently defined as:
R_tryEval(SEXP e, SEXP env, int *ErrorOccurred);
I'm trying to embed R in an application (basically yet another GUI),
and this has been very helpful to catch errors. It would be even more
helpful if it also gave access to the visibility flag. I can wrap this
in a call to withVisible, and that works great, but if there is an
error, traceback() contains a bunch of irrelevant levels.
It seems fairly easy to add another argument, similar to
ErrorOccurred, that is set to the visibility flag before returning. Is
this something that could be considered for addition in R-devel? A
possible patch for R/trunk is attached. Mac-GUI/REngine/REngine.m will
also need a patch, but I don't understand the language it's written
in.
-Deepayan
Index: src/include/Rinternals.h
===
--- src/include/Rinternals.h (revision 41080)
+++ src/include/Rinternals.h (working copy)
@@ -616,7 +616,7 @@
void R_ProtectWithIndex(SEXP, PROTECT_INDEX *);
void R_Reprotect(SEXP, PROTECT_INDEX);
-SEXP R_tryEval(SEXP, SEXP, int *);
+SEXP R_tryEval(SEXP, SEXP, int *, int *);
/* return(.) NOT reached : for -Wall */
#define error_return(msg) { Rf_error(msg); return R_NilValue; }
Index: src/library/methods/src/methods_list_dispatch.c
===
--- src/library/methods/src/methods_list_dispatch.c (revision 41080)
+++ src/library/methods/src/methods_list_dispatch.c (working copy)
@@ -299,7 +299,7 @@
val = CDR(val);
SETCAR(val, f_env);
}
-val = R_tryEval(e, Methods_Namespace, &check_err);
+val = R_tryEval(e, Methods_Namespace, &check_err, NULL);
if(check_err)
error(_("S language method selection got an error when called from internal dispatch for function '%s'"),
check_symbol_or_string(fname, TRUE,
@@ -540,7 +540,7 @@
else {
/* get its class */
SEXP arg, class_obj; int check_err;
- PROTECT(arg = R_tryEval(arg_sym, ev, &check_err)); nprotect++;
+ PROTECT(arg = R_tryEval(arg_sym, ev, &check_err, NULL)); nprotect++;
if(check_err)
error(_("error in evaluating the argument '%s' in selecting a method for function '%s'"),
CHAR(PRINTNAME(arg_sym)),CHAR(asChar(fname)));
@@ -551,7 +551,7 @@
else {
/* the arg contains the class as a string */
SEXP arg; int check_err;
- PROTECT(arg = R_tryEval(arg_sym, ev, &check_err)); nprotect++;
+ PROTECT(arg = R_tryEval(arg_sym, ev, &check_err, NULL)); nprotect++;
if(check_err)
error(_("error in evaluating the argument '%s' in selecting a method for function '%s'"),
CHAR(PRINTNAME(arg_sym)),CHAR(asChar(fname)));
@@ -636,7 +636,7 @@
args = CDR(args);
}
if(prim_case) {
- val = R_tryEval(e, ev, &error_flag);
+ val = R_tryEval(e, ev, &error_flag, NULL);
/* reset the methods: R_NilValue for the mlist argument
leaves the previous function, methods list unchanged */
do_set_prim_method(op, "set", R_NilValue, R_NilValue);
@@ -833,7 +833,7 @@
else {
/* get its class */
SEXP arg; int check_err;
- PROTECT(arg = R_tryEval(arg_sym, ev, &check_err));
+ PROTECT(arg = R_tryEval(arg_sym, ev, &check_err, NULL));
if(check_err)
error(_("error in evaluating the argument '%s' in selecting a method for function '%s'"),
CHAR(PRINTNAME(arg_sym)),CHAR(asChar(fname)));
Index: src/main/main.c
===
--- src/main/main.c (revision 41080)
+++ src/main/main.c (working copy)
@@ -1434,7 +1434,7 @@
SETCAR(cur, VECTOR_ELT(f, 1));
}
-val = R_tryEval(e, NULL, &errorOccurred);
+val = R_tryEval(e, NULL, &errorOccurred, NULL);
if(!errorOccurred) {
PROTECT(val);
if(TYPEOF(val) != LGLSXP) {
Index: src/main/context.c
===
--- src/main/context.c (revision 41080)
+++ src/main/context.c (working copy)
@@ -636,7 +636,7 @@
}
SEXP
-R_tryEval(SEXP e, SEXP env, int *ErrorOccurred)
+R_tryEval(SEXP e, SEXP env, int *ErrorOccurred, int *IsVisible)
{
Rboolean ok;
ProtectedEvalData data;
@@ -649,6 +649,9 @@
if (ErrorOccurred) {
*ErrorOccurred = (ok == FALSE);
}
+if (IsVisible) {
+*IsVisible = (int) R_Visible;
+}
if (ok == FALSE)
data.val = NULL;
else
Index: src/gnuwin32/front-ends/rproxy_impl.c
===
--- src/gnuwin32/front-ends/rproxy_impl.c (revision 41080)
+++ src/gnuwin32/front-ends/rproxy_impl.c (working copy)
@@ -305,7 +305,7 @@
switch (lStatus) {
case PARSE_OK:
PROTECT(lSexp);
- lResult = R_tryEval(VECTOR_ELT(lSexp, 0), R_GlobalEnv, &evalError);
+ lResult = R_tryEval(VECTOR_ELT(lSexp, 0), R_GlobalEnv, &evalError, NULL);
UNPROTECT(1);
if(evalError) lRc = SC_PROXY_ERR_EVALUATE_STOP;
else lRc = SEXP2BDX(lResult, pData
Re: [Rd] wishlist: additional argument in R_tryEval (Rinternals.h)
Hi Deepayan. It is not part of the API, but it is used in numerous packages that would break if such a change were made. It is an easy change to make, but not necessarily a robust approach if we keep adding parameters. If we need the room to add more, using a structure whose fields are modified within the R_tryEval() would be more flexible for future evolutions. But then again, that is creeping towards an object and that is precisely what we need for the evaluator itself.. (More perhaps in the future.) D. Deepayan Sarkar wrote: > Hi, > > R_tryEval, exported in Rinternals.h but not part of the API, is > currently defined as: > > R_tryEval(SEXP e, SEXP env, int *ErrorOccurred); > > I'm trying to embed R in an application (basically yet another GUI), > and this has been very helpful to catch errors. It would be even more > helpful if it also gave access to the visibility flag. I can wrap this > in a call to withVisible, and that works great, but if there is an > error, traceback() contains a bunch of irrelevant levels. > > It seems fairly easy to add another argument, similar to > ErrorOccurred, that is set to the visibility flag before returning. Is > this something that could be considered for addition in R-devel? A > possible patch for R/trunk is attached. Mac-GUI/REngine/REngine.m will > also need a patch, but I don't understand the language it's written > in. > > -Deepayan > > > > > __ > 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] wishlist: additional argument in R_tryEval (Rinternals.h)
Even though it isn't officially part of the API it has seen some use so I'd prefer not to change the interface; instead add SEXP R_tryEvalWithVis(SEXP e, SEXP env, int *ErrorOccurred, int *visible); or something along those lines and define R_tryEval internally in terms of that. It may be worth thinking a bit more though to see if there is something else that might be useful at this point. I vaguely recall thinking recently about needing something else of this flavor but I can't seem to remember what it was exactly -- will try to see if I can recall. Best, luke On Fri, 6 Apr 2007, Deepayan Sarkar wrote: > Hi, > > R_tryEval, exported in Rinternals.h but not part of the API, is > currently defined as: > > R_tryEval(SEXP e, SEXP env, int *ErrorOccurred); > > I'm trying to embed R in an application (basically yet another GUI), > and this has been very helpful to catch errors. It would be even more > helpful if it also gave access to the visibility flag. I can wrap this > in a call to withVisible, and that works great, but if there is an > error, traceback() contains a bunch of irrelevant levels. > > It seems fairly easy to add another argument, similar to > ErrorOccurred, that is set to the visibility flag before returning. Is > this something that could be considered for addition in R-devel? A > possible patch for R/trunk is attached. Mac-GUI/REngine/REngine.m will > also need a patch, but I don't understand the language it's written > in. > > -Deepayan > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wishlist: additional argument in R_tryEval (Rinternals.h)
It's come up for me when I do FFI stuff. For GUI stuff I usually just want to suppress, but it's possible that you'd want to detect visibility if you were to make the GUI more programmable. I usually end up having to work around the whole business by fiddling with R_Visible. Speaking of R_tryEval, can someone with the appropriate powers PRETTY PLEASE just make it an official API? Having it continue to be unofficial is just getting silly. On 4/6/07, Luke Tierney <[EMAIL PROTECTED]> wrote: > Even though it isn't officially part of the API it has seen some use > so I'd prefer not to change the interface; instead add > > SEXP R_tryEvalWithVis(SEXP e, SEXP env, int *ErrorOccurred, int *visible); > > or something along those lines and define R_tryEval internally in > terms of that. > > It may be worth thinking a bit more though to see if there is > something else that might be useful at this point. I vaguely recall > thinking recently about needing something else of this flavor but I > can't seem to remember what it was exactly -- will try to see if I can > recall. > > Best, > > luke > > > On Fri, 6 Apr 2007, Deepayan Sarkar wrote: > > > Hi, > > > > R_tryEval, exported in Rinternals.h but not part of the API, is > > currently defined as: > > > > R_tryEval(SEXP e, SEXP env, int *ErrorOccurred); > > > > I'm trying to embed R in an application (basically yet another GUI), > > and this has been very helpful to catch errors. It would be even more > > helpful if it also gave access to the visibility flag. I can wrap this > > in a call to withVisible, and that works great, but if there is an > > error, traceback() contains a bunch of irrelevant levels. > > > > It seems fairly easy to add another argument, similar to > > ErrorOccurred, that is set to the visibility flag before returning. Is > > this something that could be considered for addition in R-devel? A > > possible patch for R/trunk is attached. Mac-GUI/REngine/REngine.m will > > also need a patch, but I don't understand the language it's written > > in. > > > > -Deepayan > > > > -- > Luke Tierney > Chair, Statistics and Actuarial Science > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: [EMAIL PROTECTED] > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wishlist: additional argument in R_tryEval (Rinternals.h)
On 4/6/07, Byron Ellis <[EMAIL PROTECTED]> wrote: > It's come up for me when I do FFI stuff. For GUI stuff I usually just > want to suppress, but it's possible that you'd want to detect > visibility if you were to make the GUI more programmable. I usually > end up having to work around the whole business by fiddling with > R_Visible. My GUI is basically a wrapper around R (it's an exercise in teaching myself Qt), so replicating console functionality is a major goal. R is embedded and not the main thread, mostly because I didn't read R-exts carefully enough before starting. But most things have gone fairly smoothly, and I want to see how far I can go. > Speaking of R_tryEval, can someone with the appropriate powers PRETTY > PLEASE just make it an official API? Having it continue to be > unofficial is just getting silly. > > > On 4/6/07, Luke Tierney <[EMAIL PROTECTED]> wrote: > > Even though it isn't officially part of the API it has seen some use > > so I'd prefer not to change the interface; instead add > > > > SEXP R_tryEvalWithVis(SEXP e, SEXP env, int *ErrorOccurred, int *visible); > > > > or something along those lines and define R_tryEval internally in > > terms of that. > > > > It may be worth thinking a bit more though to see if there is > > something else that might be useful at this point. I vaguely recall > > thinking recently about needing something else of this flavor but I > > can't seem to remember what it was exactly -- will try to see if I can > > recall. OK, I'll stick with withVisible for now, and wait for something like R_tryEvalWithVis. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
