Spencer;<br><span dir="ltr"></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bytecode instruction number is typically related to position within the current function (where a function might be an actual function, or the top-level execution context for a given .ck file).</blockquote>
<div><br>Thanks for the explanation, quite interesting.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think if this functionality was applied to the main ChucK branch, it could pin these random ChucK exceptions to specific line numbers, and also put ChucK on the path towards having its own debugger.<br><font color="#888888">
</font></blockquote><div><br>I would think this would be very worthwhile. Array out of bound errors are one of the most common issues for me (I'm a big fan of arrays and end up using them a lot) and they are one of the hardest to trace. I think this could be a big time saver.<br>
<br>I expect that a ChucK debugger (in general) would help in learning about ChucK as well. These days I can usually tell but I remember that in the past I was often quite insecure about whether a issue was one of my own oopses or a ChucK-bug. It's pure speculation but I suspect a ChucK debugger might help in learning to write ChucK code as well as help with the debugging of ChucK itself because of this but that's purely based on my own experiences so far from objective.<br>
<br>Yours,<br>Kas.<br></div></div><br>