I just noticed that I no longer see Lisp source line numbers in our backtraces. I'm assuming this is a property of the new classwriter. For debugging, this seems like a serious regression as we already had a paucity of debug information (no way to inspect the frames, no stepped, etc.) Having the line number of the form associated with the stack frame at least gave a bit of a clue as to where to look for the source of a condition.
Is my presumption if the lossage stemming from the new classwriter correct? Would it be easy to restore? We seem to be including the ordinal of the top level form in the class name (i.e. "org.armedbear.lisp.ASDF_TMP_installer_51.execute(installer.lisp)" contains the result of compiling the 51st top-level form in 'installer.lisp'), so it should be fairly easy to include a single entry in the LineNumberTable attribute linking the start of the class code with the Lisp source.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Hi Mark,
On Fri, Nov 19, 2010 at 9:55 AM, Mark Evenson evenson@panix.com wrote:
I just noticed that I no longer see Lisp source line numbers in our backtraces. I'm assuming this is a property of the new classwriter. For debugging, this seems like a serious regression as we already had a paucity of debug information (no way to inspect the frames, no stepped, etc.) Having the line number of the form associated with the stack frame at least gave a bit of a clue as to where to look for the source of a condition.
Is my presumption if the lossage stemming from the new classwriter correct?
Yes.
Would it be easy to restore?
Yes. As a matter of fact, I just did. We did add the LineNumberTable attribute into the class file, but we stuck it on the method itself, instead of on the Code attribute of the method (where Java expects it).
Fixed and backported.
Bye,
Erik.
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Mark Evenson