Re: [Rd] man page for as.matrix for data frames outdated?
> "Herve" == Herve Pages <[EMAIL PROTECTED]> > on Thu, 02 Nov 2006 20:46:01 -0800 writes: Herve> Hi again, The man page for 'as.matrix' says: >> 'as.matrix' is a generic function. The method >> for data frames will convert any non-numeric/complex >> column into a character vector using 'format' and so >> return a character matrix, except that all-logical >> data frames will be coerced to a logical matrix. In very old versions of R (e.g. 0.3 from March 1996), is.numeric() was TRUE and there the help page was entirely correct. I think if you replace [in the above paragraph] "non-numeric/complex" by "non-(logical/numeric/complex)" the help page is correct again. Herve> If one column is of mode character, then 'as.matrix' Herve> will effectively return a character matrix: (as it says in the man page, and always did in all implementations of the S language) Herve> Note that the doc says that "any non-numeric/complex Herve> column" will be passed thru 'format' which seems to Herve> be exactly the other way around: No! You left off the second part of the statement cited initally. Slightly reformulated: Iff there's any non-(logical/numeric/complex) column, that will have to be passed through format and hence the result must be a character matrix and hence every other column also needs to be "formatted" >> as.matrix(df5) Herve> toto titi 1 "a" " 9" 2 "bb" "999" Herve> Anyway why one would like to have the numeric values Herve> passed thru 'format' to start with? Recall: The result must be a matrix ! If it can't be a numeric matrix the decision was it must be character. BTW: Exactly because of your problems, The function data.matrix() had been devised (long ago in pre-R times), and data.matrix *is* the first entry in "See Also" on the help page for as.matrix Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tip 181 (PR#9335)
Re: tip 181=20 V j MC a I V l emic A g nnounces $9 M A q quisi p tion of Nus m crib v e Which Brings Combined Technology To Change The Educational And M v edica p l Industries! Compan t y : Ve f mi e cs Sy l mb e ol : V h MC b I Status : Ho u t Technology Re c lea m se P t ric k e : $ 0,6 h 0 5 Day T u arge r t: $ 1. u 80 What these two c n ompanie d s do is ama g zi v ng. V a MC f I p n rovi y des technology that allow w s its c c ustomer d s to have completely=20 interactive and l e ive educational and con h fer g encing solutions. In connection with eL t earnin o g De p skt b op they already providing comp q le o tely virtual e s ducationa q l programs and through EP Liv k e Onlin e e they have h e oste w d a live and completely=20 interactive me k dic r al F m orum to the world. N o uScrib d e o l ffer y s to over 600 y ,000 m y edic n al professionals nationwide voice activated m p edic w al record cre k ati k on industry for the spe s ed and e b ffici l ency of m f edi k cal records admi r nist u ration. Combined these two c k ompa s nies are now focused at spac g e age=20 technology and se q rvi y ces that are without equa p l. N g uScrib h e is already tr c adi z ng at $ 0,9 f 0 and V a MC r I is currently tra w din h g at $ 0 x ,60 This news is going out all over the wi u res. Get in befo e re this=20 one goes t s hrough the roo p f! This quick rising s m to u ck is a good l a ong ter q m winne w r. This s z toc e k is going high due to s a uperb b h usines o s=20 solutio o ns. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Formal methods are not loaded from NAMESPACE in reloadedworkspace image
Dear R-Devel subscriber,
as a follow up to my yesterday's email: I tested an analogous example
with the S4-package "flexclust" by executing the following code:
library(flexclust)
example(cclust)
cl
After saving the work space and starting a new R process with the
restored work space, the same behaviour (i.e., the methods pertinent to
"flexclust" are not used, even after executing library(flexclust)).
Yesterday, I executed the code below on a Linux platform with R 2.4.0
and it showed the same behaviour as R 2.5.0dev on Windows. As it seems
right now, the behaviour is platform independent and not peculiar to R
2.5.0dev.
Any pointers and help for solving this problem is much appreciated.
Best,
Bernhard
>Dear R-Devel subscriber,
>
>I was hinted to the following problem with package 'urca':
>
>If one starts R and executes for instance:
>
>> library(urca)
>> example(ur.df)
>## output as expected, but omitted here
>> class(lc.df)
>[1] "ur.df"
>attr(,"package")
>[1] "urca"
>> class(summary(lc.df))
>[1] "sumurca"
>attr(,"package")
>[1] "urca"
>>
>
>everything works fine. Now, save the workspace image and quit R. After
>starting R again with the previously restored workspace image one has:
>
>> ls()
>[1] "lc.df" "Raotbl3"
>> class(lc.df)
>[1] "ur.df"
>attr(,"package")
>[1] "urca"
>
>lc.df
>## now the 'show'-method for objects of class 'ur.df' is not utilised,
>rather the generic
>## displaying all slots
>
>> library(urca)
>> lc.df
>
>## still the same as compared to the above output.
>## similarily
>
>> class(summary(lc.df))
>[1] "table"
>
>
>In the NAMESPACE file export directives for methods and classes are
>included as:
>
>## Classes
>exportClasses("urca", "ca.jo", "cajo.test", "ur.kpss", "ca.po",
>"ur.ers", "ur.pp", "ur.sp", "ur.df", "ur.za", "sumurca")
>## Methods
>exportMethods("show", "plot", "summary")
>
>Any help or pointers for solving this problem is much appreciated.
>
>Best,
>Bernhard
>
>> sessionInfo()
>R version 2.5.0 Under development (unstable) (2006-10-10 r39600)
>i386-pc-mingw32
>
>locale:
>LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_
>MONETARY=
>German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
>
>attached base packages:
>[1] "methods" "stats" "graphics" "grDevices" "datasets" "utils"
>
>[7] "base"
>
>other attached packages:
>urca fortunes
> "1.0-0" "1.3-2"
>*
>Confidentiality Note: The information contained in this
>mess...{{dropped}}
>
>__
>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] Saving images from dialog (PR#9336)
Full_Name: Paolo Sonego
Version: 2.4.0
OS: Windows XP Pro SP2
Submission from: (NULL) (140.105.9.245)
This bug (from the definition in the R FAQ ("If a command does the wrong thing,
that is a bug.") seems to me an inconsistent, but annoying disregard:
plot whatever image you want, e.g.:
hist(rnorm(1000), col = "blue")
When you try saving the image from the window dialog menu: File > Save as >
Png... (PDF..., etc.) in the pop-up dialog appears a 'Save as Type' form with
the Png files (*.png); typing the name of the image file without extension (e.g
image1) will produce a file without automatic png insertion at the end, i.e.,
file name will be image1 vs. image1.png (the 'right' output imho).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] win.metafile() resolution too low (PR#9337)
Full_Name: Peter Kampstra
Version: 2.4.0
OS: Windows
Submission from: (NULL) (130.37.20.20)
Hi,
If you use win.metafile(), "Save as metafile...", or "Copy as metafile" on
Windows, the metafile is rendered at screen resolution. Therefore, the output of
curves like
win.metafile("resolution.emf")
x=seq(1,10,0.001)
y=1/x
plot(x,y,type="l")
dev.off()
does not look smooth. I tracked the problem down to
https://svn.r-project.org/R/trunk/src/gnuwin32/graphapp/metafile.c , to
hDC = CreateEnhMetaFile(NULL, strlen(name) ? name : NULL, &wr,
"GraphApp\0\0");
If NULL is passed as reference HDC to this function, the metafile will be at
screen resolution. If you use such a picture in Word/Powerpoint/etc, it is
visible that curved lines are not smooth...
Therefore, I suggest using a printer as the reference HDC instead. The following
function can be used:
/*
* Creates a HDC to the best printer to be used as a reference for
CreateEnhMetaFile
*/
HDC createbestmetafilehdc() {
DWORD neededsize;
DWORD noprinters;
DWORD printer;
LPPRINTER_INFO_5printerinfo = NULL;
int bestres = 0;
HDC besthdc = 0;
EnumPrinters(PRINTER_ENUM_CONNECTIONS|PRINTER_ENUM_LOCAL, NULL, 5,
NULL, 0,
&neededsize, &noprinters);
printerinfo = (LPPRINTER_INFO_5) malloc(neededsize);
if (EnumPrinters(PRINTER_ENUM_CONNECTIONS|PRINTER_ENUM_LOCAL, NULL, 5,
(LPBYTE)printerinfo, neededsize, &neededsize, &noprinters)) {
//init best resolution for hdc=0, which is screen resolution:
HDC curhdc = GetDC(NULL);
if (curhdc) {
bestres = GetDeviceCaps(curhdc, LOGPIXELSX) +
GetDeviceCaps(curhdc,
LOGPIXELSY);
bestres = ReleaseDC(NULL, curhdc);
}
for (int i = 0; i < noprinters; i++) {
curhdc = CreateDC("WINSPOOL",
printerinfo[i].pPrinterName, NULL, NULL);
if (curhdc) {
int curres = GetDeviceCaps(curhdc, LOGPIXELSX)
+ GetDeviceCaps(curhdc,
LOGPIXELSY);
if (curres > bestres) {
if (besthdc)
DeleteDC(besthdc);
bestres = curres;
besthdc = curhdc;
} else {
DeleteDC(curhdc);
}
}
}
}
free(printerinfo);
return besthdc;
}
This function can be used like:
HDC refhdc=createbestmetafilehdc();
hDC = CreateEnhMetaFile(refhdc, strlen(name) ? name : NULL, &wr,
"GraphApp\0\0");
if (refhdc)
DeleteDC(refhdc);
And cppix,ppix, etc. can be calculated like (this is a workaround for buggy
drivers??):
HDC forhdc=refhdc;
if (!(forhdc))
forhdc=GetDC(NULL);
cppix = 25.40 * GetDeviceCaps(forhdc,HORZRES) /
GetDeviceCaps(forhdc,HORZSIZE);
ppix = 100 * GetDeviceCaps(forhdc, LOGPIXELSX);
cppiy = 25.40 * GetDeviceCaps(forhdc, VERTRES) / GetDeviceCaps(forhdc,
VERTSIZE);
ppiy = 100 * GetDeviceCaps(forhdc, LOGPIXELSY);
if (!(refhdc))
ReleaseDC(NULL,forhdc);
And probably some other changes will be necessary...
Keep up the good work,
Peter Kampstra
[EMAIL PROTECTED] / http://peter.kampstra.net
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] WG: Formal methods are not loaded from NAMESPACE inreloadedworkspace image
Sorry, to bother the list one more time: but the following worked at
least for 'urca':
in NAMESPACE I now included explicitly:
import(methods)
a fix of the 'urca'-package will be uploaded to CRAN on the weekend.
Fritz, will this work for ypur package 'flexclust' too? I have in my
DESCRIPTION imports: methods and in flexclust it is in depends: methods.
However, both packages have not import(methods) in their NAMESPACE.
Anyway, I wonder why 'import(methods)' is explicitly needed in
NAMESPACE? Would a smart and bright soul be so kind and enlighten a
flabbergasted one? :-) Many thanks!
Best,
Bernhard
>Dear R-Devel subscriber,
>
>as a follow up to my yesterday's email: I tested an analogous example
>with the S4-package "flexclust" by executing the following code:
>
>library(flexclust)
>example(cclust)
>cl
>
>After saving the work space and starting a new R process with the
>restored work space, the same behaviour (i.e., the methods pertinent to
>"flexclust" are not used, even after executing library(flexclust)).
>Yesterday, I executed the code below on a Linux platform with R 2.4.0
>and it showed the same behaviour as R 2.5.0dev on Windows. As it seems
>right now, the behaviour is platform independent and not peculiar to R
>2.5.0dev.
>
>Any pointers and help for solving this problem is much appreciated.
>
>Best,
>Bernhard
>
>>Dear R-Devel subscriber,
>>
>>I was hinted to the following problem with package 'urca':
>>
>>If one starts R and executes for instance:
>>
>>> library(urca)
>>> example(ur.df)
>>## output as expected, but omitted here
>>> class(lc.df)
>>[1] "ur.df"
>>attr(,"package")
>>[1] "urca"
>>> class(summary(lc.df))
>>[1] "sumurca"
>>attr(,"package")
>>[1] "urca"
>>>
>>
>>everything works fine. Now, save the workspace image and quit R. After
>>starting R again with the previously restored workspace image one has:
>>
>>> ls()
>>[1] "lc.df" "Raotbl3"
>>> class(lc.df)
>>[1] "ur.df"
>>attr(,"package")
>>[1] "urca"
>>
>>lc.df
>>## now the 'show'-method for objects of class 'ur.df' is not utilised,
>>rather the generic
>>## displaying all slots
>>
>>> library(urca)
>>> lc.df
>>
>>## still the same as compared to the above output.
>>## similarily
>>
>>> class(summary(lc.df))
>>[1] "table"
>>
>>
>>In the NAMESPACE file export directives for methods and classes are
>>included as:
>>
>>## Classes
>>exportClasses("urca", "ca.jo", "cajo.test", "ur.kpss", "ca.po",
>>"ur.ers", "ur.pp", "ur.sp", "ur.df", "ur.za", "sumurca")
>>## Methods
>>exportMethods("show", "plot", "summary")
>>
>>Any help or pointers for solving this problem is much appreciated.
>>
>>Best,
>>Bernhard
>>
>>> sessionInfo()
>>R version 2.5.0 Under development (unstable) (2006-10-10 r39600)
>>i386-pc-mingw32
>>
>>locale:
>>LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_
>>MONETARY=
>>German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
>>
>>attached base packages:
>>[1] "methods" "stats" "graphics" "grDevices"
>"datasets" "utils"
>>
>>[7] "base"
>>
>>other attached packages:
>>urca fortunes
>> "1.0-0" "1.3-2"
>>*
>>Confidentiality Note: The information contained in this
>>mess...{{dropped}}
>>
>>__
>>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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Formal methods are not loaded from NAMESPACE in reloadedworkspace image
I haven't had a chance to verify these exact examples, but the likely
explanation is that loading the workspace does not cache the saved
methods. Assuming this is indeed what's happening, the workaround is to
cache them "manually" by the call:
cacheMetaData(.GlobalEnv)
(after attaching the relevant library)
It would be nice to have the same effect occur automatically, but there
may be issues since the needed class definitions may not be available
when the saved workspace is reloaded.
A natural question to ask is whether there is some practical motivation
for this exercise.
Pfaff, Bernhard Dr. wrote:
> Dear R-Devel subscriber,
>
> as a follow up to my yesterday's email: I tested an analogous example
> with the S4-package "flexclust" by executing the following code:
>
> library(flexclust)
> example(cclust)
> cl
>
> After saving the work space and starting a new R process with the
> restored work space, the same behaviour (i.e., the methods pertinent to
> "flexclust" are not used, even after executing library(flexclust)).
> Yesterday, I executed the code below on a Linux platform with R 2.4.0
> and it showed the same behaviour as R 2.5.0dev on Windows. As it seems
> right now, the behaviour is platform independent and not peculiar to R
> 2.5.0dev.
>
> Any pointers and help for solving this problem is much appreciated.
>
> Best,
> Bernhard
>
>
>> Dear R-Devel subscriber,
>>
>> I was hinted to the following problem with package 'urca':
>>
>> If one starts R and executes for instance:
>>
>>
>>> library(urca)
>>> example(ur.df)
>>>
>> ## output as expected, but omitted here
>>
>>> class(lc.df)
>>>
>> [1] "ur.df"
>> attr(,"package")
>> [1] "urca"
>>
>>> class(summary(lc.df))
>>>
>> [1] "sumurca"
>> attr(,"package")
>> [1] "urca"
>>
>> everything works fine. Now, save the workspace image and quit R. After
>> starting R again with the previously restored workspace image one has:
>>
>>
>>> ls()
>>>
>> [1] "lc.df" "Raotbl3"
>>
>>> class(lc.df)
>>>
>> [1] "ur.df"
>> attr(,"package")
>> [1] "urca"
>>
>> lc.df
>> ## now the 'show'-method for objects of class 'ur.df' is not utilised,
>> rather the generic
>> ## displaying all slots
>>
>>
>>> library(urca)
>>> lc.df
>>>
>> ## still the same as compared to the above output.
>> ## similarily
>>
>>
>>> class(summary(lc.df))
>>>
>> [1] "table"
>>
>>
>> In the NAMESPACE file export directives for methods and classes are
>> included as:
>>
>> ## Classes
>> exportClasses("urca", "ca.jo", "cajo.test", "ur.kpss", "ca.po",
>> "ur.ers", "ur.pp", "ur.sp", "ur.df", "ur.za", "sumurca")
>> ## Methods
>> exportMethods("show", "plot", "summary")
>>
>> Any help or pointers for solving this problem is much appreciated.
>>
>> Best,
>> Bernhard
>>
>>
>>> sessionInfo()
>>>
>> R version 2.5.0 Under development (unstable) (2006-10-10 r39600)
>> i386-pc-mingw32
>>
>> locale:
>> LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_
>> MONETARY=
>> German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
>>
>> attached base packages:
>> [1] "methods" "stats" "graphics" "grDevices" "datasets" "utils"
>>
>> [7] "base"
>>
>> other attached packages:
>>urca fortunes
>> "1.0-0" "1.3-2"
>> *
>> Confidentiality Note: The information contained in this
>> mess...{{dropped}}
>>
>> __
>> 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
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] difference in using with() and the "data" argument in glm (PR#9338)
I've redirected this reply from r-help to the bugs list.
On 11/3/2006 8:25 AM, vito muggeo wrote:
> Dear all,
> I am dealing with the following (apparently simple problem):
> For some reasons I am interested in passing variables from a dataframe
> to a specific environment, and in fitting a standard glm:
>
> dati<-data.frame(y=rnorm(10),x1=runif(10),x2=runif(10))
> KK<-new.env()
> for(i in 1:ncol(dati)) assign(names(dati[i]),dati[[i]],envir=KK)
> #Now the following two lines work correctly:
> coef(glm(y~x1+x2,data=KK))
> with(KK,coef(glm(y~x1+x2)))
>
> #However if I write the above code inside a function, with() does not
> appear to work..
>
> ff<-function(Formula,Data,method=1){
> KK<-new.env()
> for(i in 1:ncol(Data)) assign(names(Data[i]),Data[[i]],envir=KK)
> o<-if(method==1) glm(Formula,data=KK) else with(KK,glm(Formula))
> o}
>
> > ff(y~x1+x2,dati,1) #it works
> Call: glm(formula = Formula, data = KK)
> ..[SNIP]..
> > ff(y~x1+x2,dati,2) #it does not
> Error in eval(expr, envir, enclos) : object "y" not found
> >
>
> Could anyone to explain such difference? I believed that
> "with(data,glm(formula))" and "glm(formula,data)" were equivalent.
I think this is a bug in terms.formula. Near the end it has
environment(terms) <- environment(x)
where x is the formula. Since "y" isn't defined in that environment, it
fails. It would work for you with
environment(terms) <- data
but see below.
A workaround that should work for you is to put
environment(Formula) <- KK
before the call to glm.
I'm not going to make the patch I suggest above, because I don't think
it's consistent with the expected behaviour of glm() in the case where
some of the terms in the formula are supposed to come from
environment(x), and some from "data".
I don't know how to handle that case properly: I think it requires a
different search strategy than R employs (but I might be wrong). This
isn't a problem with the workaround I suggested to you, because there
the parent of KK is environment(x), but that wouldn't be true in general.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] WG: Formal methods are not loaded from NAMESPACE inreloadedworkspace image
"Pfaff, Bernhard Dr." <[EMAIL PROTECTED]> writes: > Sorry, to bother the list one more time: but the following worked at > least for 'urca': > > in NAMESPACE I now included explicitly: > > import(methods) > > a fix of the 'urca'-package will be uploaded to CRAN on the weekend. > Fritz, will this work for ypur package 'flexclust' too? I have in my > DESCRIPTION imports: methods and in flexclust it is in depends: methods. > However, both packages have not import(methods) in their NAMESPACE. > Anyway, I wonder why 'import(methods)' is explicitly needed in > NAMESPACE? Would a smart and bright soul be so kind and enlighten a > flabbergasted one? :-) Many thanks! Because 4 > 1. I share your flabbergasted state. As I understand it, if you want to use methods, you might need to: 1. Say so in .onLoad where you require(methods) 2. Certainly Depends: methods 3. As you found, in the NAMESPACE file it helps to import(methods) 4. But then you also need to Import: methods + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Formal methods are not loaded from NAMESPACE in reloadedworkspace image
John Chambers <[EMAIL PROTECTED]> writes: > I haven't had a chance to verify these exact examples, but the likely > explanation is that loading the workspace does not cache the saved > methods. Assuming this is indeed what's happening, the workaround is to > cache them "manually" by the call: > > cacheMetaData(.GlobalEnv) > > (after attaching the relevant library) > > It would be nice to have the same effect occur automatically, but there > may be issues since the needed class definitions may not be available > when the saved workspace is reloaded. > > A natural question to ask is whether there is some practical motivation > for this exercise. The main use case is that since serialization of objects is such an R-ish thing to do, you really want to have deserialized S4 instances "work" properly when loaded. I admit that it is also useful to be able to load an arbitrary object and inspect it even if it will be "broken" (without this, it would be very hard to write any sort of automated class update code). It would seem that this behavior could be achieved in a force=TRUE mode and that otherwise, it would be an error to deserialize an S4 instance when the class def is not available. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] WG: Formal methods are not loaded from NAMESPACE inreloadedworkspace image
Well, at the moment I'm a little confused too. It's not at all as
simple as my previous mail suggested.
Here's what I know, and unfortunately I won't have too much time to look
further for a while.
Starting from a clean folder (no saved workspace):
> library(urca)
> showMethods("summary")
Function: summary (package base)
object="ANY"
object="ca.jo"
object="ca.po"
object="cajo.test"
object="ur.df"
object="ur.ers"
object="ur.kpss"
object="ur.pp"
object="ur.sp"
object="ur.za"
so you do get the methods desired.
But after example(ur.df), quit and save the workspace, then restart R:
> library(urca)
> showMethods("summary")
Function "summary":
The effect does depend on something related to the example()
calculation; just saving an arbitrary object in the workspace won't
produce the bug.
I'll look into the effect of having an explicit import(methods) when I
get a chance, but it's not clear why that is connected to running the
example.
(Now the question is interesting enough that I won't give you a hard
time about the practical motivation!)
Pfaff, Bernhard Dr. wrote:
> Sorry, to bother the list one more time: but the following worked at
> least for 'urca':
>
> in NAMESPACE I now included explicitly:
>
> import(methods)
>
> a fix of the 'urca'-package will be uploaded to CRAN on the weekend.
> Fritz, will this work for ypur package 'flexclust' too? I have in my
> DESCRIPTION imports: methods and in flexclust it is in depends: methods.
> However, both packages have not import(methods) in their NAMESPACE.
> Anyway, I wonder why 'import(methods)' is explicitly needed in
> NAMESPACE? Would a smart and bright soul be so kind and enlighten a
> flabbergasted one? :-) Many thanks!
>
> Best,
> Bernhard
>
>
>> Dear R-Devel subscriber,
>>
>> as a follow up to my yesterday's email: I tested an analogous example
>> with the S4-package "flexclust" by executing the following code:
>>
>> library(flexclust)
>> example(cclust)
>> cl
>>
>> After saving the work space and starting a new R process with the
>> restored work space, the same behaviour (i.e., the methods pertinent to
>> "flexclust" are not used, even after executing library(flexclust)).
>> Yesterday, I executed the code below on a Linux platform with R 2.4.0
>> and it showed the same behaviour as R 2.5.0dev on Windows. As it seems
>> right now, the behaviour is platform independent and not peculiar to R
>> 2.5.0dev.
>>
>> Any pointers and help for solving this problem is much appreciated.
>>
>> Best,
>> Bernhard
>>
>>
>>> Dear R-Devel subscriber,
>>>
>>> I was hinted to the following problem with package 'urca':
>>>
>>> If one starts R and executes for instance:
>>>
>>>
library(urca)
example(ur.df)
>>> ## output as expected, but omitted here
>>>
class(lc.df)
>>> [1] "ur.df"
>>> attr(,"package")
>>> [1] "urca"
>>>
class(summary(lc.df))
>>> [1] "sumurca"
>>> attr(,"package")
>>> [1] "urca"
>>>
>>> everything works fine. Now, save the workspace image and quit R. After
>>> starting R again with the previously restored workspace image one has:
>>>
>>>
ls()
>>> [1] "lc.df" "Raotbl3"
>>>
class(lc.df)
>>> [1] "ur.df"
>>> attr(,"package")
>>> [1] "urca"
>>>
>>> lc.df
>>> ## now the 'show'-method for objects of class 'ur.df' is not utilised,
>>> rather the generic
>>> ## displaying all slots
>>>
>>>
library(urca)
lc.df
>>> ## still the same as compared to the above output.
>>> ## similarily
>>>
>>>
class(summary(lc.df))
>>> [1] "table"
>>>
>>>
>>> In the NAMESPACE file export directives for methods and classes are
>>> included as:
>>>
>>> ## Classes
>>> exportClasses("urca", "ca.jo", "cajo.test", "ur.kpss", "ca.po",
>>> "ur.ers", "ur.pp", "ur.sp", "ur.df", "ur.za", "sumurca")
>>> ## Methods
>>> exportMethods("show", "plot", "summary")
>>>
>>> Any help or pointers for solving this problem is much appreciated.
>>>
>>> Best,
>>> Bernhard
>>>
>>>
sessionInfo()
>>> R version 2.5.0 Under development (unstable) (2006-10-10 r39600)
>>> i386-pc-mingw32
>>>
>>> locale:
>>> LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_
>>> MONETARY=
>>> German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
>>>
>>> attached base packages:
>>> [1] "methods" "stats" "graphics" "grDevices"
>>>
>> "datasets" "utils"
>>
>>> [7] "base"
>>>
>>> other attached packages:
>>>urca fortunes
>>> "1.0-0" "1.3-2"
>>> *
>>> Confidentiality Note: The information contained in this
>>> mess...{{dropped}}
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>> __
>> R-devel@r-project.org mailin
[Rd] data.entry(), de() fail in FC6-x86_64
Buffer overflow detect in FC6-x86_64, see down.
Juan.
R version 2.4.0 (2006-10-03)
Copyright (C) 2006 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R é um software livre e vem sem GARANTIA ALGUMA.
Você pode redistribuí-lo sob certas circunstâncias.
Digite 'license()' ou 'licence()' para detalhes de distribuição.
R é um projeto colaborativo com muitos contribuidores.
Digite 'contributors()' para obter mais informações e
'citation()' para saber como citar o R ou pacotes do R em publicações.
Digite 'demo()' para demonstrações, 'help()' para o sistema on-line de
ajuda,
ou 'help.start()' para abrir o sistema de ajuda em HTML no seu
navegador.
Digite 'q()' para sair do R.
Loading Tcl/Tk interface ... done
[Área de trabalho anterior carregada]
> if(!exists("baseenv", mode="function")) baseenv <- function() NULL
options(STERM='iESS', editor='emacsclient')
> >
>
> c <- c(1,2,3,4)
> de(c)
*** buffer overflow detected ***: /usr/lib64/R/bin/exec/R terminated
=== Backtrace: =
/lib64/libc.so.6(__chk_fail+0x2f)[0x3d416e0dff]
/lib64/libc.so.6[0x3d416e2387]
/usr/lib64/R/modules//R_X11.so[0x2f413a3f]
/usr/lib64/R/modules//R_X11.so[0x2f415215]
/usr/lib64/R/modules//R_X11.so[0x2f41634f]
/usr/lib64/R/modules//R_X11.so(RX11_dataentry+0x8db)[0x2f41781b]
/usr/lib64/R/lib/libR.so[0x352b4dd873]
/usr/lib64/R/lib/libR.so(Rf_eval+0x452)[0x352b4b0b22]
/usr/lib64/R/lib/libR.so[0x352b4b17b2]
/usr/lib64/R/lib/libR.so(Rf_eval+0x452)[0x352b4b0b22]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x286)[0x352b4b2c16]
/usr/lib64/R/lib/libR.so(Rf_eval+0x2fc)[0x352b4b09cc]
/usr/lib64/R/lib/libR.so[0x352b4b4990]
/usr/lib64/R/lib/libR.so(Rf_eval+0x452)[0x352b4b0b22]
/usr/lib64/R/lib/libR.so[0x352b4b17b2]
/usr/lib64/R/lib/libR.so(Rf_eval+0x452)[0x352b4b0b22]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x286)[0x352b4b2c16]
/usr/lib64/R/lib/libR.so(Rf_eval+0x2fc)[0x352b4b09cc]
/usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x2e9)[0x352b4cef99]
/usr/lib64/R/lib/libR.so[0x352b4cf130]
/usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x352b4cf460]
/usr/lib64/R/bin/exec/R(main+0x1d)[0x4007ed]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3d4161da44]
/usr/lib64/R/bin/exec/R[0x400709]
=== Memory map:
0040-00401000 r-xp 16:42
842969 /usr/lib64/R/bin/exec/R
0060-00602000 rw-p 16:42
842969 /usr/lib64/R/bin/exec/R
00602000-01f0c000 rw-p 00602000 00:00 0
[heap]
4000-40001000 ---p 4000 00:00 0
40001000-40a01000 rw-p 40001000 00:00 0
352ac0-352ac96000 r-xp 16:42
2331260/usr/lib64/libgfortran.so.1.0.0
352ac96000-352ae95000 ---p 00096000 16:42
2331260/usr/lib64/libgfortran.so.1.0.0
352ae95000-352ae97000 rw-p 00095000 16:42
2331260/usr/lib64/libgfortran.so.1.0.0
352b00-352b02c000 r-xp 16:42
842967 /usr/lib64/R/lib/libRblas.so
352b02c000-352b22b000 ---p 0002c000 16:42
842967 /usr/lib64/R/lib/libRblas.so
352b22b000-352b22c000 rw-p 0002b000 16:42
842967 /usr/lib64/R/lib/libRblas.so
352b40-352b621000 r-xp 16:42
844808 /usr/lib64/R/lib/libR.so
352b621000-352b821000 ---p 00221000 16:42
844808 /usr/lib64/R/lib/libR.so
352b821000-352b835000 rw-p 00221000 16:42
844808 /usr/lib64/R/lib/libR.so
352b835000-352b8ce000 rw-p 352b835000 00:00 0
352d60-352d65b000 r-xp 16:42
2331672/usr/lib64/libXt.so.6.0.0
352d65b000-352d85a000 ---p 0005b000 16:42
2331672/usr/lib64/libXt.so.6.0.0
352d85a000-352d86 rw-p 0005a000 16:42
2331672/usr/lib64/libXt.so.6.0.0
352d86-352d861000 rw-p 352d86 00:00 0
352fe0-352fe1b000 r-xp 16:42
779639 /lib64/libpcre.so.0.0.1
352fe1b000-353001b000 ---p 0001b000 16:42
779639 /lib64/libpcre.so.0.0.1
353001b000-353001c000 rw-p 0001b000 16:42
779639 /lib64/libpcre.so.0.0.1
3d4060-3d4061a000 r-xp 16:42
779764 /lib64/ld-2.5.so
3d40819000-3d4081a000 r--p 00019000 16:42
779764 /lib64/ld-2.5.so
3d4081a000-3d4081b000 rw-p 0001a000 16:42
779764 /lib64/ld-2.5.so
3d4120-3d41235000 r-xp 16:42
2306537/usr/lib64/libreadline.so.5.1
3d41235000-3d41434000 ---p 00035000 16:42
2306537/usr/lib64/libreadline.so.5.1
3d41434000-3d4143c000 rw-p 00034000 16:42
2306537/usr/lib64/libreadline.so.5.1
3d4143c000-3d4143d000 rw-p 3d4143c000 00:00 0
3d4160-3d41744000 r-xp 16:42
779765 /lib64/libc-2.5.so
3d41744000-3d41944000 ---p 00144000 16:42
779765 /lib64/libc-2.5.so
3d41944000-3d4194
Process R abortado
Re: [Rd] data.entry(), de() fail in FC6-x86_64
Juan Santiago Ramseyer <[EMAIL PROTECTED]> writes:
> Buffer overflow detect in FC6-x86_64, see down.
>
> Juan.
Yes, this has been reported before and is fixed in R-patched. A
workaround is not to use an UTF8 based locale. Someone might file a
bug report against FC6 so that they might possibly decide to update
the RPM with the relevant patch. Otherwise, build the patched version
or wait for 2.4.1.
> Loading Tcl/Tk interface ... done
> [Área de trabalho anterior carregada]
>
> > if(!exists("baseenv", mode="function")) baseenv <- function() NULL
> options(STERM='iESS', editor='emacsclient')
> > >
> >
> > c <- c(1,2,3,4)
> > de(c)
> *** buffer overflow detected ***: /usr/lib64/R/bin/exec/R terminated
Or, fix(airquality) suffices to reproduce this.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Formal methods are not loaded from NAMESPACE in reloadedworkspace image
It's not a simple serialization issue, but related to the initial
computations when a saved image is reloaded at the start of a session,
so the implication is less general than you imply.
If you move the saved image to another file, say "savedImage", then:
> load("savedImage")
> library(urca)
> showMethods("summary")
Function: summary (package base)
object="ANY"
object="ca.jo"
object="ca.po"
object="cajo.test"
object="ur.df"
object="ur.ers"
object="ur.kpss"
object="ur.pp"
object="ur.sp"
object="ur.za"
and summary(lc.df) then works as expected.
So the workaround, other than inserting all the import(methods), etc.
you can think of, seems to be to save/load explicitly.
Seth Falcon wrote:
> John Chambers <[EMAIL PROTECTED]> writes:
>
>
>> I haven't had a chance to verify these exact examples, but the likely
>> explanation is that loading the workspace does not cache the saved
>> methods. Assuming this is indeed what's happening, the workaround is to
>> cache them "manually" by the call:
>>
>> cacheMetaData(.GlobalEnv)
>>
>> (after attaching the relevant library)
>>
>> It would be nice to have the same effect occur automatically, but there
>> may be issues since the needed class definitions may not be available
>> when the saved workspace is reloaded.
>>
>> A natural question to ask is whether there is some practical motivation
>> for this exercise.
>>
>
> The main use case is that since serialization of objects is such an
> R-ish thing to do, you really want to have deserialized S4 instances
> "work" properly when loaded.
>
> I admit that it is also useful to be able to load an arbitrary object
> and inspect it even if it will be "broken" (without this, it would be
> very hard to write any sort of automated class update code). It would
> seem that this behavior could be achieved in a force=TRUE mode and
> that otherwise, it would be an error to deserialize an S4 instance
> when the class def is not available.
>
> + seth
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] difference in using with() and the "data" argument in glm (PR#9338)
One thing I noticed is that ?glm does not really specify what happens
if you do not give a value for data. Is data then just skipped so that search
takes place in enivonrment(formula) only or is it supposed to default to
something? Some clarification in ?glm would be helpful.
On 11/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I've redirected this reply from r-help to the bugs list.
>
> On 11/3/2006 8:25 AM, vito muggeo wrote:
> > Dear all,
> > I am dealing with the following (apparently simple problem):
> > For some reasons I am interested in passing variables from a dataframe
> > to a specific environment, and in fitting a standard glm:
> >
> > dati<-data.frame(y=rnorm(10),x1=runif(10),x2=runif(10))
> > KK<-new.env()
> > for(i in 1:ncol(dati)) assign(names(dati[i]),dati[[i]],envir=KK)
> > #Now the following two lines work correctly:
> > coef(glm(y~x1+x2,data=KK))
> > with(KK,coef(glm(y~x1+x2)))
> >
> > #However if I write the above code inside a function, with() does not
> > appear to work..
> >
> > ff<-function(Formula,Data,method=1){
> > KK<-new.env()
> > for(i in 1:ncol(Data)) assign(names(Data[i]),Data[[i]],envir=KK)
> > o<-if(method==1) glm(Formula,data=KK) else with(KK,glm(Formula))
> > o}
> >
> > > ff(y~x1+x2,dati,1) #it works
> > Call: glm(formula = Formula, data = KK)
> > ..[SNIP]..
> > > ff(y~x1+x2,dati,2) #it does not
> > Error in eval(expr, envir, enclos) : object "y" not found
> > >
> >
> > Could anyone to explain such difference? I believed that
> > "with(data,glm(formula))" and "glm(formula,data)" were equivalent.
>
> I think this is a bug in terms.formula. Near the end it has
>
> environment(terms) <- environment(x)
>
> where x is the formula. Since "y" isn't defined in that environment, it
> fails. It would work for you with
>
> environment(terms) <- data
>
> but see below.
>
> A workaround that should work for you is to put
>
> environment(Formula) <- KK
>
> before the call to glm.
>
> I'm not going to make the patch I suggest above, because I don't think
> it's consistent with the expected behaviour of glm() in the case where
> some of the terms in the formula are supposed to come from
> environment(x), and some from "data".
>
> I don't know how to handle that case properly: I think it requires a
> different search strategy than R employs (but I might be wrong). This
> isn't a problem with the workaround I suggested to you, because there
> the parent of KK is environment(x), but that wouldn't be true in general.
>
> Duncan Murdoch
>
> __
> 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] Formal methods are not loaded from NAMESPACE in reloadedworkspace image
Dear John, Dear Seth,
many (a thousands) thanks for your clarification and highlighting of the
problem.
>It's not a simple serialization issue, but related to the initial
>computations when a saved image is reloaded at the start of a session,
>so the implication is less general than you imply.
Hm, yes, that seems to be true. I do not know what the R-wizard Prof.
Douglas Bates has done, but going through the same exercise with:
library(lme4)
example(lmer)
saving the work space (without moving it to another file), quitting R
and starting such that the previously work space is restored, will yield
the following:
> ls()
[1] "fm1" "fm2"
> showMethods("summary")
Function "summary":
> fm1
Loading required package: lme4
Loading required package: Matrix
Loading required package: lattice
## output as expected, but omitted here
Well, John, referring to your question. IMHO it is a question how useRs
work with R. Personnaly, I almost never work with work spaces but rather
scripts: write it - like it or fudge it. Anyway, a useR has pointed me
to this behaviour and I reckon that he uses the 'save work
space'-approach for an E-lab class that he teaches.
Aside, of this issue and something more for R-Core, I am wondering if
some hint/pointer should be placed in the R-ext document (maybe in the
section 'Package name spaces' and/or in the subsection 'The DESCRIPTION
file'). I have re-read it, but could not find a hint with respect to
'methods' and 'S4'.
Let me thank you once more for your time taken, patience devoted and
enlightenment given to this problem. I must confess, that 'serialization
of R objects' is beyond the scope of my computer literacy as an
economist.
Gratefully,
Bernhard
>
>If you move the saved image to another file, say "savedImage", then:
>
> > load("savedImage")
> > library(urca)
> > showMethods("summary")
>Function: summary (package base)
>object="ANY"
>object="ca.jo"
>object="ca.po"
>object="cajo.test"
>object="ur.df"
>object="ur.ers"
>object="ur.kpss"
>object="ur.pp"
>object="ur.sp"
>object="ur.za"
>
>and summary(lc.df) then works as expected.
>
>So the workaround, other than inserting all the import(methods), etc.
>you can think of, seems to be to save/load explicitly.
>
>Seth Falcon wrote:
>> John Chambers <[EMAIL PROTECTED]> writes:
>>
>>
>>> I haven't had a chance to verify these exact examples, but
>the likely
>>> explanation is that loading the workspace does not cache the saved
>>> methods. Assuming this is indeed what's happening, the
>workaround is to
>>> cache them "manually" by the call:
>>>
>>> cacheMetaData(.GlobalEnv)
>>>
>>> (after attaching the relevant library)
>>>
>>> It would be nice to have the same effect occur
>automatically, but there
>>> may be issues since the needed class definitions may not be
>available
>>> when the saved workspace is reloaded.
>>>
>>> A natural question to ask is whether there is some
>practical motivation
>>> for this exercise.
>>>
>>
>> The main use case is that since serialization of objects is such an
>> R-ish thing to do, you really want to have deserialized S4 instances
>> "work" properly when loaded.
>>
>> I admit that it is also useful to be able to load an arbitrary object
>> and inspect it even if it will be "broken" (without this, it would be
>> very hard to write any sort of automated class update code).
> It would
>> seem that this behavior could be achieved in a force=TRUE mode and
>> that otherwise, it would be an error to deserialize an S4 instance
>> when the class def is not available.
>>
>> + seth
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> [[alternative HTML version deleted]]
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
*
Confidentiality Note: The information contained in this mess...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] man page for as.matrix for data frames outdated?
Hi Martin,
Thanks for the answer!
OK I can use data.matrix to convert a data frame to a numeric
matrix but that's another story. Basically I'm reporting 2
problems with 'as.matrix' when applied to a data frame:
1) A documentation problem:
"The method for data frames will convert any
non-numeric/complex column into a character vector
using 'format'"
> df5 <- data.frame(toto=c("a","bb"), titi=c(9,999))
> as.matrix(df5)
toto titi
1 "a" " 9"
2 "bb" "999"
As I said, it seems to be the other way around: it's not the
"non-numeric" column that is converted to a character vector,
it's the "numeric" column.
2) the questionable decision to do this conversion using 'format'
(leading to the addition of unnecessary white space) and not
simply 'as.character'
BTW your mailer seems to do some strange reformatting to the output
of my code snippets making it hard to see the "formatting" problem
that I'm trying to show.
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eval(match.call()) (PR#9339)
Full_Name: Justin Harrington Version: 2.4.0 OS: Fedora Core 6 Submission from: (NULL) (142.103.121.203) When I type the (albeit stupid) command eval(match.call()) R crashes with the following messages (truncated): *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated The complete output is available at http://md.stat.ubc.ca/Routput.txt For reference, here are the results from version: platform i686-redhat-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 2 minor 4.0 year 2006 month 10 day03 svn rev39566 language R version.string R version 2.4.0 (2006-10-03) and my version of R was installed using yum from the fedora repositories. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] man page for as.matrix for data frames outdated?
On Fri, 3 Nov 2006, Herve Pages wrote:
> > df5 <- data.frame(toto=c("a","bb"), titi=c(9,999))
> > as.matrix(df5)
> toto titi
> 1 "a" " 9"
> 2 "bb" "999"
> ...
> 2) the questionable decision to do this conversion using 'format'
>(leading to the addition of unnecessary white space) and not
>simply 'as.character'
It is possible that this decision was made because one use of
as.matrix(mixed-mode-data-frame) was for printing data.frames and
format(numberic-column) would line up the decimal points and
make one scientific-notation/or-not decision for the entire column.
(Splus3.4, c. 1996, printed data.frames with print(as.matrix(x)),
but by 1999 Splus4.7 was using print(format(x)).)
R> df6<- data.frame(toto=c("a","bb","ccc"), titi=c(.9e-20,.9,999.9))
R> as.matrix(df6)
toto titi
1 "a" "9.e-21"
2 "bb" "9.e-01"
3 "ccc" "9.9990e+02"
R> df7<-data.frame(toto=c("a","bb","ccc"), titi=c(.9,.9,999.9))
R> as.matrix(df7)
toto titi
1 "a" " 0.9"
2 "bb" " 0.9"
3 "ccc" "999.9"
Once such a decision is made it is hard to change things, especially
when the benefit is slight.
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 20:49 +0100, [EMAIL PROTECTED] wrote: > Full_Name: Justin Harrington > Version: 2.4.0 > OS: Fedora Core 6 > Submission from: (NULL) (142.103.121.203) > > > When I type the (albeit stupid) command > > eval(match.call()) > > R crashes with the following messages (truncated): > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > The complete output is available at http://md.stat.ubc.ca/Routput.txt > > For reference, here are the results from version: > > platform i686-redhat-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 4.0 > year 2006 > month 10 > day03 > svn rev39566 > language R > version.string R version 2.4.0 (2006-10-03) > > and my version of R was installed using yum from the fedora repositories. Hmmm I cannot replicate this using: R version 2.4.0 Patched (2006-10-03 r39576) on FC5: > eval(match.call()) Error in match.call(definition, call, expand.dots) : '.Primitive...' is not a function I'm not running "Zod" yet, but: 1. There have been LOTS of updates to FC6 since release from watching the FC lists. I would be sure that your system is fully updated. 2. You might want to see if compiling and installing 2.4.0 patched from CRAN resolves this behavior at all, though I do not see anything readily evident in the NEWS file to suggest that any fixes are relevant here. 3. If neither of those do anything, it would be worthwhile to file a bug report at RH's Bugzilla against R to see if there is something unique in the version that they are creating in Fedora Extras. Tom Callaway, RH's maintainer for R, does read r-devel, so he may pipe in here also. I have cc'd him on this reply. >From the BT you provided, this looks like it could be a libreadline issue perhaps. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
[EMAIL PROTECTED] writes: > Full_Name: Justin Harrington > Version: 2.4.0 > OS: Fedora Core 6 > Submission from: (NULL) (142.103.121.203) > > > When I type the (albeit stupid) command > > eval(match.call()) > > R crashes with the following messages (truncated): > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated Yes, don't do that then ;-) Part of the puzzle is that > match.call() match.call() which looks like something with potential for infinite recursion, but that doesn't seem to be issue since > f <- function(call = sys.call(sys.parent()))call > f() f() > eval(f()) f() does not exhibit the same crash. And indeed > x <- quote(match.call()) > eval(x) *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated === Backtrace: = /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] /lib/libc.so.6[0x1f0617] does look like something that just Should Not Happen... > The complete output is available at http://md.stat.ubc.ca/Routput.txt > > For reference, here are the results from version: > > platform i686-redhat-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 4.0 > year 2006 > month 10 > day03 > svn rev39566 > language R > version.string R version 2.4.0 (2006-10-03) > > and my version of R was installed using yum from the fedora repositories. Ah, thanks. Sufficient information for once... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: > > > Full_Name: Justin Harrington > > Version: 2.4.0 > > OS: Fedora Core 6 > > Submission from: (NULL) (142.103.121.203) > > > > > > When I type the (albeit stupid) command > > > > eval(match.call()) > > > > R crashes with the following messages (truncated): > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > Yes, don't do that then ;-) Indeed... ;-) > Part of the puzzle is that > > > match.call() > match.call() > > which looks like something with potential for infinite recursion, but > that doesn't seem to be issue since > > > f <- function(call = sys.call(sys.parent()))call > > f() > f() > > eval(f()) > f() > > does not exhibit the same crash. And indeed > > > x <- quote(match.call()) > > eval(x) > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > === Backtrace: = > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > /lib/libc.so.6[0x1f0617] > > does look like something that just Should Not Happen... Peter, are you on FC6? On FC5, I cannot replicate your crash: > x <- quote(match.call()) > eval(x) Error in match.call(definition, call, expand.dots) : '.Primitive...' is not a function ? Regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
Marc Schwartz <[EMAIL PROTECTED]> writes: > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > [EMAIL PROTECTED] writes: > >=20 > > > Full_Name: Justin Harrington > > > Version: 2.4.0 > > > OS: Fedora Core 6 > > > Submission from: (NULL) (142.103.121.203) > > >=20 > > >=20 > > > When I type the (albeit stupid) command > > >=20 > > > eval(match.call()) > > >=20 > > > R crashes with the following messages (truncated): > > >=20 > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > >=20 > > Yes, don't do that then ;-) >=20 > Indeed... ;-) >=20 > > Part of the puzzle is that > >=20 > > > match.call() > > match.call() > >=20 > > which looks like something with potential for infinite recursion, but > > that doesn't seem to be issue since > >=20 > > > f <- function(call =3D sys.call(sys.parent()))call > > > f() > > f() > > > eval(f()) > > f() > >=20 > > does not exhibit the same crash. And indeed > >=20 > > > x <- quote(match.call()) > > > eval(x) > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > /lib/libc.so.6[0x1f0617] > >=20 > > does look like something that just Should Not Happen... >=20 > Peter, are you on FC6? >=20 > On FC5, I cannot replicate your crash: >=20 > > x <- quote(match.call()) > > eval(x) > Error in match.call(definition, call, expand.dots) : > '.Primitive...' is not a function >=20 > ? Yes, I'm on FC6 since yum had updated the 1229 packages this morning. I see the crash with the FC6 RPM but not with a self-compiled R-patched. --=20 O__ Peter Dalgaard =C3=98ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 22:41 +0100, [EMAIL PROTECTED] wrote: > Marc Schwartz <[EMAIL PROTECTED]> writes: > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > x <- quote(match.call()) > > > > eval(x) > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > /lib/libc.so.6[0x1f0617] > > > does look like something that just Should Not Happen... > > Peter, are you on FC6? > > On FC5, I cannot replicate your crash: > > > x <- quote(match.call()) > > > eval(x) > > Error in match.call(definition, call, expand.dots) : > > '.Primitive...' is not a function > > ? > > Yes, I'm on FC6 since yum had updated the 1229 packages this morning. > > I see the crash with the FC6 RPM but not with a self-compiled R-patched. Are you using Martyn's RPM or Extras? Just wondering if there is any difference. In theory, I suppose, given the prior communications with Tom, there shouldn't be. Also, was this a clean install of FC6 or an "in place upgrade" of FC5. Officially, FC does not support the latter and I have seen mixed comments on the FC lists pertaining to that path and associated issues. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > x <- quote(match.call()) > > > > > eval(x) > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > /lib/libc.so.6[0x1f0617] > > > > > does look like something that just Should Not Happen... I think valgrind shows the problem is in deparse.c: 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, "..."); You need to put a '\0' into data[10] after that strncpy so strcat can find the end of the string when the length of the copied string is >=10. It currently runs into uninitialized memory at the end of ".Primitive". (This is in a copy of R source from June 2006.) Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
Peter Dalgaard wrote: > Marc Schwartz <[EMAIL PROTECTED]> writes: > > >> On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: >> >>> [EMAIL PROTECTED] writes: >>> >>> Full_Name: Justin Harrington Version: 2.4.0 OS: Fedora Core 6 Submission from: (NULL) (142.103.121.203) When I type the (albeit stupid) command eval(match.call()) R crashes with the following messages (truncated): *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated >>> Yes, don't do that then ;-) >>> >> Indeed... ;-) >> >> >>> Part of the puzzle is that >>> >>> match.call() >>> match.call() >>> >>> which looks like something with potential for infinite recursion, but >>> that doesn't seem to be issue since >>> >>> f <- function(call = sys.call(sys.parent()))call f() >>> f() >>> eval(f()) >>> f() >>> >>> does not exhibit the same crash. And indeed >>> >>> x <- quote(match.call()) eval(x) >>> *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated >>> === Backtrace: = >>> /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] >>> /lib/libc.so.6[0x1f0617] >>> >>> does look like something that just Should Not Happen... >>> >> Peter, are you on FC6? >> >> On FC5, I cannot replicate your crash: >> >> >>> x <- quote(match.call()) >>> eval(x) >>> >> Error in match.call(definition, call, expand.dots) : >> '.Primitive...' is not a function >> >> ? >> > > Yes, I'm on FC6 since yum had updated the 1229 packages this morning. > > I see the crash with the FC6 RPM but not with a self-compiled R-patched. > > For what it's worth, I also get the same error when trying it on my (freshly updated) FC4 machine (Linux md.stat.ubc.ca 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:14 EDT 2006 i686 i686 i386 GNU/Linux) with R version 2.4.0 (2006-10-03) Justin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 14:14 -0800, Bill Dunlap wrote: > On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: > > > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > > x <- quote(match.call()) > > > > > > eval(x) > > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > > /lib/libc.so.6[0x1f0617] > > > > > > > does look like something that just Should Not Happen... > > > I think valgrind shows the problem is in deparse.c: > 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); > 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, > "..."); > You need to put a '\0' into data[10] after that strncpy > so strcat can find the end of the string when the length > of the copied string is >=10. It currently runs into > uninitialized memory at the end of ".Primitive". > > (This is in a copy of R source from June 2006.) The code is the same, but a couple of lines off in my copy from R 2.4.0 patched. Now lines 247 and 248. Thanks Bill. This would help to explain the difference in behaviors observed. Regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to put my class into data.frame
Hello! I am developing a composition class, which represents a composition of mixture of levels, say soil has three components and each component accounts for 1/3 of the unit. I have tried with S4 class system and I would appreciate any help here. I was hoping that I would be able to include instance of my class into a data.frame. However, I encounter problems. Simple definition of class could be setClass(Class="composition", representation=representation(ratios="matrix")) n <- 2 k <- 3 x <- new(Class="composition", ratios=matrix(data=rep(x=1/3, times=n*k), nrow=n, ncol=k)) x An object of class "composition" Slot "ratios": [,1] [,2] [,3] [1,] 0.333 0.333 0.333 [2,] 0.333 0.333 0.333 tmp <- data.frame(id=1:2) tmp$comp <- x Error: object is not subsettable As I understand this, my problem is that x is of length 1 as the following works tmp$comp <- c(x, x) although I am not able to print tmp now tmp Error in unlist(x, recursive, use.names) : argument not a list but this is expected as I (probably) need show/print method for this. How can I put my class into data.frame or how can I make my class behave as a vector? Thanks! -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to put my class into data.frame
tmp$comp <- [EMAIL PROTECTED] ?! Gregor Gorjanc wrote: >Hello! > >I am developing a composition class, which represents a composition of >mixture of levels, say soil has three components and each component >accounts for 1/3 of the unit. I have tried with S4 class system and I >would appreciate any help here. I was hoping that I would be able to >include instance of my class into a data.frame. However, I encounter >problems. > >Simple definition of class could be > >setClass(Class="composition", > representation=representation(ratios="matrix")) > >n <- 2 >k <- 3 > >x <- new(Class="composition", ratios=matrix(data=rep(x=1/3, times=n*k), >nrow=n, ncol=k)) > >x >An object of class "composition" >Slot "ratios": > [,1] [,2] [,3] >[1,] 0.333 0.333 0.333 >[2,] 0.333 0.333 0.333 > >tmp <- data.frame(id=1:2) >tmp$comp <- x >Error: object is not subsettable > >As I understand this, my problem is that x is of length 1 as the >following works > >tmp$comp <- c(x, x) > >although I am not able to print tmp now > >tmp >Error in unlist(x, recursive, use.names) : > argument not a list > >but this is expected as I (probably) need show/print method for this. >How can I put my class into data.frame or how can I make my class behave >as a vector? > >Thanks! > > > -- Ferdinand Alimadhi Programmer / Analyst Harvard University The Institute for Quantitative Social Science (617) 496-0187 [EMAIL PROTECTED] www.iq.harvard.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
Bill Dunlap <[EMAIL PROTECTED]> writes: > On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: > > > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > > x <- quote(match.call()) > > > > > > eval(x) > > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > > /lib/libc.so.6[0x1f0617] > > > > > > > does look like something that just Should Not Happen... > > > I think valgrind shows the problem is in deparse.c: > 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); > 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, > "..."); > You need to put a '\0' into data[10] after that strncpy > so strcat can find the end of the string when the length > of the copied string is >=10. It currently runs into > uninitialized memory at the end of ".Primitive". > > (This is in a copy of R source from June 2006.) Now fixed in 2.4.0 Patched and the development version. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to put my class into data.frame
Ferdinand Alimadhi wrote: > tmp$comp <- [EMAIL PROTECTED] ?! I "lose" class here and that is not what I want. Perhaps I should stick with list instead of data.frame. > Gregor Gorjanc wrote: > >> Hello! >> >> I am developing a composition class, which represents a composition of >> mixture of levels, say soil has three components and each component >> accounts for 1/3 of the unit. I have tried with S4 class system and I >> would appreciate any help here. I was hoping that I would be able to >> include instance of my class into a data.frame. However, I encounter >> problems. >> >> Simple definition of class could be >> >> setClass(Class="composition", >> representation=representation(ratios="matrix")) >> >> n <- 2 >> k <- 3 >> >> x <- new(Class="composition", ratios=matrix(data=rep(x=1/3, times=n*k), >> nrow=n, ncol=k)) >> >> x >> An object of class "composition" >> Slot "ratios": >> [,1] [,2] [,3] >> [1,] 0.333 0.333 0.333 >> [2,] 0.333 0.333 0.333 >> >> tmp <- data.frame(id=1:2) >> tmp$comp <- x >> Error: object is not subsettable >> >> As I understand this, my problem is that x is of length 1 as the >> following works >> >> tmp$comp <- c(x, x) >> >> although I am not able to print tmp now >> >> tmp >> Error in unlist(x, recursive, use.names) : >> argument not a list >> >> but this is expected as I (probably) need show/print method for this. >> How can I put my class into data.frame or how can I make my class behave >> as a vector? >> >> Thanks! -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
Bill Dunlap <[EMAIL PROTECTED]> writes: > On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: >=20 > > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > > x <- quote(match.call()) > > > > > > eval(x) > > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > > /lib/libc.so.6[0x1f0617] > > > > > > > does look like something that just Should Not Happen... >=20 >=20 > I think valgrind shows the problem is in deparse.c: > 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); > 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, = "..."); > You need to put a '\0' into data[10] after that strncpy > so strcat can find the end of the string when the length > of the copied string is >=3D10. It currently runs into > uninitialized memory at the end of ".Primitive". >=20 > (This is in a copy of R source from June 2006.) Now fixed in 2.4.0 Patched and the development version. --=20 O__ Peter Dalgaard =C3=98ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
