[Development] Question about Qt's future

[André Pönitz]

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'