[Rd] Bug in str or issue with class management in my package?
Dear developeRs,
with R 2.4.1 (and also 2.4.0), the function str() fails on objects of class
relimplmbooteval, if there are unused slots, which is very often the case. I
am not sure whether this is a bug in str() or a correct behavior of str()
that unmasks some sloppiness in my usage of S4 classes (that I am not aware
of)?
Reproducible example (package relaimpo needed):
The program
require(relaimpo)
bte<-booteval.relimp(boot.relimp(swiss,b=100))
str(bte)
yields the error message
Errorr in FUN(c("lmg.lower", "lmg.upper", "lmg.rank.lower",
"lmg.rank.upper", :
no slot named "pmvd.lower" for this object of class
"relimplmbooteval"
(back-translated from German).
Regards, Ulrike
--
View this message in context:
http://www.nabble.com/Bug-in-str-or-issue-with-class-management-in-my-package--tf3453429.html#a9633559
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in str or issue with class management in my package?
Ulrike,
booteval.relimp has the statement
ausgabe <- calc.relimp(empcov, type = type, diff = diff,
rank = rank, rela = rela, always = always, groups = groups,
groupnames = groupnames)
class(ausgabe) <- "relimplmbooteval"
This changes the name of the class of ausgabe, without changing its
structure. I'm guessing that prior to this call ausgabe did not have a
slot "pmvd.lower". Here's the simpler version:
>setClass("A", representation=representation(x="numeric"))
[1] "A"
> setClass("B", contains="A", representation=representation(y="numeric"))
[1] "B"
> a <- new("A")
> class(a) <- "B"
> str(a)
Error in FUN(c("y", "x")[[1L]], ...) : no slot of name "y" for this object of
class "B"
and some behavior which is somehow weird:
> slot(a, "y")
Error in slot(a, "y") : no slot of name "y" for this object of class "B"
> slot(a, "y") <- 10 # 'creates' the slot!
> slot(a, "y")
[1] 10
Probably what you want to do is to create a 'setAs' method
setAs('relimplm', 'relimplmbooteval',
function(from) {
})
and use
ausgabe <- as(ausgabe, "relimplmbooteval")
I'm not really sure what should look like; my first
stab was
obj <- new("relimplmbooteval")
slots <- slotNames(from)
for (slt in slots)
slot(obj, slt) <- slot(from, slt)
obj
which would not be very memory efficient (each slot assignment copies
the entire object) but is perhaps fine for your needs.
Hope that helps
Martin
Ulrike Grömping <[EMAIL PROTECTED]> writes:
> Dear developeRs,
>
> with R 2.4.1 (and also 2.4.0), the function str() fails on objects of class
> relimplmbooteval, if there are unused slots, which is very often the case. I
> am not sure whether this is a bug in str() or a correct behavior of str()
> that unmasks some sloppiness in my usage of S4 classes (that I am not aware
> of)?
>
> Reproducible example (package relaimpo needed):
>
> The program
>
> require(relaimpo)
> bte<-booteval.relimp(boot.relimp(swiss,b=100))
> str(bte)
>
> yields the error message
>
> Errorr in FUN(c("lmg.lower", "lmg.upper", "lmg.rank.lower",
> "lmg.rank.upper", :
> no slot named "pmvd.lower" for this object of class
> "relimplmbooteval"
> (back-translated from German).
>
> Regards, Ulrike
> --
> View this message in context:
> http://www.nabble.com/Bug-in-str-or-issue-with-class-management-in-my-package--tf3453429.html#a9633559
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to use debug.mypkg
Here is the way I do something similar in my dse1 package:
..onLoad <- function(library, section) {
.DSEflags(list(COMPILED=TRUE, DUP=TRUE))
invisible(TRUE)
}
..DSEflags <- local({
.DSE.flags <- character(0)
function(new) {
if(!missing(new))
.DSE.flags <<- new
else
.DSE.flags
}
})
This was suggested to me a few years ago (by Kurt I think). It works
well. A call to .DSEflags() displays the settings and a list argument
sets them.
Paul
Seth Falcon wrote:
> Benilton Carvalho <[EMAIL PROTECTED]> writes:
>
>> it doesn't matter where..
>>
>> just pick one of your files and set it...
>>
>> of course, your file should be listed in the Collate field (in case
>> you changed your mind and are now using it).
>
> One useful trick is to create an environment object in your package's
> namespace. It is probably best to put this early in the Collate order
> so all your code can assume it is there:
>
>OPTIONS <- new.env(hash=TRUE, parent=emptyenv())
>
> Then you could have, for example, a debug flag that gets a default
> value of FALSE, but can be interactively toggled. In your package
> code you would have:
>
>OPTIONS$debug <- FALSE
>
> Then you could either export this object from your namespace or, more
> conservatively, export a function to toggle. Then an end user (or
> developer) can do:
>
> R> toggleDebug()
>
> Obviously, for this to be useful, you need to have package code that
> checks if(OPTIONS$debug) and does something different.
>
> + seth
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in str or issue with class management in my package?
Martin,
thank you, you've pointed me in the right direction! I just wasn't aware
that a slot must not be unassigned (everything but str worked so far, and
even str works in R 2.3.1).
Actually, looking up the help for function new, I see that the solution is
much easier, because my class relimplmbooteval extends the class relimplm of
the object ausgabe. Therefore, I can simply write
obj <- new("relimplmbooteval", ausgabe)
which copies all slots from ausgabe to the right place in the new obj.
Regards, Ulrike
Martin Morgan wrote:
>
> Ulrike,
>
> booteval.relimp has the statement
>
> ausgabe <- calc.relimp(empcov, type = type, diff = diff,
> rank = rank, rela = rela, always = always, groups = groups,
> groupnames = groupnames)
> class(ausgabe) <- "relimplmbooteval"
>
> This changes the name of the class of ausgabe, without changing its
> structure. I'm guessing that prior to this call ausgabe did not have a
> slot "pmvd.lower". Here's the simpler version:
>
>>setClass("A", representation=representation(x="numeric"))
> [1] "A"
>> setClass("B", contains="A", representation=representation(y="numeric"))
> [1] "B"
>> a <- new("A")
>> class(a) <- "B"
>> str(a)
> Error in FUN(c("y", "x")[[1L]], ...) : no slot of name "y" for this object
> of class "B"
>
> and some behavior which is somehow weird:
>
>> slot(a, "y")
> Error in slot(a, "y") : no slot of name "y" for this object of class "B"
>> slot(a, "y") <- 10 # 'creates' the slot!
>> slot(a, "y")
> [1] 10
>
> Probably what you want to do is to create a 'setAs' method
>
> setAs('relimplm', 'relimplmbooteval',
> function(from) {
>
> })
>
> and use
>
> ausgabe <- as(ausgabe, "relimplmbooteval")
>
> I'm not really sure what should look like; my first
> stab was
>
> obj <- new("relimplmbooteval")
> slots <- slotNames(from)
> for (slt in slots)
> slot(obj, slt) <- slot(from, slt)
> obj
>
> which would not be very memory efficient (each slot assignment copies
> the entire object) but is perhaps fine for your needs.
>
> Hope that helps
>
> Martin
>
> Ulrike Grömping <[EMAIL PROTECTED]> writes:
>
>> Dear developeRs,
>>
>> with R 2.4.1 (and also 2.4.0), the function str() fails on objects of
>> class
>> relimplmbooteval, if there are unused slots, which is very often the
>> case. I
>> am not sure whether this is a bug in str() or a correct behavior of str()
>> that unmasks some sloppiness in my usage of S4 classes (that I am not
>> aware
>> of)?
>>
>> Reproducible example (package relaimpo needed):
>>
>> The program
>>
>> require(relaimpo)
>> bte<-booteval.relimp(boot.relimp(swiss,b=100))
>> str(bte)
>>
>> yields the error message
>>
>> Errorr in FUN(c("lmg.lower", "lmg.upper", "lmg.rank.lower",
>> "lmg.rank.upper", :
>> no slot named "pmvd.lower" for this object of class
>> "relimplmbooteval"
>> (back-translated from German).
>>
>> Regards, Ulrike
>> --
>> View this message in context:
>> http://www.nabble.com/Bug-in-str-or-issue-with-class-management-in-my-package--tf3453429.html#a9633559
>> Sent from the R devel mailing list archive at Nabble.com.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Martin Morgan
> Bioconductor / Computational Biology
> http://bioconductor.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
View this message in context:
http://www.nabble.com/Bug-in-str-or-issue-with-class-management-in-my-package--tf3453429.html#a9637517
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] can't load just saved R object "ReadItem: unknown type 65"
According to the logs nothing at all has changed in the serialization
code in a month and nothing of consequence for much longer than that.
To track this down we will need a complete, reproducible, and
preferably minimal example.
Best,
luke
On Thu, 22 Mar 2007, Mark W Kimpel wrote:
> I have run into a problem loading a just saved R object using R-devel. I
> have been saving and loading this particular type of R object for a long
> while and never ran into this problem. I save, then immediately reload
> (to test save) and get "ReadItem: unnknown type 65".
>
> This error is reproducible after logout from server and restart of emacs
> and R.
>
> Below is my output and sessionInfo().
>
> Thanks,
> Mark
>
> > setwd("~/Genomics/Experiments.Genomic/BB01/acb.shell")
> > local(save(affy.object.preprocessed, file
> ="affy.object.preprocessed.R" ))
> > load("affy.object.preprocessed.R")
> Error in load("affy.object.preprocessed.R") :
> ReadItem: unknown type 65, perhaps written by later version of R
> > sessionInfo()
> R version 2.5.0 Under development (unstable) (2007-03-11 r40824)
> powerpc64-unknown-linux-gnu
>
> locale:
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] "splines" "stats" "graphics" "grDevices" "datasets" "utils"
> [7] "tools" "methods" "base"
>
> other attached packages:
> multtestrat2302cdf affycoretools annaffyxtable
> "1.13.1" "1.15.0" "1.7.8" "1.7.3" "1.4-3"
> gcrma matchprobes biomaRt RCurl XML
> "2.7.3" "1.7.4" "1.9.21" "0.8-0" "1.6-0"
> GOstats CategoryMatrix latticegenefilter
> "2.1.13" "2.1.20" "0.9975-11" "0.14-16" "1.13.8"
> survival KEGG RBGL annotateGO
>"2.31" "1.15.12" "1.11.4" "1.13.6" "1.15.12"
> graph limma affyaffyio Biobase
> "1.13.6" "2.9.13" "1.13.14" "1.3.3" "1.13.39"
>
--
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] Bug in str or issue with class management in my package?
Hi,
> "Ulrike" == Ulrike Grömping <[EMAIL PROTECTED]>
> on Fri, 23 Mar 2007 08:39:32 -0700 (PDT) writes:
Ulrike> Martin,
Ulrike> thank you, you've pointed me in the right direction! I just wasn't
aware
Ulrike> that a slot must not be unassigned (everything but str worked so
far, and
Ulrike> even str works in R 2.3.1).
That "everything worked" is actually quite astonishing to me.
I'd have expected that you should get an *error* when using
class() <- "arbitraryString"
since - as Martin Morgan mentioned - you typically coerce
S4 objects to a new class by as(<..>, "new class")
~
[ which either needs an explicit SetAs(from,to, )
declaration ``earlier on'' (typically by one of the class
designers, often package authors),
or an implicit one - as in your case, when one class extends
another ]
Martin Mächler, ETH Zurich
Ulrike> Actually, looking up the help for function new, I see that the
solution is
Ulrike> much easier, because my class relimplmbooteval extends the class
relimplm of
Ulrike> the object ausgabe. Therefore, I can simply write
Ulrike> obj <- new("relimplmbooteval", ausgabe)
Ulrike> which copies all slots from ausgabe to the right place in the new
obj.
Ulrike> Regards, Ulrike
Ulrike> Martin Morgan wrote:
>>
>> Ulrike,
>>
>> booteval.relimp has the statement
>>
>> ausgabe <- calc.relimp(empcov, type = type, diff = diff,
>> rank = rank, rela = rela, always = always, groups = groups,
>> groupnames = groupnames)
>> class(ausgabe) <- "relimplmbooteval"
>>
>> This changes the name of the class of ausgabe, without changing its
>> structure. I'm guessing that prior to this call ausgabe did not have a
>> slot "pmvd.lower". Here's the simpler version:
>>
>>> setClass("A", representation=representation(x="numeric"))
>> [1] "A"
>>> setClass("B", contains="A", representation=representation(y="numeric"))
>> [1] "B"
>>> a <- new("A")
>>> class(a) <- "B"
>>> str(a)
>> Error in FUN(c("y", "x")[[1L]], ...) : no slot of name "y" for this
object
>> of class "B"
>>
>> and some behavior which is somehow weird:
>>
>>> slot(a, "y")
>> Error in slot(a, "y") : no slot of name "y" for this object of class "B"
>>> slot(a, "y") <- 10 # 'creates' the slot!
>>> slot(a, "y")
>> [1] 10
>>
>> Probably what you want to do is to create a 'setAs' method
>>
>> setAs('relimplm', 'relimplmbooteval',
>> function(from) {
>>
>> })
>>
>> and use
>>
>> ausgabe <- as(ausgabe, "relimplmbooteval")
>>
>> I'm not really sure what should look like; my first
>> stab was
>>
>> obj <- new("relimplmbooteval")
>> slots <- slotNames(from)
>> for (slt in slots)
>> slot(obj, slt) <- slot(from, slt)
>> obj
>>
>> which would not be very memory efficient (each slot assignment copies
>> the entire object) but is perhaps fine for your needs.
>>
>> Hope that helps
>>
>> Martin
>>
>> Ulrike Grömping <[EMAIL PROTECTED]> writes:
>>
>>> Dear developeRs,
>>>
>>> with R 2.4.1 (and also 2.4.0), the function str() fails on objects of
>>> class
>>> relimplmbooteval, if there are unused slots, which is very often the
>>> case. I
>>> am not sure whether this is a bug in str() or a correct behavior of
str()
>>> that unmasks some sloppiness in my usage of S4 classes (that I am not
>>> aware
>>> of)?
>>>
>>> Reproducible example (package relaimpo needed):
>>>
>>> The program
>>>
>>> require(relaimpo)
>>> bte<-booteval.relimp(boot.relimp(swiss,b=100))
>>> str(bte)
>>>
>>> yields the error message
>>>
>>> Errorr in FUN(c("lmg.lower", "lmg.upper", "lmg.rank.lower",
>>> "lmg.rank.upper", :
>>> no slot named "pmvd.lower" for this object of class
>>> "relimplmbooteval"
>>> (back-translated from German).
>>>
>>> Regards, Ulrike
>>> --
>>> View this message in context:
>>>
http://www.nabble.com/Bug-in-str-or-issue-with-class-management-in-my-package--tf3453429.html#a9633559
>>> Sent from the R devel mailing list archive at Nabble.com.
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> --
>> Martin Morgan
>> Bioconductor / Computational Biology
>> http://bioconductor.org
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
Ulrike> --
Ulrike> View this message in context:
http://www.nabble.com/Bug-in-str-or-issue-with-class-management-in-my-package--tf3453429.html#a9637517
Ulrike>
Re: [Rd] Bug in str or issue with class management in my package?
Martin,
I agree, if the naive changing of class (like also in Martina Morgan's simpler
example below) causes issues later, it would be best if it throws an error
straight away. That would have forced me to think about the correct way of
changing the class immediately.
I have experienced no problems with "my way" so far in my package, all methods
on objects of the class in question work without trouble; but that may be due
to the fact that I payed attention in the methods that slots are only used if
they exist.
Regards, Ulrike
> Hi,
>
> > "Ulrike" == Ulrike Grömping <[EMAIL PROTECTED]>
> > on Fri, 23 Mar 2007 08:39:32 -0700 (PDT) writes:
>
> Ulrike> Martin,
>
> Ulrike> thank you, you've pointed me in the right direction! I just wasn't
> aware
> Ulrike> that a slot must not be unassigned (everything but str worked so
> far, and
> Ulrike> even str works in R 2.3.1).
>
> That "everything worked" is actually quite astonishing to me.
>
> I'd have expected that you should get an *error* when using
>
> class() <- "arbitraryString"
>
> since - as Martin Morgan mentioned - you typically coerce
> S4 objects to a new class by as(<..>, "new class")
> ~
> [ which either needs an explicit SetAs(from,to, )
> declaration ``earlier on'' (typically by one of the class
> designers, often package authors),
> or an implicit one - as in your case, when one class extends
> another ]
Simple example from Martin Morgan, how "manual change" of class attribute works:
> > setClass("A", representation=representation(x="numeric"))
> [1] "A"
> > setClass("B", contains="A", representation=representation(y="numeric"))
> [1] "B"
> > a <- new("A")
> > class(a) <- "B"
> > str(a)
> Error in FUN(c("y", "x")[[1L]], ...) : no slot of name "y" for this
> object
> of class "B"
>
> and some behavior which is somehow weird:
>
> > slot(a, "y")
> Error in slot(a, "y") : no slot of name "y" for this object of class "B"
> > slot(a, "y") <- 10 # 'creates' the slot!
> > slot(a, "y")
> [1] 10
--- End of Original Message ---
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to use debug.mypkg
Thank you all for your suggestions, I have implemented the OPTIONS "option", since it allows to define other options, too. Yes, I use now the Collate field, since it gives me the possibility to organize my files in the way I want. Best regards Christian Benilton Carvalho wrote: > it doesn't matter where.. > > just pick one of your files and set it... > > of course, your file should be listed in the Collate field (in case > you changed your mind and are now using it). > > b > > On Mar 22, 2007, at 6:52 PM, cstrato wrote: > >> Yes, I know, but somewhere in my package I need to define this flag. >> When I set the flag "debug.mypkg<-T" in the R session, everything works, >> but the problem is that if I do not set it, it is undefined. So I >> need to set it >> initially in my package, but where? >> >> Christian >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cbind() & rbind() for S4 objects -- 'Matrix' package changes
Thank you, Luke, for your feedback,
(more inline below)
> "Luke" == Luke Tierney <[EMAIL PROTECTED]>
> on Tue, 20 Mar 2007 20:27:18 -0500 (CDT) writes:
Luke> On Tue, 20 Mar 2007, Martin Maechler wrote:
>> As some of you may have seen / heard in the past,
>> it is not possible to make cbind() and rbind() into proper S4
>> generic functions, since their first formal argument is '...'.
>> [ BTW: S3-methods for these of course only dispatch on the first
>> argument which is also not really satisfactory in the context
>> of many possible matrix classes.]
>>
>> For this reason, after quite some discussion on R-core (and
>> maybe a bit on R-devel) about the options, since R-2.2.0 we have
>> had S4 generic functions cbind2() and rbind2() (and default methods)
>> in R's "methods" which are a version of cbind() and
>> rbind() respectively for two arguments (x,y)
>> {and fixed 'deparse.level = 0' : the argument names are 'x' and 'y' and
>> hence don't make sense to be used to construct column-names or
>> row-names for rbind(), respectively.}
>>
>> We have been defining methods for cbind2() and rbind2()
>> for the 'Matrix' classes in late summer 2005 as well. So far so
>> good.
>>
>> In addition, [see also help(cbind2) ],
>> we have defined cbind() and rbind() functions which recursively call
>> cbind2() and rbind2(), more or less following John Chambers
>> proposal of dealing with such "(...)" argument functions.
>> These new recursively defined cbind() / rbind() functions
>> however have typically remained invisible in the methods package
>> [you can see them via methods:::cbind or methods:::rbind ]
>> and have been ``activated'' --- replacing base::cbind / rbind ---
>> only via an explicit or implicit call to
>> methods:::bind_activation(TRUE)
>>
>> One reason I didn't dare to make them the default was that I
>> noticed they didn't behave identically to cbind() / rbind() in
>> all cases, though IIRC the rare difference was only in the dimnames
>> returned; further, being entirely written in R, and recursive,
>> they were slower than the mostly C-based fast cbind() / rbind()
>> functions.
>>
>> As some Bioconductor developers have recently found,
>> these versions of cbind() and rbind() that have been
>> automagically activated by loading the Matrix package
>> can have a detrimental effect in some extreme cases,
>> e.g. when using
>> do.call(cbind, list_of_length_1000)
>> because of the recursion and the many many calls to the S4
>> generic, each time searching for method dispatch ...
>> For the bioconductor applications and potentially for others using
cbind() /
>> rbind() extensively, this can lead to unacceptable performance
>> loss just because loading 'Matrix' currently calls
>> methods:::bind_activation(TRUE)
Luke> The recursion part is potentially problematic because stack space
Luke> limitations will cause this to fail for "relatively" short
Luke> list_of_length_1000, but that should be easily curable by rewriting
Luke> methods:::cbind and methods:::rbind to use iteration rather than
Luke> recursion.
Yes, thank you, Luke, something I should have at least tried
doing but didn't get to.
Luke> This might also help a little with efficiency by avoiding
Luke> call overhead. It would be interesting to know how much of the
Luke> performance hit is dispatch overhead and how much closure call
Luke> overhead. If it's dispatch overhead then it may be worth figuring out
Luke> some way of handling this with internal dispatch at the C level (at
Luke> the cost of maintaining the C level stuff).
Luke> My initial reaction to scanning the methods:::cbind code is that it is
Luke> doing too much, at least too much R-level work, but I haven't thought
Luke> it through carefully.
I can well understand that reaction..
The code started up quite small and easily understandable ...
until I started trying to emulate the "standard" cbind() /
rbind() behavior, notably about automatic colnames / rownames
creation. When delving into that the code got the current
partial messyness
>> For this reason, we plan to refrain from doing this activation
>> on loading of Matrix, but propose to
>>
>> 1) define and export
>> cBind <- methods:::cbind
>> rBind <- methods:::cbind
>>
>> also do this for R-2.5.0 so that other useRs / packages
>> can start cBind() / rBind() in their code when they want to
>> have something that can become properly object-oriented
Luke> In mackage methods?
yes, inside methods, such that in fact there cBind <- cbind
(plus namespace export) would be sufficient.
In the mean time I'm less sure if this is desirable;
but at least this would ``expose'' the code and have it used
an
Re: [Rd] [R] can't load just saved R object "ReadItem: unknown type 65"
Luke, I'll be gone for about 2 weeks but will work on getting you a
reproducible example when I get back. If this topic comes up with anyone
else, please copy me on your responses as I may miss it in the 600
emails I'll have to delete on my return :) Mark
Luke Tierney wrote:
> According to the logs nothing at all has changed in the serialization
> code in a month and nothing of consequence for much longer than that.
> To track this down we will need a complete, reproducible, and
> preferably minimal example.
>
> Best,
>
> luke
>
> On Thu, 22 Mar 2007, Mark W Kimpel wrote:
>
>> I have run into a problem loading a just saved R object using R-devel. I
>> have been saving and loading this particular type of R object for a long
>> while and never ran into this problem. I save, then immediately reload
>> (to test save) and get "ReadItem: unnknown type 65".
>>
>> This error is reproducible after logout from server and restart of emacs
>> and R.
>>
>> Below is my output and sessionInfo().
>>
>> Thanks,
>> Mark
>>
>> > setwd("~/Genomics/Experiments.Genomic/BB01/acb.shell")
>> > local(save(affy.object.preprocessed, file
>> ="affy.object.preprocessed.R" ))
>> > load("affy.object.preprocessed.R")
>> Error in load("affy.object.preprocessed.R") :
>> ReadItem: unknown type 65, perhaps written by later version of R
>> > sessionInfo()
>> R version 2.5.0 Under development (unstable) (2007-03-11 r40824)
>> powerpc64-unknown-linux-gnu
>>
>> locale:
>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>>
>>
>>
>> attached base packages:
>> [1] "splines" "stats" "graphics" "grDevices" "datasets" "utils"
>> [7] "tools" "methods" "base"
>>
>> other attached packages:
>> multtestrat2302cdf affycoretools annaffyxtable
>> "1.13.1" "1.15.0" "1.7.8" "1.7.3" "1.4-3"
>> gcrma matchprobes biomaRt RCurl XML
>> "2.7.3" "1.7.4" "1.9.21" "0.8-0" "1.6-0"
>> GOstats CategoryMatrix latticegenefilter
>> "2.1.13" "2.1.20" "0.9975-11" "0.14-16" "1.13.8"
>> survival KEGG RBGL annotateGO
>>"2.31" "1.15.12" "1.11.4" "1.13.6" "1.15.12"
>> graph limma affyaffyio Biobase
>> "1.13.6" "2.9.13" "1.13.14" "1.3.3" "1.13.39"
>>
>
--
Mark W. Kimpel MD
Neuroinformatics
Department of Psychiatry
Indiana University School of Medicine
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.Date nuance
Hi,
I have encountered a nuance in as.Date() behaviour that is not altogether
obvious - not sure whether this is intended or not:
> as.Date("2001-01-01error")
[1] "2001-01-01"
I.e. it ignores the rest of the characters. This happens both in 2.3.1 and
2.4.1 versions.
This also happens with explicit format specification:
> as.Date("2006-01-01error", format="%Y-%m-%d")
[1] "2006-01-01"
thank you
Vladimir Dergachev
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
