[haXe] Stack traces in Flash target

[Asger Ottar Alstrup]

On 4/27/06, Nicolas Cannasse <ncannasse at motion-twin.com> wrote:

> Something possible right now : you can easily know the place where the
> exception occured by using the "here" identifier or the haxe.PosInfos
> structure (see http://haxe.org/tutos/trace)


Yes, I use that already, but without the trace, it is not enough information
to find the problems...

Stack traces would be nice for debugging. It put them on the same list
> than runtime exceptions handling since they are debug-features that
> can't be kept for a normal build. The Flash Player doesn't enable access
> to the stack so some specific code need to be generated for *each call*:
>
> _global.__stack.push(4564); // stack identifier
> var _tmp = this.myMethod();
> _global.__stack.pop();
> _tmp
>
> With the appropriate code for try...catch that will mark the __stack
> position, and a big Array for File and Line informations.
>
> That would easily multiply the size of the SWF by 3 or 4 and slow it
> down by a significant factor. Doable, but a bit painful :)


Yes, but definately worth it.

Consider also the following :
>
> - you can test your pure haXe (crossplatform) code logic on the Neko
> platform which directly provide both runtime exceptions and stack traces.


Except that I rely on large parts of the Flash API, and the application will
not work without those APIs. We need correct return values for widths and
heights of texts, for instance, as well as keyboard and mouse input.


> - some of theses features will be part of the Flash 9 Player, I would
> prefer to spend time working on supporting this platform.


But Flash 9 will have another API, so this will not help unless a
compatibility API is made first. It will take at least a month or two before
this becomes a reality...

I understand that you have other priorities.

Can you give some pointers to the code, such that I could have a go at
implementing stack traces myself as you sketch above? For me and my
coworkers, the investment to implement this will pay off quickly, because we
waste hours every day looking for such simple bugs.

If not, I guess the fallback is to implement our own stack traces by
transforming all functions like this:

  function myFunction(a, b, c) {
    Trace.enter(here);

    ...

   if (...) {
    Trace.exit(here);
    return;
   }

   Trace.exit(here);
 }

This is doable, and we can use conditional compilation to make sure that
these Trace calls are no-ops in non-debug builds. But we would like to avoid
the runtime penalty of the function calls in release builds, so can haXe
optimise no-op functions and calls away?

Regards,
Asger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20060427/07b15835/attachment.htm