On 2009-10-05, at 12:49, André Bargull wrote:
> I haven't yet tested your patch, but it looks promising. Here are my
> notes so far:
>
> - lfc/build.xml: "platformopt" is declared in the backtrace switch,
> but not used.
Okay. I removed that flag and made the swf9 back-end do the right
thing whenever nameFunctions is on.
> - lps/components/lztest/xmlequals.lzx needs to be updated, too.
Done. Wonder why we need two copies of the same thing?
> - Did you file the swf8+backtrace finally bug, just in case it's a
> broader issue?
It _is_ a broader issue. Filed (LPP-8533), but I suspect we could
drop swf8 before it is fixed.
> - I think we need to create our own workaround for the as3 finally
> +return bug, did/may you file a ticket in our JIRA?
Just now: LPP-8534
> - The "LzBacktrace.lzs" include in lfc/debugger/Library.lzs can be
> simplified, because the AS3 special case is no longer necessary.
Done.
> - lfc/debugger/platform/swf9/LzBacktrace.as can be removed now,
> can't it?
Done.
> - JavascriptGenerator: "Array.prototype.slice(arguments)" instead of
> "Array.prototype.slice(arguments, 0)" for smaller code?
See next.
> - JavascriptGenerator: rest arguments will create different
> "backtrace arguments" in AS3 compared to DHTML. The rest arguments
> need to be appended to the other
> arguments, so "[arg_1, arg_2, ..., arg_n].concat(arg_rest)" instead
> of "[arg_1, arg_2, ..., arg_n, arg_rest]".
Instead, I am going to change the way the arguments are stored to a
plist of name/value pairs. It will make the output more useful.
> - CodeGenerator: static functions capture the "this" for backtraces,
> this isn't done for DHTML and for AS3.
Fixed.
> - CodeGenerator: The analyzer runs on the backtrace annotations,
> too. Isn't this wrong according to your note?
>> Make sure only user variables are transformed, not annotations
>> introduced by the compiler.
That note was only with respect to the script body transformation,
where var's become globals. It's ok to make the annotation vars into
registers. If we were really going to fix this right, I'd have a
first pass that did all the platform-independent transformations on
Javascript and then in the second-pass do a platform-specific
transform (or byte-code generation, as CodeGenerator does). Because I
don't envision SWF8 sticking around much longer, I'm not going to work
hard on supporting that. There will be something closer two the two-
part transform coming soon, to support lzo's on other platforms.
> Later:
>
> - JavaGenerator: this is a snippet from test/lpp-8222.lzx in debug
> +backtrace+swf10:
>> var $lzsc$d_$3 = Debug;
>> var $lzsc$s_$4 = $lzsc$d_$3.backtraceStack;
>> try {
>> if ($lzsc$s_$4) {
>> var $lzsc$a_$5 = [$lzc$ignore_$1];
>> $lzsc$a_$5.callee = "handle oninit";
>> $lzsc$a_$5["this"] = this;
>> $lzsc$a_$5.filename = "lpp-8222.lzx";
>> $lzsc$a_$5.lineno = 22;
>> $lzsc$s_$4.push($lzsc$a_$5);
> The annotations are still transformed, isn't this wrong?
See above.
> I've used test/lpp-8222.lzx for testing in debug+backtrace+swf10
> (there's a bug which prevents the application from compiling in
> swf10, I'm going to fix it) and encountered the following issues:
> - the initial debug-info: "Ignore the next error" didn't show up
Hm...
> - debug eval doesn't work in all cases, e.g. 'mytest.testCatchErrors
> ()' fails with a VerifyError because of a stack underflow
Surely related to the above. This must be bombing in some way that
causes it not to run... This looks difficult so I am filing a
separate bug. (LPP-8536)
> - clicking on "throw uncaught error" and then inspecting the
> backtrace gives different results in swf10 compared to dhtml.
> DHTML: last two entries shouldn't appear, should they?
I've updated the logic for trimming the internal backtrace frames to
be more accurate by capturing the whole backtrace first and then
hiding the internal frames.
I'll send out a review request for these fixes in a bit.
_______________________________________________
Laszlo-reviews mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-reviews
