Thanks to you and Max and Henry. We've been able to resolve 24 issues
as a result of this scrub.
jim
On Sep 7, 2006, at 4:52 AM, P T Withington wrote:
> [I've added my annotations to max's]
>
> On 2006-09-07, at 02:58 EDT, Max Carlson wrote:
>
>>
>>
>> Jim Grandy wrote:
>>> Below are some questions about Legals bugs. Legals folks, please
>>> scan
>>> this list and provide answers for any you know about.
>>>
>>> jim
>>>
>>>
>>> LPP-98 - Compiler source-source transformations should be in
>>> separate
>>> phase -- Hasn't this been done?
>
> Not done. Close, but not done. Need to remodularize
> JavascriptGenerator and CodeGenerator.
>
>>> LPP-160 - Replace callInherited by bytecode -- either this is
>>> already
>>> done or we defer post-Legals.
>
> Not done. This task is to use the SWF8 SUPER byte-code, which we
> have not done, although callInherited has been made significantly
> faster. I have not done the analysis to determine the feasibility
> of this task. Surely it would want to be done for SWF9.
>
>>> LPP-440 - Compilation Manager does not manage debugger -- Still
>>> valid
>
> Still valid.
>>> LPP-786 - add if (!$debug) {} compiler directive -- Still valid?
>
> Still valid.
>
>>> LPP-928 - Remove LzTransformer -- Hasn't this been done?
>>
>> I did this some time ago...
>>
>>> LPP-930 - add support for 'class' keyword -- Hasn't this been done
>
> Resolved as duplicate of LPP-2301 Make it possible to remove
> compatibility layer
>
>>> LPP-931 - add "JavaScript" back end to compiler - Hasn't this
>>> been done
>
> Resolved as duplicate of LPP-1367: 'Stage 1: ECMA3: Make fully-
> compliant ECMA3 fronten and LPP-1302 'Emit constraints as ECMA
> instead of bytecode'
>
>>> LPP-1326 - Pass list of events to runtime -- Isn't this Invalid now?
>>
>> This is invalid/has been done manually.
>>
>>> LPP-1352 - ECMA4: Implement classes -- Hasn't this been done?
>
> Resolved as duplicate of LPP-2301 Make it possible to remove
> compatibility layer
>
>>> LPP-1420 - DHTML kernel: Implement display node -- What's this
>>> about?
>>
>> It's a basic view. Done some time ago.
>>
>>> LPP-1421 - DHTML kernel: Multiframe resources -- Hasn't this been
>>> done?
>>
>> Also done a while ago.
>>
>>> LPP-1542 - Build mini-lfc with script compiler, emit individual
>>> files
>>> for debugging -- Done, right?
>
> Not done, but perhaps invalid? This was to get better error
> reporting from the browser javascript debuggers, which I don't
> think we need any more. (What we and dojo would _really_ like is
> for browser Javascript to support #file and #line directives.)
>
>>> LPP-1545 - Compile-time warnings for runtime-specific features --
>>> Still valid?
>>
>> This still needs to be done - the current requires/provides
>> implementation only handles runtime warnings...
>>
>>> LPP-1555 - Investigate loader in AJAX -- Still valid?
>>
>> Invalid now...
>>
>>> LPP-1641 - syntax error while compiling LFCdhtml -- Hasn't this been
>>> done?
>
> Resolved as Duplicate of LPP-969 "Implement 'in' operator"
>
>>> LPP-1915 - setAttribute should not call sendEvent if there are no
>>> listenters -- Surely this is resolved? Or is it essentially the same
>>> as LPP-2065?
>
> This is an optimization that still should be done. And should be
> done for 2065 (inline setAttribute) too.
>
>>> LPP-1933 - Compiler does not scope #pragma to compile-time
>>> conditional block -- Did this get resolved?
>
> Assign to me to verify.
>
>>> LPP-1946 - logdebug has rotted -- Either fixed, or folks are getting
>>> by. Defer?
>>>
>>> LPP-1987 - Make all wrappers standards compliant -- The first
>>> part of
>>> this is done, no?
>
> We need a thorough pass through all the wrappers. This could be a
> QA task, probably should be part of the standard release test plan.
>
>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> [email protected]
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> [email protected]
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
