------ art_522_29111856.1196623776509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't think we necessarily disagree. But a couple of comments and clarification of a couple of points. Python optimization creates a separate file, with the extension .pyo or .pyc (as opposed to .py which is what the debuggers use). When necessary, I've been able to debug C and C++ programs in gdb even at the highest levels of optimization with a large level of success. Of course, the programmer has to realize keep in mind transformations that may have been taken by the optimizer. But programmer awareness of how the optimizer transformed the program (during say debugging of optimized code) isn't necessarily a bad thing either. In short, code optimization and debuggers have lived together for a while now. I don't think it's anything one should be afraid of. In case I wasn't clear before though, the request isn't strictly about debuggers so much as introspection. Introspection is used by debuggers, but it could be used in performance tools, and yes, even optimizers. Or just run-of-the-mill user programs, see for example Perl's Carp module. On Dec 2, 2007 12:57 PM, Charles Oliver Nutter <charles.nutter / sun.com> wrote: > Rocky Bernstein wrote: > > The below is a little long. So here's a summary. > > > > Ideally what I'd like in 1.9, 1.9.1 or 2.0: > > * Frame/Block objects which contains > > - line, (may be nil) > > - method, # of args (may be nil) > > - access to a binding object which we can eval for access to that > > scope (not nil) > > My understanding is this information is around at run time. > > > > * Thread Object which gives access to the Frame/Block above. So access > > to the Frame object could be via a something like > > thread.caller(level-number). > > > > * Enough added to the C-API added (e.g. parts of vm_core.h) to be able > > to write code to do the above. > > Be careful what you ask for. > > Exposing call frames to the code is a neat, useful feature, to be sure. > And Python's debugging capabilities use such access to great effect, > inspecting the call stack and so on. But all is not wine and roses. > Exposing call frames, scoping constructs, and so on prevents any > implementation from minimizing or optimizing frames away. Many of the > fastest language implementations and VMs (like the JVM, JRuby, and I > believe Ruby 1.9) get that way because frames are not exposed and they > can optimize them in different ways. In the JVM, a Java call may result > in one, many, or even zero C call frames being constructed, and after > more and more code gets inlined this metric will change. > > IronPython, which boasts better performance than C Python in many cases, > gets there largely because it does not support frame objects. The side > effect is that you can't use any of the Python frame-inspecting tools > with IronPython. > > So yes, you may get good features out of having frames exposed to the > language, but to my knowledge there's no implementation that does so and > avoids paying a performance penalty for it. > > JRuby could support such a feature, but I can tell you right now it > would negatively impact performance, and we'd probably make it an > optional flag so folks not interested in using the feature could run > without it. > > - Charlie > > ------ art_522_29111856.1196623776509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't think we necessarily disagree. But a couple of comments and clarification of a couple of points. <br><br>Python optimization creates a separate file, with the extension .pyo or .pyc (as opposed to .py which is what the debuggers use). <br><br>When necessary, I've been able to debug C and C++ programs in gdb even at the highest levels of optimization with a large level of success. <br><br>Of course, the programmer has to realize keep in mind transformations that may have been taken by the optimizer. But programmer awareness of how the optimizer transformed the program (during say debugging of optimized code) isn't necessarily a bad thing either. <br><br>In short, code optimization and debuggers have lived together for a while now. I don't think it's anything one should be afraid of.<br><br>In case I wasn't clear before though, the request isn't strictly about debuggers so much as introspection. Introspection is used by debuggers, but it could be used in performance tools, and yes, even optimizers. Or just run-of-the-mill user programs, see for example Perl's Carp module. <br><br><div class mail_quote">On Dec 2, 2007 12:57 PM, Charles Oliver Nutter <<a href ailto:charles.nutter / sun.com">charles.nutter / sun.com</a>> wrote:<br><blockquote class mail_quote" style order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class h2E3d">Rocky Bernstein wrote:<br>> The below is a little long. So here's a summary.<br>><br>> Ideally what I'd like in 1.9, 1.9.1 or 2.0:<br>> * Frame/Block objects which contains<br>> - line, (may be nil) <br>> - method, # of args (may be nil)<br>> - access to a binding object which we can eval for access to that<br>> scope (not nil)<br>> My understanding is this information is around at run time.<br> ><br>> * Thread Object which gives access to the Frame/Block above. So access<br>> to the Frame object could be via a something like<br>> thread.caller(level-number).<br>><br>> * Enough added to the C-API added ( e.g. parts of vm_core.h) to be able<br>> to write code to do the above.<br><br></div>Be careful what you ask for.<br><br>Exposing call frames to the code is a neat, useful feature, to be sure.<br>And Python's debugging capabilities use such access to great effect, <br>inspecting the call stack and so on. But all is not wine and roses.<br>Exposing call frames, scoping constructs, and so on prevents any<br>implementation from minimizing or optimizing frames away. Many of the<br>fastest language implementations and VMs (like the JVM, JRuby, and I <br>believe Ruby 1.9) get that way because frames are not exposed and they<br>can optimize them in different ways. In the JVM, a Java call may result<br>in one, many, or even zero C call frames being constructed, and after <br>more and more code gets inlined this metric will change.<br><br>IronPython, which boasts better performance than C Python in many cases,<br>gets there largely because it does not support frame objects. The side<br>effect is that you can't use any of the Python frame-inspecting tools <br>with IronPython.<br><br>So yes, you may get good features out of having frames exposed to the<br>language, but to my knowledge there's no implementation that does so and<br>avoids paying a performance penalty for it. <br><br>JRuby could support such a feature, but I can tell you right now it<br>would negatively impact performance, and we'd probably make it an<br>optional flag so folks not interested in using the feature could run<br> without it.<br><br>- Charlie<br><br></blockquote></div><br> ------ art_522_29111856.1196623776509--