New method 'show_stack' to show Ruby stack(s) when program is running
It would be great to have a method to show the Ruby stack(s) (there are actually two of these) while a Ruby program is running. This would help people to understand how Ruby works internally. There is functionality in Ruby already to print out the stack(s), but it is only triggered when there is an internal error in the interpreter.
The attached patch is just a proof of concept. At least some more cleanup will be needed.
There's how it's supposed to work:
ruby -e '3 + 4 * 5 ** 6.show_stack'
-- Control Frames ----------------------------------------------- c:0001 p:0000 s:0003 E:001c90 (none) [FINISH] c:0002 p:0011 s:0009 e:000005 EVAL -e:1 [FINISH] -- Internal Stack ------------ 0009 (0x6ffffef0058): 000000000000000d Integer: 6 <- Stack Pointer (2) 0008 (0x6ffffef0050): 000000000000000b Integer: 5 0007 (0x6ffffef0048): 0000000000000009 Integer: 4 0006 (0x6ffffef0040): 0000000000000007 Integer: 3 0005 (0x6ffffef0038): 0000000077770021 (flags) <- Environment Pointer (2) 0004 (0x6ffffef0030): 000000060013e3f1 (specval) 0003 (0x6ffffef0028): 0000000000000000 (me_cref) <- Stack Pointer (1)
In the above example, the various operands (3, 4, 5, 6) on the stack can easily be seen.
Because the stack grows e.g. when expressions are evaluated (see above), it's very handy to have the
Object#show_stack, so that
show_stack can be applied at any very specific point during execution. I implemented
RubyVM.show_stack before I realized that
Object#show_stack would be needed, so it's still there, but may now be superfluous.
The format of the output is based on the existing functions in vm_dump.c, but changed in a few aspects:
1) Overall order and terminology adapted to match the "Ruby under the Microscope" book.
2) Added more user-friendly output for frequent classes such as Integer, String, Symbol, nil, false, true,...
3) Cut off output of the actual call to the
Issues on which I'd like to get feedback:
- Builtin/stdlib or gem? (the functionality is not needed in production, only for educational purposes, but it would be more convenient to have it in the standard library because of the code overlap).
- Method name
- Implementation details (I'm sure there's lots of little issues to fix)