ugexe i can't put my finger on it but it still seems a bit redundant 00:09
Like without having thought about it for more than 30 seconds I think I would have conditionally set a `new_status` variable and then have a single MVM_cas call outside of the conditionals, something like `MVM_cas(&other->gc_status, status_bits | suspend_bits, new_status | suspend_bits) == (status_bits | suspend_bits))`. Although having typed out this thought I'm not sure that would be equivalent 00:15
00:42 timo left 00:55 leont left, leont joined 10:15 librasteve_ joined 10:59 vrurg joined, vrurg_ left 11:15 timo joined 12:01 Geth left, Geth joined 13:05 librasteve_ left
patrickb Are frames (on the context of the debugserver) completely anologous to the `caller` chain? 13:07
lizmat afaik, yes, that's at least the mental model I've been using timo? 13:24
but note, something like ".say for ^10" may introduce a frame that is not obvious from looking at the code 13:25
otoh, static optimization may have removed frames already 13:30
is also my understanding
patrickb Context: I'm pondering how to present the different views of data in the debugger. Now I wonder if I should allow introspecting both, frames and the caller chain or if I could just as well drop one of the two concepts. Given frames don't have a strong presence in Raku I wonder if I could just present the debugger frames under the name "callers". But that's only ok to do if they match perfectly. 13:33
lizmat there *is* a class CallFrame in Rakudo 13:43
docs.raku.org/type/CallFrame 13:44
patrickb Good point! 14:16
timo i have been meaning to double-check how exactly especially inlines are reflected (or not) in that output, but what the debugserver gives you is, as far as i can tell, exactly what you can get a "context" object for, which is also a moarvm "thing" that we use inside rakudo to do stuff 14:35
15:32 librasteve_ joined 19:02 Sario left, Sario joined 20:15 librasteve_ left 23:27 gfldex left, gfldex joined