On 3/1/2012 3:56 PM, Loup Vaillant wrote:
Le 01/03/2012 22:58, Casey Ransberger a écrit :
Below.
On Feb 29, 2012, at 5:43 AM, Loup Vaillant<l...@loup-vaillant.fr> wrote:
Yes, I'm aware of that limitation. I have the feeling however that
IDEs and debuggers are overrated.
When I'm Squeaking, sometimes I find myself modeling classes with the
browser but leaving method bodies to 'self break' and then write all
of the actual code in the debugger. Doesn't work so well for hacking
on the GUI, but, well.
Okay I take it back. Your use case sounds positively awesome.
I'm curious about 'debuggers are overrated' and 'you shouldn't need
one.' Seems odd. Most people I've encountered who don't use the
debugger haven't learned one yet.
Spot on. The only debugger I have used up until now was a semi-broken
version of gdb (it tended to miss stack frames).
yeah...
sadly, apparently the Visual Studio debugger will miss stack frames,
since it apparently often doesn't know how to back-trace through code in
areas it doesn't have debugging information for, even though presumably
pretty much everything is using the EBP-chain convention for 32-bit code
(one gets the address, followed by question-marks, and the little
message "stack frames beyond this point may be invalid").
a lot of time this happens in my case in stack frames where the crash
has occurred in code which has a call-path going through the BGBScript
VM (and the debugger apparently isn't really sure how to back-trace
through the generated code).
note: although I don't currently have a full/proper JIT, some amount of
the execution path often does end up being through generated code (often
through piece-wise generate code fragments).
ironically, in AMD Code Analyst, this apparently shows up as "unknown
module", and often accounts for more of the total running time than does
the interpreter proper (although typically still only 5-10%, as the bulk
of the running time tends to be in my renderer and also in "nvogl32.dll"
and "kernel.exe" and similar...).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
