[ruby-core:40411] Re: 2.0 feature questionnaire

On Wed, Oct 26, 2011 at 3:39 AM, Charles Oliver Nutter
<[e-mail]>wrote:

>
> As you probably know, I'm still of the opinion that debug time and
> runtime have completely different characteristics.


Yes, I thought it improbable that you would believe otherwise.

Expecting that
> debug-time binding access (frame access, local variable modification,
> etc) should be available at normal runtime is unreasonable...


I wouldn't put it so strongly, especially as I can think of many
implementations of dynamic languages, including Ruby implementations where
this is the case and where it is unlikely for those implementations to
change drastically.

it's not
> possible to do this without killing many, many optimizations.


I understand your point and don't disagree.  The extent to which
optimization is important and how important versus allowing run-time
dynamicism including environment access (which is typically used by
debuggers in systems that provide it) I am unwilling to take a stand or pass
judgement on.

You and
> I discussed that those optimizations could still be active and
> debuggers would just lose functionality...but I'm not sure I see that
> being useful.


I think I take a minority opinion here. Debugging for me is about
transparency. Here, that means giving the programmer an understanding of
what the running program is doing -- whatever that may be. If the
translation system has heavily modified the source code, so be it. When
there's something horribly wrong that a programmer needs to be involved,
offering what is there is better than saying, sorry you are out of luck.

For decades programmers have debugged optimized C code with gdb. Is it the
preferred way to go? No. Given the choice of starting over but first
recompiling without optimization and running again with debugging, just
about always a C programmer will do that. But in some situations you can't.
 I think there would be a number of C programmers, myself included, who
would be disappointed if you said you can *only* debug C code that has no
optimization.

If JRuby eliminated all local variables for a given
> method and the debugger was unable to see them, what use is the local
> variable feature of the debugger


Right, it's not useful in that particular context. What I'd request  though
is that the transformation system kept some sort of information indicating
that local variables were eliminated. It could be done on a very coarse
level, such as recording that you are in optimized code or recording the
compilation options. Or a fine level such as recording which locals were
eliminated.

In the patches to MRI/YARV 1.9.2, one thing I changed is the ability to not
throw out the compile flags that are normally stored during compilation;
this is the default if we think debugging is on which is determined if the
__SCRIPT_LINES__ hash is set.

In the gcc case, sometimes one will ask about local variables and if they
happen to be in a register you may get the wrong answer. It's not great, but
personally I've gotten used to it. And I prefer that to the "sorry out of
luck" answer. Or a solution where a debugger that *never* allows me ask
about local variables.  Again, I am probably in the minority, but I
sometimes may disassemble code in gdb which usually clues me into whether I
can expect the variable to be stored in the place gdb is probably looking
at.

So again, I probably am the only one who uses this, but for the trepanning
debuggers as well as for the python debuggers before it, have a command to
show bytecode disassembly.



I'm still of the opinion that
> debugging will almost always be most useful in a mode that limits
> optimizations normally invisible to the user, so we're talking about a
> completely different mode of execution where full-system binding
> access may be just fine.
>

I don't disagree. And this works. Obviously, because that's how debugging in
more static languages invariably works. It could also be that way for more
dynamic languages as well. But it's all in the details. And that's why I
take interest here.

Let's take for example the recent proposal of adding Dtrace enhancements for
debugging in MRI 2.0. I'm not totally sure what that means (which is my
bad), but I suspect that whatever this does it has nothing to change the way
variables are accessing/modified in a debugger.

So before closing, I will reiterate an observation I've only slowly noticed:
the state of debuggers has a tendency of getting worse. Just as you would
like to hold the line or improve what can be optimized in a language system,
I would like to hold the line or improve debugging, tracing, profiling and
debuggers in such systems.


>
> In any case, this is a bit off topic.
>

Yep. And with this too long post I think I have overstayed my welcome. In
the back of my mind I think most of what I want is relevant to or of
interest to very few. So if this falls on deaf ears, like the ability to ask
about local variables: so be it.


> - Charlie
>
>