On Fri, Feb 16, 2001 at 09:30:50PM +0000, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote:
> > I think he meant that using a symbolic debugger is hard, not that it
> > wouldn't work. After all, when GDB is tell you that:
> > (*fooz).blazt[10].mark[0]->set(fungle(10));
> > Is causing a seg fault and all you wrote was:
> > $fooz->set(10);
> > You've got to get pretty smart to figure out what's going south.
Yes, that's what I meant. Why didn't I actually write out the explanation?
(that was why I said "mix well" rather than "mix" (at all))
Having C source full of macros (or FORTRAN source with somme custom
preprocessing, thinking about a previous job) and a symbolic debugger
saying "it went SEGV here:
FROB(BNARFL(3));
" without actually seeing the clean language source is not easy to follow.
For example, as BNARFL is a macro, you can't ask the debugger to
call BNARFL(3) and see what you get back.
> Oh, I see what you mean. Yeah, my use of the word "macro" was misleading
> there. I'm thinking more of "template".
Cool. More like XS, by which I mean XS makes a C file, and the C file is
there for you to read while debugging, rather than just the XS file.
[but this isn't a great example as it's chock full o' pre-processor macros,
which are the sort of thing that then makes symbolic debugging hard]
> Very, very, very rough example so you get the idea:
[reassuring example]
> The real benefit would be that the Perl program would know about all the
> methods and be able to automatically construct the vtable definitions and
> the relevant enum's, and that all the system-specific crap wouldn't show up in
> the generated C files, so they'd actually be *easier* to handle.
Cool. I'd been failing to understand that the intent was to make human
readable C files (as opposed to obfuscation for cpp)
Nicholas Clark
