Re: [Rd] RCMD check fails on "checkin installed package size"
Hello Duncan,
This is what I get:
C:\Users\STME\Documents\R\win-library\2.13\AnnotationFuncs>du -k
209 ./doc
24 ./help
8 ./html
9 ./Meta
10 ./R
279 .
Kind regards,
Stefan McKinnon Høj-Edwards Dept. of Genetics and Biotechnology
PhD student Faculty of Agricultural Sciences
stefan.hoj-edwa...@agrsci.dkAarhus University
Tel.: +45 8999 1291 Blichers Allé 20, Postboks 50
Web: www.iysik.com DK-8830 Tjele
Tel.: +45 8999 1900
Web: www.agrsci.au.dk
-Oprindelig meddelelse-
Fra: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sendt: 12. maj 2011 14:11
Til: Stefan McKinnon Høj-Edwards
Cc: Prof Brian Ripley; r-devel@r-project.org
Emne: Re: [Rd] RCMD check fails on "checkin installed package size"
On 11/05/2011 8:07 AM, Stefan McKinnon Høj-Edwards wrote:
> Thanks. It worked.
> I added the line "_R_CHECK_PKG_SIZES_=no" to /etc/Rcmd_environ (I am the only
> user of this computer).
>
> Regarding the 'du' executable, it is found in the first directory in the PATH
> environment variable and came with Rtools for R 2.13.
R CMD check will try to run "du -k" while the current directory is the
one where it just installed the package during the check. If you do
that from the command line, (i.e. install AnnotationFuncs, switch to
RHOME/library/AnnotationFuncs, and run "du -k") what do you see as output?
Duncan Murdoch
> Kind regards,
> Stefan McKinnon Høj-Edwards
> PhD student
> Dept. of Genetics and Biotechnology
> Faculty of Agricultural Sciences
> Aarhus University
> Blichers Allé 20, Postboks 50
> DK-8830 Tjele
>
> Tel.: +45 8999 1291
> Email: stefanm.edwa...@agrsci.dk
>
> Tel.: +45 8999 1900
> Web: www.agrsci.au.dk
>
>
>
>
> -Oprindelig meddelelse-
> Fra: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
> Sendt: 11. maj 2011 13:51
> Til: Stefan McKinnon Høj-Edwards
> Cc: r-devel@r-project.org
> Emne: Re: [Rd] RCMD check fails on "checkin installed package size"
>
> On Wed, 11 May 2011, Stefan McKinnon Høj-Edwards wrote:
>
> > Hi,
> >
> > When I run RCMD check on my package, I receive the following error:
> > C:\R-packages\AnnotationFuncs>RCMD check --no-vignettes AnnotationFuncs
> > * using log directory
> > 'C:/R-packages/AnnotationFuncs/AnnotationFuncs.Rcheck'
> > * using R version 2.13.0 (2011-04-13)
> > * using platform: i386-pc-mingw32 (32-bit)
> > * using session charset: ISO8859-1
> > * using option '--no-vignettes'
> > * checking for file 'AnnotationFuncs/DESCRIPTION' ... OK
> > * this is package 'AnnotationFuncs' version '1.1.2'
> > * checking package name space information ... OK
> > * checking package dependencies ... OK
> > * checking if this is a source package ... OK
> > * checking for executable files ... OK
> > * checking whether package 'AnnotationFuncs' can be installed ... OK
> > * checking installed package size ...Error in if (total> 1024 * 5) { :
> > missing
> > value where TRUE/FALSE needed
> > Execution halted
> >
> >
> > I am running it on Windows 7 (32-bit) and my PATH environment variable
> > starts with this:
> > C:\Rtools\bin;C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.13.0\bin\i386;
> >
> > I have updated Rtools to the newest with 2.13.
> >
> > Any suggestions?
>
> Set _R_CHECK_PKG_SIZES_ to 'no' (see 'Writing R Extensions' and its
> references on customizing R CMD check), or correct your paths so the
> 'du' program in Rtools is the one that is found. (The only reported
> example was from using a different 'du' program.)
>
> I believe that current R-patched works around this: R-devel definitely
> does.
>
> >
> > Thanks in advanced,
> > Stefan McKinnon Høj-Edwards
> >
> > __
> > 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] Reproducible use case for R crash after updating R
On 11-05-16 11:59 PM, Henrik Bengtsson wrote:
Great, thanks for this.
On Fri, May 13, 2011 at 2:34 PM, Duncan Murdoch
wrote:
A simple version of a fix is now in R-devel: if the .RData file can't be
loaded during startup, an error message is printed, and R starts with an
empty workspace.
I've just verified with the R v2.14.0 devel (2011-05-16 r55916) on
Windows. For followers, here it is how it works now:
# GENERATE AN INVALID .RData file:
install.packages("fortunes")
library("fortunes")
foo<- fortune
remove.packages("fortunes")
q("yes")
Startup behavior when using either Rterm or Rgui:
[...]
Type 'q()' to quit R.
Error in loadNamespace(name) : there is no package called 'fortunes'
During startup - Warning message:
unable to restore saved data in .RData
cat("Hello world!\n")
Hello world!
The name of the .RData file is printed. It's usually just ".RData", because
that's what R tries to load; the file will be in the current directory if
you want to delete it.
I've looked at the code behind this and I kind of understand what you
mean by "just" .RData. However, is there a reason for not reporting
the full pathname to .RData, e.g. file.path(getwd(), ".RData")? It
would help the user further if the warning said:
This is coming from C code, so getting the current directory requires
allocating memory for a buffer. We're in a situation where something
that normally succeeds has just failed, so it might not be safe to do that.
(1) unable to restore saved data in .RData in directory /path/to/pwd/
(2) unable to restore saved data in /path/to/pwd/.RData
If the file that it tried to load was named "/path/to/.RData", then your
messages wouldn't be right:
(1) unable to restore saved data in /path/to/.RData in directory
/path/to/pwd/
(2) unable to restore saved data in /path/to/pwd//path/to/.RData
You really want something like normalizePath(), but that's not a simple
C function (and it has its own problems, e.g. if the file doesn't exist,
normalizePath doesn't work, at least on Windows).
Duncan Murdoch
BTW, the following will not be correct if the working directory is
changed by one of the .Rprofile startup scripts:
(2) unable to restore saved data in .RData in the current working
directory, cf. getwd()
Thanks again
/Henrik
If it contains objects that you want to recover, you
can try to deal with the error message (e.g. by installing fortunes in your
example), exiting without saving, and then the next restart may succeed.
Duncan Murdoch
On 11-05-12 2:26 PM, Henrik Bengtsson wrote:
On Thu, May 12, 2011 at 10:55 AM, Henrik Bengtsson
wrote:
This might have been discussed before, but below is a
"not-so-unlikely" use case where the user follows normal procedures,
updates R to a major release version, and then R crashes:
1. Use runs R stable (e.g. v2.13.0).
2. User installs a package with a namespace, e.g.
install.packages("fortunes").
3. User uses the package and one of the package's objects are assigned
to the global env, e.g. foo<- fortune.
4. The user quits R and stores the session data, e.g. q("yes"). The
session is stored in users home directory.
5. User update to new major release of R (e.g. 2.14.0).
6. User starts R. R crashes with "Fatal error: unable to restore
saved object in .RData" because 'fortunes' is not installed for this
new version of R. There is also an error message before that
reporting "Error in loadNamespace(name) : there is no package called
'fortunes'".
This can also be reproduced using a single R version as follows:
1. Start R and do:
install.packages("fortunes")
library("fortunes")
foo<- fortune
remove.packages("fortunes")
q("yes")
2. Restart R. R crashes.
For a GUI-only user this is complicated, because although the users
sees the informative error message that "Error in loadNamespace(name)
: there is no package called 'fortunes'", s/he cannot get to the point
where it is possible to install that missing package. The key for the
user is to understand to remove the .RData. In order to do this, s/he
has to locate that file first.
To simplify this, a few alternatives exists:
1. R reports the full path to the problematic .RData file.
2. R renames the problematic .RData file to
erroneous_20110512-123404UTC.RData and reports the new full pathname.
In both cases there could be the option for R to either exit, or
ignore the problematic .RData file and give the user access to the
prompt. One could also imaging a fancy recovery feature where R
detects "erroneous" .RData files and asks the user if s/he wish to try
to load them (maybe the packages has been installed since).
On Windows, the easiest way to give a GUI-only user access to the R
prompt is to also install an "R (vanilla mode)" shortcut/icon on the
Startup menu and Desktop (with target "...\Rgui.exe" --vanilla) in
addition to the default one.
/Henrik
I'm sure there are complications to implement the above, because
.RData is loaded during startup, but that's my $.02 to
Re: [Rd] Reproducible use case for R crash after updating R
The ability to do a "wounded load", when a proper load() can't be completed but
you still want as much of the stuff as possible, would be very useful. In my
experience, the trouble has invariably been a missing namespace, eg (as in
Henrik's example) from a package that can't be found. That's OK if the package
can be identified and updated. But sometimes it can't be-- maybe it just
doesn't exist for the latest greatest version of R, or the developer has
decided to work in Q instead, or the internet is having a bad day. If there are
lots of useful objects in the .RData, but a few things that won't load, it's
pretty bad to lose the whole lot. So triggering an comprehensible error is
useful for the specific case Henrik gives, but if this is being looked at
anyway, perhaps more could be done.
How about giving load() an optional argument, such that if a (namespace?)
environment is sought but can't be found, then it is replaced with emptyenv(),
with a warning. That should stop catastrophic behaviour later on.
I wonder whether the "refhook" argument of 'unserialize' could somehow be
perverted into doing this? Dunno, just a thought.
There might be other things besides missing packages that could cause a load()
to fail, but I think all the cases I've come across have come down to that. It
can be pretty hard to track down the problem, or worse than hard.
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of Duncan Murdoch [murdoch.dun...@gmail.com]
Sent: 17 May 2011 20:54
To: Henrik Bengtsson
Cc: R-devel
Subject: Re: [Rd] Reproducible use case for R crash after updating R
On 11-05-16 11:59 PM, Henrik Bengtsson wrote:
> Great, thanks for this.
>
> On Fri, May 13, 2011 at 2:34 PM, Duncan Murdoch
> wrote:
>> A simple version of a fix is now in R-devel: if the .RData file can't be
>> loaded during startup, an error message is printed, and R starts with an
>> empty workspace.
>
> I've just verified with the R v2.14.0 devel (2011-05-16 r55916) on
> Windows. For followers, here it is how it works now:
>
> # GENERATE AN INVALID .RData file:
> install.packages("fortunes")
> library("fortunes")
> foo<- fortune
> remove.packages("fortunes")
> q("yes")
>
> Startup behavior when using either Rterm or Rgui:
> [...]
> Type 'q()' to quit R.
>
> Error in loadNamespace(name) : there is no package called 'fortunes'
> During startup - Warning message:
> unable to restore saved data in .RData
>> cat("Hello world!\n")
> Hello world!
>>
>
>>
>> The name of the .RData file is printed. It's usually just ".RData", because
>> that's what R tries to load; the file will be in the current directory if
>> you want to delete it.
>
> I've looked at the code behind this and I kind of understand what you
> mean by "just" .RData. However, is there a reason for not reporting
> the full pathname to .RData, e.g. file.path(getwd(), ".RData")? It
> would help the user further if the warning said:
This is coming from C code, so getting the current directory requires
allocating memory for a buffer. We're in a situation where something
that normally succeeds has just failed, so it might not be safe to do that.
> (1) unable to restore saved data in .RData in directory /path/to/pwd/
> (2) unable to restore saved data in /path/to/pwd/.RData
If the file that it tried to load was named "/path/to/.RData", then your
messages wouldn't be right:
(1) unable to restore saved data in /path/to/.RData in directory
/path/to/pwd/
(2) unable to restore saved data in /path/to/pwd//path/to/.RData
You really want something like normalizePath(), but that's not a simple
C function (and it has its own problems, e.g. if the file doesn't exist,
normalizePath doesn't work, at least on Windows).
Duncan Murdoch
> BTW, the following will not be correct if the working directory is
> changed by one of the .Rprofile startup scripts:
>
> (2) unable to restore saved data in .RData in the current working
> directory, cf. getwd()
>
> Thanks again
>
> /Henrik
>
>> If it contains objects that you want to recover, you
>> can try to deal with the error message (e.g. by installing fortunes in your
>> example), exiting without saving, and then the next restart may succeed.
>>
>> Duncan Murdoch
>>
>>
>> On 11-05-12 2:26 PM, Henrik Bengtsson wrote:
>>>
>>> On Thu, May 12, 2011 at 10:55 AM, Henrik Bengtsson
>>> wrote:
This might have been discussed before, but below is a
"not-so-unlikely" use case where the user follows normal procedures,
updates R to a major release version, and then R crashes:
1. Use runs R stable (e.g. v2.13.0).
2. User installs a package with a namespace, e.g.
install.packages("fortunes").
3. User uses the package and one of the package's objects are assigned
to the global env, e.g. foo<- fortune.
4. The user quits R and stores the session data, e.g. q("yes"). The
Re: [Rd] By default, `names<-` alters S4 objects
One point that may have been unclear, though it's surprising if so. The
discussion was about assigning names to S4 objects from classes that do
NOT have a formal "names" slot. Of course, having a "names" slot is not
illegal, it's what one should do to deal with names in S4. Look at
class "namedList" for example.
Assigning names() to such a class would go through without warning as it
does now.
> getClass("namedList")
Class "namedList" [package "methods"]
Slots:
Name: .Data names
Class: list character
Extends:
Class "list", from data part
Class "vector", by class "list", distance 2
Known Subclasses: "listOfMethods"
> xx <- new("namedList", list(a=1,b=2))
> names(xx)
[1] "a" "b"
> names(xx) <- c("D", "E")
> xx@names
[1] "D" "E"
>
There was no question of breaking inheritance.
On 5/16/11 4:13 PM, Hervé Pagès wrote:
On 11-05-16 01:53 PM, John Chambers wrote:
On 5/16/11 10:09 AM, Hervé Pagès wrote:
On 11-05-16 09:36 AM, John Chambers wrote:
You set up a names slot in a non-vector. Maybe that should be allowed,
maybe not. But in any case I would not expect the names() primitive to
find it, because your object has a non-vector type ("S4").
But the names<-() primitive *does* find it. So either names() and
names<-() should both find it, or they shouldn't. I mean, if you care
about consistency and predictability of course.
That's not the only case where borderline or mistaken behavior is caught
on assignment, but not on access. The argument is that assignment can
afford to check things, but access needs to be fast. Slot access is
another case. There, assignment ensures legality so access can be quick.
The catch is that there are sometimes backdoor ways to assignments,
partly because slots, attributes and some "builtin" properties like
names overlap.
What we were talking about before was trying to evolve a sensible rule
for assigning names to S4 objects. Let's try to discuss what people need
to do before carping or indulging in sarcasm.
What *you* were talking about but not what my original post was about.
Anyway, about the following proposal:
1. If the class has a vector data slot and no names slot, assign the
names but with a warning.
2. Otherwise, throw an error.
(I.e., I would prefer an error throughout, but discretion )
I personally don't like it because it breaks inheritance. Let's
say I have a class B with a vector data slot and no names slot.
According to 1. names<-() would work out-of-the-box on it (with
a warning), but now if I extend it by adding a names slot, it
breaks.
One thing to consider though is that this works right now (and with
no warning):
> setClass("I", contains="integer")
[1] "I"
> i <- new("I", 1:4)
> names(i) <- LETTERS[1:4]
> attributes(i)
$class
[1] "I"
attr(,"package")
[1] ".GlobalEnv"
$names
[1] "A" "B" "C" "D"
> names(i)
[1] "A" "B" "C" "D"
and it's probably what most people would expect (sounds reasonable
after all). So this needs to keep working (with no warning). I can
see 2 ways to avoid breaking inheritance:
(a) not allow a names slot to be added to class I or any
of its subclasses (in other words the .Data and names
slots cannot coexist),
or
(b) have names() and names<-() keep working when the names slot is
added but that is maybe dangerous as it might break C code that
is trying to access the names, that is, inheritance might break
but now at the C level
Now for classes that don't have a .Data slot, they can of course
have a names slot. I don't have a strong opinion on whether names()
and names<-() should access it by default, but honestly that's really
a very small convenience offered to the developer of the class. Also,
for the sake of consistency, the same would need to be done for dim,
dimnames and built-in attributes in general. And also that won't work
if those built-in-attributes-made-slots are not declared with the right
type in the setClass statement (i.e. "character" for names, "integer"
for dim, etc...). And also by default names() would return character(0)
and not NULL. So in the end, potentially a lot of complications /
surprise / inconsistencies for very little value.
Thanks,
H.
John
H.
You could do
a@names if you thought that made sense:
> setClass("A", representation(names="character"))
[1] "A"
> a <- new("A")
> a@names <- "xx"
> a@names
[1] "xx"
> names(a)
NULL
If you wanted something sensible, it's more like:
> setClass("B", representation(names = "character"), contains =
"integer")
[1] "B"
> b <- new("B", 1:5)
> names(b) <- letters[1:5]
> b
An object of class "B"
[1] 1 2 3 4 5
Slot "names":
[1] "a" "b" "c" "d" "e"
> names(b)
[1] "a" "b" "c" "d" "e"
This allows both the S4 and the primitive code to deal with a
well-defined object.
John
On 5/15/11 3:02 PM, Hervé Pagès wrote:
On 11-05-15 11:33 AM, John Chambers wrote:
This is basically a case of a user error that is not being caught:
Sure!
https://stat.ethz.ch/pipermail/r-devel/2009-March/052386.html
..
Ah, that's i
Re: [Rd] By default, `names<-` alters S4 objects
On 11-05-17 09:04 AM, John Chambers wrote:
One point that may have been unclear, though it's surprising if so. The
discussion was about assigning names to S4 objects from classes that do
NOT have a formal "names" slot. Of course, having a "names" slot is not
illegal, it's what one should do to deal with names in S4.
IMO it looks more like what one should avoid to do right now because
it's broken (as reported previously):
> setClass("A", representation(names="character"))
> a <- new("A")
> names(a) <- "K"
> names(a)
NULL
And on that particular issue here is what you said:
You set up a names slot in a non-vector. Maybe that should be
allowed, maybe not.
And now:
Of course, having a "names" slot is not illegal, it's what one
should do to deal with names in S4.
??!
H.
Look at class
"namedList" for example.
Assigning names() to such a class would go through without warning as it
does now.
> getClass("namedList")
Class "namedList" [package "methods"]
Slots:
Name: .Data names
Class: list character
Extends:
Class "list", from data part
Class "vector", by class "list", distance 2
Known Subclasses: "listOfMethods"
> xx <- new("namedList", list(a=1,b=2))
> names(xx)
[1] "a" "b"
> names(xx) <- c("D", "E")
> xx@names
[1] "D" "E"
>
There was no question of breaking inheritance.
On 5/16/11 4:13 PM, Hervé Pagès wrote:
On 11-05-16 01:53 PM, John Chambers wrote:
On 5/16/11 10:09 AM, Hervé Pagès wrote:
On 11-05-16 09:36 AM, John Chambers wrote:
You set up a names slot in a non-vector. Maybe that should be allowed,
maybe not. But in any case I would not expect the names() primitive to
find it, because your object has a non-vector type ("S4").
But the names<-() primitive *does* find it. So either names() and
names<-() should both find it, or they shouldn't. I mean, if you care
about consistency and predictability of course.
That's not the only case where borderline or mistaken behavior is caught
on assignment, but not on access. The argument is that assignment can
afford to check things, but access needs to be fast. Slot access is
another case. There, assignment ensures legality so access can be quick.
The catch is that there are sometimes backdoor ways to assignments,
partly because slots, attributes and some "builtin" properties like
names overlap.
What we were talking about before was trying to evolve a sensible rule
for assigning names to S4 objects. Let's try to discuss what people need
to do before carping or indulging in sarcasm.
What *you* were talking about but not what my original post was about.
Anyway, about the following proposal:
1. If the class has a vector data slot and no names slot, assign the
names but with a warning.
2. Otherwise, throw an error.
(I.e., I would prefer an error throughout, but discretion )
I personally don't like it because it breaks inheritance. Let's
say I have a class B with a vector data slot and no names slot.
According to 1. names<-() would work out-of-the-box on it (with
a warning), but now if I extend it by adding a names slot, it
breaks.
One thing to consider though is that this works right now (and with
no warning):
> setClass("I", contains="integer")
[1] "I"
> i <- new("I", 1:4)
> names(i) <- LETTERS[1:4]
> attributes(i)
$class
[1] "I"
attr(,"package")
[1] ".GlobalEnv"
$names
[1] "A" "B" "C" "D"
> names(i)
[1] "A" "B" "C" "D"
and it's probably what most people would expect (sounds reasonable
after all). So this needs to keep working (with no warning). I can
see 2 ways to avoid breaking inheritance:
(a) not allow a names slot to be added to class I or any
of its subclasses (in other words the .Data and names
slots cannot coexist),
or
(b) have names() and names<-() keep working when the names slot is
added but that is maybe dangerous as it might break C code that
is trying to access the names, that is, inheritance might break
but now at the C level
Now for classes that don't have a .Data slot, they can of course
have a names slot. I don't have a strong opinion on whether names()
and names<-() should access it by default, but honestly that's really
a very small convenience offered to the developer of the class. Also,
for the sake of consistency, the same would need to be done for dim,
dimnames and built-in attributes in general. And also that won't work
if those built-in-attributes-made-slots are not declared with the right
type in the setClass statement (i.e. "character" for names, "integer"
for dim, etc...). And also by default names() would return character(0)
and not NULL. So in the end, potentially a lot of complications /
surprise / inconsistencies for very little value.
Thanks,
H.
John
H.
You could do
a@names if you thought that made sense:
> setClass("A", representation(names="character"))
[1] "A"
> a <- new("A")
> a@names <- "xx"
> a@names
[1] "xx"
> names(a)
NULL
If you wanted something sensible, it's more like:
> setClass("B", representation(names = "character"), contains =
"integer"
Re: [Rd] Windows Rzlib.dll gzopen and friends
R developers, If the absence of a more complete zlib is a permanent change, then is the best strategy to build and distribute a package that wraps a functional zlib? This seems like it will create problems with symbol resolution at the least. Including a zlib in each package that uses it also seems like a poor choice. What other strategies are recommended? Martin On 05/06/2011 09:58 AM, Martin Morgan wrote: This change has significant consequences for Windows packages using R's zlib, including packages providing core Bioconductor functionality. Are the changes in r55624 meant to be long-term? Martin On 04/29/2011 03:13 PM, Martin Morgan wrote: Several Bioconductor packages were expecting Windows Rzlib.dll to provide gzopen / gzread / gzseek / gzgets / gzrewind / gzclose. Are these gone for good, viz., r55624 ? Martin -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lines.loess method - in order to make the plotting of loess consistent with that of lowess
Hello dear R developers,
# Bellow is an added method to lines to make the plotting of loess
consistent with what we get when using lines on lowess (which is also, IMHO,
more "intuitive")
lines.loess <- function(object,...)
{
# object: a loess object to plot using lines
# ...: passes to lines
ss <- order(object$x)
lines(object$fitted[ss] ~ object$x[ss],...)
}
# example of why this is useful:
set.seed(134)
y <- rnorm(100)
x <- rnorm(100)
plot(y~x)
lines(lowess(y~x), col = 1, lwd = 3)
lines.default(loess(y~x), col = 2)
lines.loess(loess(y~x), col = 3, lwd = 5)
legend("topright", legend = c("lines.default", "lines.loess", "lines for
lowess"), fill = c(2,3,1))
Best,
Tal Galili
Contact
Details:---
Contact me: tal.gal...@gmail.com | 972-52-7275845
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
--
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] By default, `names<-` alters S4 objects
On 5/17/11 9:53 AM, Hervé Pagès wrote:
On 11-05-17 09:04 AM, John Chambers wrote:
One point that may have been unclear, though it's surprising if so. The
discussion was about assigning names to S4 objects from classes that do
NOT have a formal "names" slot. Of course, having a "names" slot is not
illegal, it's what one should do to deal with names in S4.
IMO it looks more like what one should avoid to do right now because
it's broken (as reported previously):
> setClass("A", representation(names="character"))
> a <- new("A")
> names(a) <- "K"
> names(a)
NULL
And on that particular issue here is what you said:
You set up a names slot in a non-vector. Maybe that should be
allowed, maybe not.
And now:
Of course, having a "names" slot is not illegal, it's what one
should do to deal with names in S4.
??!]
Good grief. The classes like namedList _are_ vectors, that's the point.
Anyway, this is a waste of time. I will add some code to r-devel that
checks S4 objects when assigning names. People can try it out on their
examples.
H.
Look at class
"namedList" for example.
Assigning names() to such a class would go through without warning as it
does now.
> getClass("namedList")
Class "namedList" [package "methods"]
Slots:
Name: .Data names
Class: list character
Extends:
Class "list", from data part
Class "vector", by class "list", distance 2
Known Subclasses: "listOfMethods"
> xx <- new("namedList", list(a=1,b=2))
> names(xx)
[1] "a" "b"
> names(xx) <- c("D", "E")
> xx@names
[1] "D" "E"
>
There was no question of breaking inheritance.
On 5/16/11 4:13 PM, Hervé Pagès wrote:
On 11-05-16 01:53 PM, John Chambers wrote:
On 5/16/11 10:09 AM, Hervé Pagès wrote:
On 11-05-16 09:36 AM, John Chambers wrote:
You set up a names slot in a non-vector. Maybe that should be
allowed,
maybe not. But in any case I would not expect the names()
primitive to
find it, because your object has a non-vector type ("S4").
But the names<-() primitive *does* find it. So either names() and
names<-() should both find it, or they shouldn't. I mean, if you care
about consistency and predictability of course.
That's not the only case where borderline or mistaken behavior is
caught
on assignment, but not on access. The argument is that assignment can
afford to check things, but access needs to be fast. Slot access is
another case. There, assignment ensures legality so access can be
quick.
The catch is that there are sometimes backdoor ways to assignments,
partly because slots, attributes and some "builtin" properties like
names overlap.
What we were talking about before was trying to evolve a sensible rule
for assigning names to S4 objects. Let's try to discuss what people
need
to do before carping or indulging in sarcasm.
What *you* were talking about but not what my original post was about.
Anyway, about the following proposal:
1. If the class has a vector data slot and no names slot, assign the
names but with a warning.
2. Otherwise, throw an error.
(I.e., I would prefer an error throughout, but discretion )
I personally don't like it because it breaks inheritance. Let's
say I have a class B with a vector data slot and no names slot.
According to 1. names<-() would work out-of-the-box on it (with
a warning), but now if I extend it by adding a names slot, it
breaks.
One thing to consider though is that this works right now (and with
no warning):
> setClass("I", contains="integer")
[1] "I"
> i <- new("I", 1:4)
> names(i) <- LETTERS[1:4]
> attributes(i)
$class
[1] "I"
attr(,"package")
[1] ".GlobalEnv"
$names
[1] "A" "B" "C" "D"
> names(i)
[1] "A" "B" "C" "D"
and it's probably what most people would expect (sounds reasonable
after all). So this needs to keep working (with no warning). I can
see 2 ways to avoid breaking inheritance:
(a) not allow a names slot to be added to class I or any
of its subclasses (in other words the .Data and names
slots cannot coexist),
or
(b) have names() and names<-() keep working when the names slot is
added but that is maybe dangerous as it might break C code that
is trying to access the names, that is, inheritance might break
but now at the C level
Now for classes that don't have a .Data slot, they can of course
have a names slot. I don't have a strong opinion on whether names()
and names<-() should access it by default, but honestly that's really
a very small convenience offered to the developer of the class. Also,
for the sake of consistency, the same would need to be done for dim,
dimnames and built-in attributes in general. And also that won't work
if those built-in-attributes-made-slots are not declared with the right
type in the setClass statement (i.e. "character" for names, "integer"
for dim, etc...). And also by default names() would return character(0)
and not NULL. So in the end, potentially a lot of complications /
surprise / inconsistencies for very little value.
Thanks,
H.
John
H.
You could do
a@names if you thought that made sense:
Re: [Rd] By default, `names<-` alters S4 objects
On 11-05-17 01:15 PM, John Chambers wrote:
On 5/17/11 9:53 AM, Hervé Pagès wrote:
On 11-05-17 09:04 AM, John Chambers wrote:
One point that may have been unclear, though it's surprising if so. The
discussion was about assigning names to S4 objects from classes that do
NOT have a formal "names" slot. Of course, having a "names" slot is not
illegal, it's what one should do to deal with names in S4.
IMO it looks more like what one should avoid to do right now because
it's broken (as reported previously):
> setClass("A", representation(names="character"))
> a <- new("A")
> names(a) <- "K"
> names(a)
NULL
And on that particular issue here is what you said:
You set up a names slot in a non-vector. Maybe that should be
allowed, maybe not.
And now:
Of course, having a "names" slot is not illegal, it's what one
should do to deal with names in S4.
??!]
Good grief. The classes like namedList _are_ vectors, that's the point.
Anyway, this is a waste of time. I will add some code to r-devel that
checks S4 objects when assigning names. People can try it out on their
examples.
Thanks!
H.
H.
Look at class
"namedList" for example.
Assigning names() to such a class would go through without warning as it
does now.
> getClass("namedList")
Class "namedList" [package "methods"]
Slots:
Name: .Data names
Class: list character
Extends:
Class "list", from data part
Class "vector", by class "list", distance 2
Known Subclasses: "listOfMethods"
> xx <- new("namedList", list(a=1,b=2))
> names(xx)
[1] "a" "b"
> names(xx) <- c("D", "E")
> xx@names
[1] "D" "E"
>
There was no question of breaking inheritance.
On 5/16/11 4:13 PM, Hervé Pagès wrote:
On 11-05-16 01:53 PM, John Chambers wrote:
On 5/16/11 10:09 AM, Hervé Pagès wrote:
On 11-05-16 09:36 AM, John Chambers wrote:
You set up a names slot in a non-vector. Maybe that should be
allowed,
maybe not. But in any case I would not expect the names()
primitive to
find it, because your object has a non-vector type ("S4").
But the names<-() primitive *does* find it. So either names() and
names<-() should both find it, or they shouldn't. I mean, if you care
about consistency and predictability of course.
That's not the only case where borderline or mistaken behavior is
caught
on assignment, but not on access. The argument is that assignment can
afford to check things, but access needs to be fast. Slot access is
another case. There, assignment ensures legality so access can be
quick.
The catch is that there are sometimes backdoor ways to assignments,
partly because slots, attributes and some "builtin" properties like
names overlap.
What we were talking about before was trying to evolve a sensible rule
for assigning names to S4 objects. Let's try to discuss what people
need
to do before carping or indulging in sarcasm.
What *you* were talking about but not what my original post was about.
Anyway, about the following proposal:
1. If the class has a vector data slot and no names slot, assign the
names but with a warning.
2. Otherwise, throw an error.
(I.e., I would prefer an error throughout, but discretion )
I personally don't like it because it breaks inheritance. Let's
say I have a class B with a vector data slot and no names slot.
According to 1. names<-() would work out-of-the-box on it (with
a warning), but now if I extend it by adding a names slot, it
breaks.
One thing to consider though is that this works right now (and with
no warning):
> setClass("I", contains="integer")
[1] "I"
> i <- new("I", 1:4)
> names(i) <- LETTERS[1:4]
> attributes(i)
$class
[1] "I"
attr(,"package")
[1] ".GlobalEnv"
$names
[1] "A" "B" "C" "D"
> names(i)
[1] "A" "B" "C" "D"
and it's probably what most people would expect (sounds reasonable
after all). So this needs to keep working (with no warning). I can
see 2 ways to avoid breaking inheritance:
(a) not allow a names slot to be added to class I or any
of its subclasses (in other words the .Data and names
slots cannot coexist),
or
(b) have names() and names<-() keep working when the names slot is
added but that is maybe dangerous as it might break C code that
is trying to access the names, that is, inheritance might break
but now at the C level
Now for classes that don't have a .Data slot, they can of course
have a names slot. I don't have a strong opinion on whether names()
and names<-() should access it by default, but honestly that's really
a very small convenience offered to the developer of the class. Also,
for the sake of consistency, the same would need to be done for dim,
dimnames and built-in attributes in general. And also that won't work
if those built-in-attributes-made-slots are not declared with the right
type in the setClass statement (i.e. "character" for names, "integer"
for dim, etc...). And also by default names() would return character(0)
and not NULL. So in the end, potentially a lot of complications /
surprise / inconsistencies for very little value.
Thanks,
H.
John
H.
You
[Rd] S3 method dispatch - can methods come from the enclosing environment?
I was surprised to see that S3 methods are not found if they only reside in the
enclosing environment. E.g.:
> tstFn <- local({
+ print.tst <- function(x, ...) cat("found it!")
+
+ function(x) print(x)
+ })
>
> z <- "The cat sat on the mat."
> class(x) <- "tst"
>
> tstFn(z)
[1] "The cat sat on the mat."
>
So the answer to the question posed in the subject line is apparently "no".
Perhaps this is well known and fully documented somewhere, but if so it has
eluded me. Is there some reason for this?
I'm not sure if this is a bug, a feature, or a proposal for development, but I
would welcome people's views on this curious little issue.
Bill Venables.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 method dispatch - can methods come from the enclosing environment?
Bill,
I suspect you have a typo there [class(x) instead of class(z)] which is why it
doesn't work. Without the typo it does:
> tstFn <- local({
+ print.tst <- function(x, ...) cat("found it!")
+
+ function(x) print(x)
+ })
>
> z <- "The cat sat on the mat."
> class(z) <- "tst"
>
> tstFn(z)
found it!
Cheers,
Simon
On May 17, 2011, at 7:32 PM,
wrote:
> I was surprised to see that S3 methods are not found if they only reside in
> the enclosing environment. E.g.:
>
>> tstFn <- local({
> + print.tst <- function(x, ...) cat("found it!")
> +
> + function(x) print(x)
> + })
>>
>> z <- "The cat sat on the mat."
>> class(x) <- "tst"
>>
>> tstFn(z)
> [1] "The cat sat on the mat."
>>
>
> So the answer to the question posed in the subject line is apparently "no".
> Perhaps this is well known and fully documented somewhere, but if so it has
> eluded me. Is there some reason for this?
>
> I'm not sure if this is a bug, a feature, or a proposal for development, but
> I would welcome people's views on this curious little issue.
>
> Bill Venables.
> __
> 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] S3 method dispatch - can methods come from the enclosing environment?
My apologies... how embarrassing.
Please resume your normal duties. :-)
Bill.
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: Wednesday, 18 May 2011 10:36 AM
To: Venables, Bill (CMIS, Dutton Park)
Cc: r-devel@r-project.org
Subject: Re: [Rd] S3 method dispatch - can methods come from the enclosing
environment?
Bill,
I suspect you have a typo there [class(x) instead of class(z)] which is why it
doesn't work. Without the typo it does:
> tstFn <- local({
+ print.tst <- function(x, ...) cat("found it!")
+
+ function(x) print(x)
+ })
>
> z <- "The cat sat on the mat."
> class(z) <- "tst"
>
> tstFn(z)
found it!
Cheers,
Simon
On May 17, 2011, at 7:32 PM,
wrote:
> I was surprised to see that S3 methods are not found if they only reside in
> the enclosing environment. E.g.:
>
>> tstFn <- local({
> + print.tst <- function(x, ...) cat("found it!")
> +
> + function(x) print(x)
> + })
>>
>> z <- "The cat sat on the mat."
>> class(x) <- "tst"
>>
>> tstFn(z)
> [1] "The cat sat on the mat."
>>
>
> So the answer to the question posed in the subject line is apparently "no".
> Perhaps this is well known and fully documented somewhere, but if so it has
> eluded me. Is there some reason for this?
>
> I'm not sure if this is a bug, a feature, or a proposal for development, but
> I would welcome people's views on this curious little issue.
>
> Bill Venables.
> __
> 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
