|Problems? Is your data what you think it is?|
Re^5: How to do perl -c inside perl?by rockyb (Sexton)
|on Aug 29, 2012 at 23:44 UTC||Need Help??|
Yeah, I'm getting the sense that there is a disconnect somewhere here. Perhaps it's best to acknowledge that and leave it as it is.
In the situation of the front-end setup program, trepan.pl, before it exec's Perl it does some setup. After it issues exec it has lost control; what is reported by Perl contains some setup code along with Perl code that the programmer specified. Sorting the two can be confusing, especially for novices. Better error reporting is had by trepan.pl keeping control and filtering output on failure.
In the situation of handling gdb-like condition expressions, displays and watch-points, a syntax error in an expression or statement may mean a very large number of evaluations with the same error before the programmer may have an opportunity to fix the expression. Worse, it may cause the program to continue running where it should have previously stopped. So therefore we don't let such syntactically invalid expressions to get set.
Even when expressions and statements are syntactically correct this is still a problem. Whatever a debugger can do to reduce this, like make sure expressions are syntactically correct is well worth the effort in reducing overall programmer and debugger writer aggravation.
Safe is interesting but in those cases where syntax checking is not needed but true evaluation is to be done, then what we want is most unsafe. Debugging is inherently unsafe and people want evaluation to done as though it were in the exact context of the stopped program at the point it is stopped, including access to the local variables and the filesystem and OS.
Likewise, PPI is also interesting. But quoting from the document cited:
The purpose of PPI is not to parse Perl Code, but to parse Perl Documents.
Where something like this has been useful in similar debuggers is to be able to pick out subroutine names (via separation of the package name from the subroutine name) or to get code references which can be used to give a listing of those subroutines, give a disassembly of them, or set a breakpoint on them. However I don't think Perl5 has the control over introspection and evaluation that I have needed in Python or Ruby in order to be able to pull this off.