[Disclaimer: I've only just started thinking about this in the last hour, and don't want to appear all knowledgeable or anything!]
On 11/14/05, Jonathan Worthington <[EMAIL PROTECTED]> wrote: > My current thinking on this is that a HLL will define a sub that knows how > to print errors for that HLL. That sub would be passed an array PMC, with > element 0 representing the current sub, element 1 representing it's caller, > etc, so you can produce a backtrace. Each entry in the array would be a > hash containing the HLL debug info. So a very simple handler could maybe > look like:- > ... I agree, although I'm tempted to say that the PMCs in the backtrace would encapsulate the backtrace, but wouldn't have yet looked things up yet in the HLL debug info. It would be up to the code snipped that you provided to do the actual lookup using an opcode. Like you say, the handler can be as simple or as complicated as required, and delegate to other more appropriate handlers if necessary. It would also print sensible messages depending on what information is available (e.g. column information would only be printed if it is in the hash), and perhaps do nice word wrapping etc. > > 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.) > > > Unless I'm missing something, that's fine with what I proposed; you can emit > a ".hll_debug line 42" or similar without having to specify a filename. The > line number means whatever you'd like it to mean - it doesn't have to be > line number in a file. > Out of interest, are we able to associate HLL debug info with eval'd code? Does it have a directory, or is it just the bytecode? Cheers, Nick
