At 02:20 PM 9/13/00 -0600, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I wouldn't worry about this too much. If it's all keyed off an opcode of
> > some sort ("Current line info"), we could easily just strip those opcodes
> > out. They won't take up that much space relative to the rest of the
> > program, but I can see some sort of runtime overhead if we have each
> > 'current line' op smack a pointer to the current line info into the
> > interpreter structure or something.
>
>That'd be an incentive to write one-liners ... they'd be faster :-)
I'm not entirely sure that's a good thing... :-P
>Wouldn't removing opcodes make it impossible for you to give the user
>a position in the optree that they can turn back into a point in their
>program?
Yes.
>It seems like you'd only be able to say "division by zero at
>position 4501 of the opcode stream" and position 4501 has a different
>opcode in stripped and unstripped programs. You'd have to recompile
>your Perl program, and have a pseudo-strip that calculates where 4501
>in the stripped opcode tree would be, then tells you where in your
>program that corresponds to.
>
>I could also be missing the point. :)
No, that's the point. But if someone explicitly strips out the debugging
info then, well, you don't get much help in debugging, now do you? :)
I'm not saying this would be the default, by any means. (Though a new
pragma, "no debugging;", might be handy for modules we are reasonably
certain work properly) If you want to yank that info out, for either speed
or space reasons, that's fine with me. It'd be in by default, but we could
then have a perlstrip program to filter it out of the executable, and maybe
a command-line switch to disable it.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
