search for: do_eval

...5C R.dll:004DB75C do_if 004DA9E8 R.dll:004DA9E8 Rf_eval 004DC0D2 R.dll:004DC0D2 do_begin 004DA9E8 R.dll:004DA9E8 Rf_eval 004DACD5 R.dll:004DACD5 Rf_applyClosure 004DA7F7 R.dll:004DA7F7 Rf_eval 004DC0D2 R.dll:004DC0D2 do_begin 004DA9E8 R.dll:004DA9E8 Rf_eval 004DD315 R.dll:004DD315 do_eval 00509CB4 R.dll:00509CB4 do_internal 004DA9E8 R.dll:004DA9E8 Rf_eval 004DACD5 R.dll:004DACD5 Rf_applyClosure 004DA7F7 R.dll:004DA7F7 Rf_eval 004DD315 R.dll:004DD315 do_eval 00509CB4 R.dll:00509CB4 do_internal 004DA9E8 R.dll:004DA9E8 Rf_eval 004DACD5 R.dll:004DACD5 Rf_applyClosure 004...

...are not the same 2. `evalq(sys.parent(1))` and `evalq((function() sys.parent(2))())` ?? are not the same 3. `evalq((function() sys.parent(1))())` returns a lower frame number ?? than `evalq(sys.parent(1))` The root cause of this is that the `evalq` **closure** sets a context, but then the C-level `do_eval` it invokes sets another one[1] with the new `evalq` context as the calling frame (`cptr->sysparent`)[2].? This then interacts with how `sys.parent` resolves parents when a target frame appears more than once in the context stack.? `sys.parent` returns the oldest context that matches[3], and in...

...oess_ise (loessc.c:219) ==30841== by 0x486C7F: do_dotCode (dotcode.c:1744) ==30841== by 0x4AB040: bcEval (eval.c:4544) ==30841== by 0x4B6B3F: Rf_eval (eval.c:498) ==30841== by 0x4BAD87: Rf_applyClosure (eval.c:960) ==30841== by 0x4B6D5E: Rf_eval (eval.c:611) ==30841== by 0x4B7A1E: do_eval (eval.c:2193) ==30841== by 0x4AB040: bcEval (eval.c:4544) ==30841== by 0x4B6B3F: Rf_eval (eval.c:498) ==30841== Address 0xf8cd4144 is not stack'd, malloc'd or (recently) free'd ==30841== *** caught segfault *** address 0xf8cd4144, cause 'memory not mapped' Traceback:...

nchar(with(list(2),ls())) gives an internal error. This is of course a peculiar call (no names in the list), but the error is not caught cleanly. It is not clear from the documentation whether with(list(2)...) is allowable; if it is not, it should presumably give an error. If it is, then ls shouldn't have problems with the resulting environment. > qq <- with(list(2),ls())

...Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A6B5 R.dll:0052A6B5 Rf_applyClosure # 0052A1D7 R.dll:0052A1D7 Rf_eval # 0052CCE6 R.dll:0052CCE6 do_eval # 00559594 R.dll:00559594 do_internal # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A6B5 R.dll:0052A6B5 Rf_applyClosure # 0052A1D7 R.dll:0052A1D7 Rf_eval # 0052C2D5 R.dll:0052C2D5 do_set # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval...

...3 #7 0x00002b499ca1dda6 in Rf_eval (e=0x4cd1160, rho=0x488ca48) at eval.c:461 #8 0x00002b499ca1ea82 in do_begin (call=0x4cd1198, op=0x486a830, args=0x4cd11d0, rho=0x488ca48) at eval.c:1174 #9 0x00002b499ca1dda6 in Rf_eval (e=0x4cd1198, rho=0x488ca48) at eval.c:461 #10 0x00002b499ca22494 in do_eval (call=0x49893f8, op=0x487ed08, args=<value optimized out>, rho=0x511ec40) at eval.c:1752 #11 0x00002b499ca4b74e in do_internal (call=<value optimized out>, op=<value optimized out>, args=<value optimized out>, env=0x511ec40) at names.c:1140 #12 0x00002b499ca1dda6 in Rf...

Hey All, Just a couple of things to note. I''ve updated the wxGenericDirCtrl.h file, to include the ReCreateTree() method, as it was missing, and was very simple to add. I''ve compiled, and checked to make sure everything looks good, and it does. Also, a temporary solution, till wxGenericDirCtrl#get_tree_ctrl() is fixed, is that you can sub-class Wx::GenericDirCtrl() into your

When an attribute is a delayed expression sometimes it is not forced when it is extracted. > x <- list() > attr(x, "p") <- delay(1) > x list() attr(,"p") <promise: 0x11e4bb8> > val <- attr(x, "p") > val [1] 1 > attr(x, "p") <promise: 0x11e4bb8> I am not quite sure whether the above is a bug or not but I think

...e remaining values must be named already. =A0(This is useful > =A0in cases where the entire valuelist is already named--namelist can > =A0then be R_NilValue.) > " > > Removing the assumption from NewEnvironment looks like an efficiency sink= , > so I would suggest that we fix do_eval (eval.c) instead, effectively doin= g l > <- l[names(l) !=3D ""]. =A0So in > > =A0 =A0case LISTSXP: > =A0 =A0 =A0 =A0env =3D NewEnvironment(R_NilValue, duplicate(CADR(args)), = encl); > =A0 =A0 =A0 =A0PROTECT(env); > =A0 =A0 =A0 =A0break; > > we need to replace...

...Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A6B5 R.dll:0052A6B5 Rf_applyClosure # 0052A1D7 R.dll:0052A1D7 Rf_eval # 0052CCE6 R.dll:0052CCE6 do_eval # 00559594 R.dll:00559594 do_internal # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A6B5 R.dll:0052A6B5 Rf_applyClosure # 0052A1D7 R.dll:0052A1D7 Rf_eval # 0052C2D5 R.dll:0052C2D5 do_set # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval...

...Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A6B5 R.dll:0052A6B5 Rf_applyClosure # 0052A1D7 R.dll:0052A1D7 Rf_eval # 0052CCE6 R.dll:0052CCE6 do_eval # 00559594 R.dll:00559594 do_internal # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052A6B5 R.dll:0052A6B5 Rf_applyClosure # 0052A1D7 R.dll:0052A1D7 Rf_eval # 0052C2D5 R.dll:0052C2D5 do_set # 0052A3C8 R.dll:0052A3C8 Rf_eval # 0052BA52 R.dll:0052BA52 do_begin # 0052A3C8 R.dll:0052A3C8 Rf_eval...

...l:100846E0 Rf_eval 10084671 R.dll:10084671 Rf_eval 1008487C R.dll:1008487C Rf_eval 10085595 R.dll:10085595 Rf_evalList 100A8F0F R.dll:100A8F0F do_internal 1008494A R.dll:1008494A Rf_eval 100875AB R.dll:100875AB Rf_applyClosure 100846E0 R.dll:100846E0 Rf_eval 10085012 R.dll:10085012 do_eval 100A8E41 R.dll:100A8E41 do_internal 1008494A R.dll:1008494A Rf_eval 100875AB R.dll:100875AB Rf_applyClosure 100846E0 R.dll:100846E0 Rf_eval 100863D5 R.dll:100863D5 do_begin 1008494A R.dll:1008494A Rf_eval 1008494A R.dll:1008494A Rf_eval 100863D5 R.dll:100863D5 do_begin 1008494A R.d...

I installed ovirt-agent on a fresh fedora 11 install (not in a virtual machine). The only thing I modified prior to installation was /etc/resolv.conf in order to be able to yum update and install the ovirt packages via yum (from the ovirt repo), and /etc/ntp.conf to get the correct time from the NTP server of my network. I also disabled NetworkManager via chkconfig. I used all the options for

If anyone has a few extra CPU cycles to spare, I'd appreciate it if you could verify a problem that I have encountered. Run the code below and tell me if it crashes your R before completion. library(lme4) data(bdf) dump<-sapply( 1:50000, function(i) { fm <- lme(langPOST ~ IQ.ver.cen + avg.IQ.ver.cen, data = bdf, random = ~ IQ.ver.cen | schoolNR); cat("

..._applyClosure + 728 53 libR.dylib 0x003a13f0 Rf_eval + 1008 54 libR.dylib 0x003a2b08 do_begin + 104 55 libR.dylib 0x003a14dc Rf_eval + 1244 56 libR.dylib 0x003a4f58 Rf_applyClosure + 728 57 libR.dylib 0x003a13f0 Rf_eval + 1008 58 libR.dylib 0x003a1eac do_eval + 1868 59 libR.dylib 0x003e7d2c do_internal + 636 60 libR.dylib 0x003a14dc Rf_eval + 1244 61 libR.dylib 0x003a4f58 Rf_applyClosure + 728 62 libR.dylib 0x003a13f0 Rf_eval + 1008 63 libR.dylib 0x003a45f4 do_set + 980 64 libR.dylib 0x003a14dc Rf_eval + 1...

...0x0026744c do_begin + 136 (eval.c:1058) 6 libR.dylib 0x00265af4 Rf_eval + 1100 (eval.c:382) 7 libR.dylib 0x00266150 Rf_applyClosure + 952 (eval.c:576) 8 libR.dylib 0x00265d2c Rf_eval + 1668 (eval.c:417) 9 libR.dylib 0x00268678 do_eval + 700 (eval.c:1568) 10 libR.dylib 0x0029acec do_internal + 392 (names.c: 1084) 11 libR.dylib 0x00265af4 Rf_eval + 1100 (eval.c:382) 12 libR.dylib 0x00266150 Rf_applyClosure + 952 (eval.c:576) 13 libR.dylib 0x00265d2c Rf_eval + 1668...

...0x0026744c do_begin + 136 (eval.c:1058) 6 libR.dylib 0x00265af4 Rf_eval + 1100 (eval.c:382) 7 libR.dylib 0x00266150 Rf_applyClosure + 952 (eval.c:576) 8 libR.dylib 0x00265d2c Rf_eval + 1668 (eval.c:417) 9 libR.dylib 0x00268678 do_eval + 700 (eval.c:1568) 10 libR.dylib 0x0029acec do_internal + 392 (names.c: 1084) 11 libR.dylib 0x00265af4 Rf_eval + 1100 (eval.c:382) 12 libR.dylib 0x00266150 Rf_applyClosure + 952 (eval.c:576) 13 libR.dylib 0x00265d2c Rf_eval + 1668...