This is a follow-up to bug sent to days ago, which bounced from r-devel
because
the example was to large. Now example is smaller, and behaviour is as
belo,
EXEPT that r-windows not any more bombs, so main problem is
"xpdrows.data.frame"???
By the way, how to debug this example under windows? debug() doesnt
accept
the functions used (.Primitive), and R wont run under gdb --- may have
to do
with R.dll, from the manual for gdb i get it that it cannot debug
functions
in shared libraries?
copied:
Using the data frames frame1 and frame2 from the attached saved dataset
frame.dat
(say load("frame.dat") ):
> for (i in 1:11) {
+ frame1[i, ] <- frame2[i, ] }
Error: couldn't find function "xpdrows.data.frame"
--- What is function xpdrows.data.frame? There should be an more
appropiate
error mssage here! (the data frame frame1 isn't long enough for the
last
assignment, but this is a small, artificiall example, ocurred same
error
with much larger frames, and the reason for the error was'nt clear,
not necessarily
"index out of bound", as appropiate(?) here).
After the above:
> dim(frame1)
NULL> length(frame1)
[1] 11> class(frame1)
NULL
which shows that frame1 is destroyed as a data frame, but the str
function works on it.
but trying to print frame1
> frame1
and R (windows) bombs, after some considerable time! (~10 min)
This data frame has a factor with a very large levels set, might have to
do with that.
The error message should be meaningfull, and shuld'nt return a destroyed
object
which bombs when printing.
Kjetil Halvorsen
khal@alumni.uv.es writes:> This is a multi-part message in MIME format. > --------------E6449E20185CF0A71A620457 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > This is a follow-up to bug sent to days ago, which bounced from r-devel > because > the example was to large. Now example is smaller, and behaviour is as...> Using the data frames frame1 and frame2 from the attached saved dataset > frame.dat > (say load("frame.dat") ):....> --------------E6449E20185CF0A71A620457 > Content-Type: application/x-unknown-content-type-DAT_auto_file; name="frame.dat" > Content-Transfer-Encoding: base64 > Content-Disposition: inline; filename="frame.dat" > > MTk3Ngo2IDEzMSA1NzEKMCAxMyAiY2xhc3MiCjEgMzEgImxldmVscyIKMiAzNyAibmFtZXMi > CjMgNDMgInJvdy5uYW1lcyIKNSAxNzMwMTIgImZyYW1lMiIKNiAxNzMwMzAgImZyYW1lMSIK > NCA2NTQ3NQo3IDU3NzUxMQo4IDU3NzUxMgo5IDU3NzY2NwoxMCA1Nzc2NjgKMTEgNTc3NjY5 > CjEyIDU3NzY3MAoxMyA1Nzc2NzIKMTQgNjA5Njc3CjE1IDYwOTY3OAoxNiA2MDk2NzkKMTcg > NjA5NjgwCjE4IDYwOTY4MgoxOSA2MTQ1ODIKMjAgNjE0NTgzCjIxIDYxNDU4NAoyMiA2MTQ1This is not a good idea! MIME attachments do not survive the trip through JitterBug. So to read your data, one has to find a separate base64 decoder and feed it the above gibberish. (And even if we could get the remailer to handle it, it would still be a problem with the filed text.) It can't be that hard to cook up a smaller, plaintext example? E.g.> f1<-data.frame(a=1:2,b=3:4) > f2<-f1 > f2[3,]<-f1[2,]Error: couldn't find function "xpdrows.data.frame" ..which, incidentally, is fixed in the 0.63.3 snapshots. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._