Storing the information is very good: how do we extract it, again? we
have {get,set}{file,line} opcodes, but if we're going to store more
generic information, we need a more generic way to extract it.
As one of the first "here's something extra I need", I need not only
line numbers for files, but line numbers of user defined subroutines
and eval blocks. (that is, the line *of the sub def* that the error
occurs on, in addition to each line as we go.)
user generated error
while executing
"error "user generated error""
(procedure "joe" line 2)
invoked from within
"joe"
(procedure "test" line 4)
invoked from within
"test "
("eval" body line 1)
invoked from within
"eval { test }"
(file "foo.tcl" line 3)
Regards.
On Nov 13, 2005, at 8:19 PM, Joshua Isom wrote:
I'm pretty sure it already is for when pir's compiled to pasm.
Joshua
PASM generation from PIR is (was?) documented as borked. PIR and PASM
should be considered to each go directly to bytecode.
On Nov 13, 2005, at 7:16 PM, Joshua Hoblitt wrote:
I think it would be better if we didn't overload the meaning of
'\s*#.*'
in PIR.
-J
--
On Mon, Nov 14, 2005 at 01:48:35AM +0100, Leopold Toetsch wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
Hi,
.hll_debug file "something.pl"
.hll_debug line 1
Just
#line 123
#line 789 "file.foo"
looks simpler and well known to me - the latter is already
parsed. But
actually making it work is more important for me.
Either an integer or a string constant from the constants table
Storing debug-only things in the constant table could complicate
a TODO
'pbc_strip(1)' utility but not a problem.
pbc_merge deals with such things already.
Jonathan
leo
