[Rd] Daily snapshots of sources do not work?
For some days now there had been no more daily snapshots on ftp://ftp.stat.math.ethz.ch/Software/R/ . The latest sources are from 07/26/2012. I think this is not indented? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Daily snapshots of sources do not work?
On 05/08/2012 08:53, Rainer Hurling wrote: For some days now there had been no more daily snapshots on ftp://ftp.stat.math.ethz.ch/Software/R/ . The latest sources are from 07/26/2012. I think this is not indented? Whatever '07/26/2012' means! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Yes, we know. But: - only people at that site can deal with this - people do have vacations, and things do break in their absence At least we should thank Martin Maechler and colleagues that this does work well over 99% of the time. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interaction between callNextMethod() and selectMethod()
On Aug 5, 2012, at 04:16 , Simon Urbanek wrote: On Aug 4, 2012, at 9:49 PM, Hervé Pagès wrote: On 08/03/2012 11:44 PM, peter dalgaard wrote: On Aug 4, 2012, at 01:24 , Hervé Pagès wrote: BTW, it's funny that the VERSION file in the R source tree says: hpages@latitude:~/src/R-2.16.r59963$ cat VERSION 2.16.0 Under development (unstable) ^^ What's funny about that? We no longer display the number on startup and at some point we may not even use it for an actual release, but there needs to be a number to test R = 2.14.0-style dependencies and such. What's funny is that even if we try to pretend that the version number doesn't matter, it actually does matter. Not only for R = 2.14.0-style dependencies and such, but also for human communication: - Can't install that package! - Works for me. What version of R are you using? - Unsuffered Consequences - I'm using Roasted Marshmallows, you should upgrade to that one. - I'm confused I thought I was running the latest. - No Roasted Marshmallows is the latest. - Are you sure? How do you know? etc, etc... It reminds me of Mozilla plans to hide Firefox version: https://bugzilla.mozilla.org/show_bug.cgi?id=678775 AFAIK they finally abandoned it :-) I agree. Currently R-devel doesn't show the version number and that makes sense for two reasons: let's say today R-devel's internal version is 2.16.0 but such release doesn't exist yet so you can't call R-devel that in any case that may be referenced later (because then there will be 2.16.0 release at some point which is different from the R-devel that was referred to). Also we don't know for sure if the next release will be 2.16.0 or let's say 3.0.0. That said, I was surprised that Peter said for an actual release (I'm not sure he meant it in the way you interpreted it, though) - I think it's slightly annoying that R.version.string in R-devel doesn't contain the version number (because it makes it slightly more complicated to get the version number in scripts), but not having it or showing it for releases would certainly be fatal but I did not see any reason or discussion about such a move. Actual release meant exactly what you say: There's no 2.16.0 release yet, and (in principle) the next one might be 3.0.0. The number is there, though. For one thing, install.packages() would break without it. We just do not show it so that people will not mistake it for a release code. (Simon: You don't want to parse R.version.string, the information is already in the other fields of R.version.) R-devel is not a release (and neither is R-patched, for that matter), There is no way in which it is reasonable to call R-devel the latest R etc. What it is is a snapshot of the current sources; it is not intended for production use. Do so and you'll suffer the consequences... It is by definition unstable: It may happen that someone forgets to add a new file while modifying another so that R no longer builds for anyone except himself -- we don't need 100 bug reports on R 2.16.0 on that account. Or there can be platform issues or unexpected CRAN repercussions. Notice that since R-devel and R-patched are constantly changing, the formal version number is insufficient to identify the set of sources, and we need the Subversion revision number to identify the exact set of sources. For basically the converse reasons, R (source) releases can not be changed retroactively. So until the next release, bug fixes go to R-patched or R-devel, which is why we ask people to at least check those versions (or just their NEWS files) before submitting bugs. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setting invalid fields on reference classes sometimes allowed
I've found that reference class objects tend to behave like plain old
environments wrt field access, unless a method on e.g. $- is explicitly
defined.
Here is a code snippet:
library(methods)
Foo - setRefClass(Foo)
foo - Foo$new()
foo$a - 2 # why does this succeed? not a valid field!
## set a silly $- method
setReplaceMethod($, Foo, function(x, name, value) {
callNextMethod(x, b, value)})
foo$b - 3
At first, we can set the non-existent field a without any error (I don't
think this is the intended behavior). Then we set a silly override on $-
and things start to behave as expected:
Error in envRefSetField(x, what, refObjectClass(x), selfEnv, value) :
b is not a field in class Foo
What am I doing wrong?
Thanks,
Michael
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setting invalid fields on reference classes sometimes allowed
This doesn't seem to have anything to do with reference classes but
rather is deep in the evaluator. At least when set up in the simple
form of your example, the $- method is never called.
For example:
Foo - setRefClass(Foo)
foo - Foo$new()
find($-)
[1] package:base
debug(base::`$-`)
foo$a - 1
Other variants on this seem still not to call the replacement function,
and therefore not to dispatch the correct method.
I haven't had a chance to debug this at the required grubby level, but
my guess is that the problem comes from base::`$-` being a primitive,
and not thinking it needs to check for methods.
Various kludgey workarounds will get the evaluator's attention and fix
things.
trace($-, sig = Foo, browser)
Tracing specified method for function $- in package base
[1] $-
untrace($-, sig = Foo)
Untracing specified method for function $- in package base
foo$a - 1
Error in envRefSetField(x, what, refObjectClass(x), selfEnv, value) :
a is not a field in class Foo
Sigh.
John
On 8/5/12 9:00 AM, Michael Lawrence wrote:
I've found that reference class objects tend to behave like plain old
environments wrt field access, unless a method on e.g. $- is explicitly
defined.
Here is a code snippet:
library(methods)
Foo - setRefClass(Foo)
foo - Foo$new()
foo$a - 2 # why does this succeed? not a valid field!
## set a silly $- method
setReplaceMethod($, Foo, function(x, name, value) {
callNextMethod(x, b, value)})
foo$b - 3
At first, we can set the non-existent field a without any error (I don't
think this is the intended behavior). Then we set a silly override on $-
and things start to behave as expected:
Error in envRefSetField(x, what, refObjectClass(x), selfEnv, value) :
b is not a field in class Foo
What am I doing wrong?
Thanks,
Michael
[[alternative HTML version deleted]]
__
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] setMethod sometimes fails to set package slot when signature has trailing 'ANY'
after this
setClass(A)
setGeneric(bar, function(x, y) standardGeneric(bar))
setMethod(bar, signature(x=A, y=A), function(x, y) {})
setMethod(bar, signature(x=A, y=ANY), function(x, y) {})
the method for signature c(A, A) contains package information
str(getMethod(bar, c(A, A)))
Formal class 'MethodDefinition' [package methods] with 4 slots
..@ .Data :function (x, y)
..@ target :Formal class 'signature' [package methods] with 3 slots
.. .. ..@ .Data : chr [1:2] A A
.. .. ..@ names : chr [1:2] x y
.. .. ..@ package: chr [1:2] .GlobalEnv .GlobalEnv
..@ defined:Formal class 'signature' [package methods] with 3 slots
.. .. ..@ .Data : chr [1:2] A A
.. .. ..@ names : chr [1:2] x y
.. .. ..@ package: chr [1:2] .GlobalEnv .GlobalEnv
..@ generic: atomic [1:1] bar
.. ..- attr(*, package)= chr .GlobalEnv
but the method for signature c(A, ANY) does not
str(getMethod(bar, c(A, ANY)))
Formal class 'MethodDefinition' [package methods] with 4 slots
..@ .Data :function (x, y)
..@ target :Formal class 'signature' [package methods] with 3 slots
.. .. ..@ .Data : chr [1:2] A ANY
.. .. ..@ names : chr [1:2] x y
.. .. ..@ package: chr [1:2]
..@ defined:Formal class 'signature' [package methods] with 3 slots
.. .. ..@ .Data : chr [1:2] A ANY
.. .. ..@ names : chr [1:2] x y
.. .. ..@ package: chr [1:2]
..@ generic: atomic [1:1] bar
.. ..- attr(*, package)= chr .GlobalEnv
This does not occur when the order of setMethod calls is reversed. The
reason is that the package information added when
methods/R/Methods.R:552 calls matchSignature are stripped (because
matchSignature returns a vector with trailing 'ANY' classes removed) by
the call to .matchSigLength at line 603.
The context for this is the thread starting at
https://stat.ethz.ch/pipermail/bioconductor/2012-August/047241.html
where a complicated package dependency and attempt to redefine an
existing method leads to
Error : package slot missing from signature for generic 'sampleNames-'
and classes LumiBatch, ANY
cannot use with duplicate class names (the package may need to be
re-installed)
Martin
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
