On Wed, Mar 11, 2009 at 12:20 PM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: > > GDB is designed for any language it has maintainers for (just like FPC is > "designed" for all platforms that have active maintainers, and languishes or
Probably true, but it's leans a lot more to C/C++ support than any other language. > DWARF is much more than the "flavour of the month". It's a very generic > debug format, which is also specifically defined as vendor-extensible. I downloaded the latest DWARF3 spec - last updated in December 2005. Quite a while back. Is this good or bad? Or is the DWARF3 spec so good/flexible it caters for any new language features since 2005? > This is correct, although it's not because the GDB guys hate or don't care > about Pascal. In fact, they are always very welcoming and helpful when > someone submits a patch for any language (in correcting errors/making it Umm, and that means I have to go back and study C language again. I left C/C++ for a reason. Object Pascal is a much better language in my eyes, and I'm a lot more productive with the latter as well! > Not to mention that in many real world projects (at least on Mac OS X), a > debugger is pretty useless if it does not also support C, C++ and > Objective-C (there's a lot of mixed language development on Mac OS X). Well, I only work with the Free Pascal Compiler (and occasionally dab in Java). This issue I am raising relates directly to Free Pascal Compiler and the Object Pascal language, so I don't give a toss about any other languages or supporting them. After all, they have GDB. ;-) >> * Tooltip evaluation of highlighted code gives "no such symbol in >> context" errors > ... > c) bugs in the tooltip feature? (does it work if you try to get the value in > another way?) It always works if I use log files. :-) > And of course "Also remember that it would be dangerous to call the function > from the debugger (outside the normal flow of the application). This can > modify the state of the application (a function may change other objects)" > cannot be solved by any debugger (even if you'd take a complete snapshot to > restore afterwards or did that in a forked version of the process, I/O > related things could still change the state in a non-reversible/sandboxed > way). Again, I never heard a single Delphi developer complain about debugging properties with or without accessor methods. So what did Borland do different? Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
