On Thu, Apr 24, 2014 at 09:47:50AM +0200, Simon Hausmann wrote: > Let's turn this from a blame game into something more productive.
I will simply assume this includes the readiness to re-consider some of the non-technical decisions of the past. > The nature of the beast is that we do have two language environments here > and they do (and can't) share the same stack, so stack traces will always > be separate. There are two separate issues here: 1. The requirement to have two sources of stack frames, and 2. the specific setup of the JS stack extraction machinery. Re 1: It is possible to get a single unified stack trace using standard tools an application that's wildly mixing languages (in case of GDB e.g. C++, C, Fortran, ADA, D, Modula 2 and a few others) _on the same stack_ _out of the box_. Such a single frame source is ideal from a tooling perspective as it allows complete re-use of standard debugging and profiling tools, as well as free integration into platform native IDEs like Visual Studio or Xcode. We could get there, but that would require de-emphasizing the importance of JavaScript in the QML/JS conglomerate, i.e. primarily targeting a "Pure-Declarative-UI plus C++-Core scenario". I understand that you don't want that, but being able to re-use standard tools is the only feasible long-term approach. Re 2: The two sources of stack frames can be worked with in certain setups: There are examples to e.g. extract data from a mixed C++/Python setup using GDB (quick search finds https://fedoraproject.org/wiki/Features/EasierPythonDebugging, but I think I saw something more complete once). Some problems remain: - "Certain setups": To make that work cross-platform such an integration would be needed for all widely used native debugging backends (currently GDB, CDB, LLDB) i.e. at least tripled work for us - and that's already assuming the CDB calling restrictions don't interfere, i.e. it is possible at all) - The stack interweaving requires active IDE support, or at least some layer on top of two language-specific frame extraction machineries. We can do that with some effort for Qt Creator. There might be some kind people repeating that work for KDevelop, and possibly some others, at some time. VS? Unlikely. Xcode? No chance. [- At least at V8 times (I really haven't looked at V4 yet, I understand it should be less of an issue there), JS stack extraction required the JS engine to "run", while the C++ side needed to be "stopped" to get their respective frames. This requires extra co-ordination on the IDE side and rules out debugging scenarios like "post mortem"/"core files" which are rather common for non-trivial applications.] - Repeat for profiling. And any other kind of project analysis. All in all, the cases where "mixed stacks" really work well are very limited and even those cases come with a steep price tag. Which brings me back to #1: The only reasonable, long-term feasible approach is one that allows the direct re-use of standard tools. Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
