search for: do_ev

...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 0...

...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 i...

...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_ev...

...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...

...l wxGenericDirCtrl#get_tree_ctrl() is fixed, is that you can sub-class Wx::GenericDirCtrl() into your own class, and intercept messages sent by the TreeCtrl within it. Example: class MyDirCtrl < Wx::GenericDirCtrl def initialize(*args) super evt_tree_item_selected(Wx::ID_ANY) { |evt| do_event(evt) } end end As far as I know, this will work with any of the evt_tree* signals. A bit of a hack, but it should work without any problems. L8ers, -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ htt...

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 replac...

...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_ev...

...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_ev...

...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...

...46 +0200 2009 (2434) Error in ovirt-agent: Unknown class agent ERROR Fri Oct 09 18:02:46 +0200 2009 (2434) /usr/share/ovirt-server/ovirt-agent/ovirt-agent.rb:201:in `get_query' /usr/lib/ruby/site_ruby/1.8/qmf.rb:282:in `do_agent_events' /usr/lib/ruby/site_ruby/1.8/qmf.rb:320:in `do_events' /usr/lib/ruby/site_ruby/1.8/qmf.rb:342:in `sess_event_recv' /usr/lib/ruby/site_ruby/1.8/qmf.rb:121:in `run' /usr/lib/ruby/site_ruby/1.8/qmf.rb:83:in `initialize' /usr/lib/ruby/site_ruby/1.8/qmf.rb:82:in `new' /usr/lib/ruby/site_ruby/1.8/qmf.rb:82:in `ini...

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 +...

...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 + 166...

...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 + 166...