For Review: Change 20081031-dda-X Summary: Fix/remove most warnings from schema builder

Bracket syntax notation in AS3

Can anyone explain to me, why `++(o['count'])` fails to compile for AS3? 
Thanks!

> <canvas>
>   <handler name="oninit" >
>     var o = {count:0};
>     if (++(o.count) == 1) Debug.write("it's one");
> //Error: Implicit coercion of a value of type String to an unrelated 
> type Number, in line: if (++$2["count"] == 2) {
> //Error: Comparison between a value with static type String and a 
> possibly unrelated type int, in line: if (++$2["count"] == 2) {
> //    if (++(o['count']) == 2) Debug.write("it's two");
> //Error: Operand of increment must be a reference, in line: if 
> (++(o["count"] as int) == 3) {
> //    if (++(o['count'] cast int) == 3) Debug.write("it's three");
> //Error: Operand of increment must be a reference, in line: if 
> (++int(o["count"]) == 4) {
> //    if (++(int(o['count'])) == 4) Debug.write("it's four");
>   </handler>
> </canvas>

Re: OpenLaszlo Event Model

I've just implemented this "new event-system" locally, and amazon-demo 
start-time was before my change by about 1350-1450ms [1], with my 
changes it was dropped to 980-1050ms. And I didn't even updated anything 
of the LFC to use the new, more effective methods...

[1] FF3 + FP10 (debug-player), demo compiled for swf9 non-debug, time 
measured with <inittimer>

On 10/29/2008 1:14 AM, André Bargull wrote:
> I've started to reconcile with that idea and made up a some code 
> snippets. IMO, there is at least one thing we definitely need to 
> change: the current for API for LzDelegate#unregisterFrom(..). At the 
> moment, the method signature is "function unregisterFrom 
> (event:LzEvent)", this needs to be parallel to 
> LzDelegate#register(..), so "function unregisterFrom 
> (target:LzEventTarget, type:String)".
> (The attached code is neither complete nor fast, I just wanted to be 
> minimalistic, but also not too abstract.)
>
>> We have an (improvement 
>> suggestion)[http://jira.openlaszlo.org/jira/browse/LPP-6034 ] to 
>> change the structure of the event system to be more efficient and  
>> more DOM-like.  I recently added a comment:
>>
>>  
>>> > What we really want to do is get more in line with 
>>> http://www.w3.org/TR/DOM-Level-2-Events/
>>> >
>>> > This would mean that LzEventable would become EventTarget, and  > 
>>> LzDelegatable [LPP-7037] would become EventListener.
>>> >
>>> > The major impact on our system is that LzEvents would no longer 
>>> be  > objects in themselves, but simply names (event types). This 
>>> could  > reduce the overhead of events, but would mean a big 
>>> incompatibility.  > Instead of:
>>> >
>>> >   <target>.<event>.sendEvent(<value>);
>>> >
>>> > you would have to say:
>>> >
>>> >   <target>.dispatchEvent(<event>, <value>);
>>> >
>>> > [In DOM2, dispatchEvent takes only an Event as its argument, the  
>>> > event is an object that has attributes such as the event name  > 
>>> (type), state, and depending on the type of the event, additional  > 
>>> information -- what we usually pass as the single <value>. If we  > 
>>> want to be more compatible, perhaps we should implement the  > 
>>> `dispatchEvent` interface and another `dispatchSimpleEvent`  > 
>>> interface that handles most of our events. Otherwise the overhead 
>>> we  > save by not having LzEvent objects to attach listeners to will 
>>> be  > replaced by allocating an Event object every time you want to 
>>> send  > an event.]
>>>     
>>
>> I'd be interested in other ideas and opinions.

Re: For Review: Change 20081030-laszlo-2 Summary: Color example 3 gives warnings.

not approved (I know, you didn't ask)

The example still prints:

3=styled by 0x0000FF

I think the second declaration should be deleted, not repeated.

  #vRGB {
     bgcolorRGB : "#0000FF";
     }

     #tRGB {
     fgcolorRGB : "#0000FF";
     }

     #vHex {
     bgcolorHex : "#0000FF";
     }

     #tHex {
     fgcolorHex : "#0000FF";
     }

On Oct 30, 2008, at 5:11 AM, J Crowley wrote:

> Change 20081030-laszlo-2 by laszlo <at> T43-L3XEXMW on 2008-10-30  
> 04:58:01 EDT
> in /home/laszlo/src/svn/openlaszlo/trunk-liquid
> for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: Color example 3 gives warnings.
>
> New Features:
>
> Bugs Fixed: LPP-7193 - Color example 3 gives warnings.
>
> Technical Reviewer: max
> QA Reviewer: promanik
> Doc Reviewer: (pending)
>
> Documentation:
>
> Release Notes:
>
> Details: Fixed the example as the warnings dictated.
> (CSS colors can't be of the format 0x000000.)
>
> Tests: Run the affected file. There should be no
> warnings about invalid color formats.
>
> Files:
> M docs/src/developers/programs/color-$3.lzx
>
> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081030-laszlo-2.tar
>
>

Re: For Review: Change 20081030-laszlo-2 Summary: Color example 3 gives warnings.

I agree.  There are 2 ways to specify a color in CSS:  a color name  
(where the name is one of the 16 css color names), or RGB.  RGB has 3  
forms:  hex (#0000ff), percent (rgb(0,0,100%)), or numbers in the  
range 0-255 (rgb(0,0,255)).  It would be nice to show all those  
possibilities.

We used to allow the kludge of specifying the color as a string that  
could be parsed as a number ('0x0000ff'), but that is not true CSS, so  
we have deprecated it.  It was really only a work-around for our  
incomplete CSS parser.

On 2008-11-01, at 13:51EDT, Lou Iorio wrote:

> not approved (I know, you didn't ask)
>
> The example still prints:
>
> 3=styled by 0x0000FF
>
> I think the second declaration should be deleted, not repeated.
>
> #vRGB {
>    bgcolorRGB : "#0000FF";
>    }
>
>    #tRGB {
>    fgcolorRGB : "#0000FF";
>    }
>
>    #vHex {
>    bgcolorHex : "#0000FF";
>    }
>
>    #tHex {
>    fgcolorHex : "#0000FF";
>    }
>
>
> On Oct 30, 2008, at 5:11 AM, J Crowley wrote:
>
>> Change 20081030-laszlo-2 by laszlo <at> T43-L3XEXMW on 2008-10-30  
>> 04:58:01 EDT
>> in /home/laszlo/src/svn/openlaszlo/trunk-liquid
>> for http://svn.openlaszlo.org/openlaszlo/trunk
>>
>> Summary: Color example 3 gives warnings.
>>
>> New Features:
>>
>> Bugs Fixed: LPP-7193 - Color example 3 gives warnings.
>>
>> Technical Reviewer: max
>> QA Reviewer: promanik
>> Doc Reviewer: (pending)
>>
>> Documentation:
>>
>> Release Notes:
>>
>> Details: Fixed the example as the warnings dictated.
>> (CSS colors can't be of the format 0x000000.)
>>
>> Tests: Run the affected file. There should be no
>> warnings about invalid color formats.
>>
>> Files:
>> M docs/src/developers/programs/color-$3.lzx
>>
>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081030-laszlo-2.tar
>>
>>
>

Re: For Review: Change 20081030-laszlo-2 Summary: Color example 3 gives warnings.

Sounds good.  I've already checked this in, but I'll revise as 
recommended and check that in.

P T Withington wrote:
> I agree.  There are 2 ways to specify a color in CSS:  a color name 
> (where the name is one of the 16 css color names), or RGB.  RGB has 3 
> forms:  hex (#0000ff), percent (rgb(0,0,100%)), or numbers in the 
> range 0-255 (rgb(0,0,255)).  It would be nice to show all those 
> possibilities.
>
> We used to allow the kludge of specifying the color as a string that 
> could be parsed as a number ('0x0000ff'), but that is not true CSS, so 
> we have deprecated it.  It was really only a work-around for our 
> incomplete CSS parser.
>
>
> On 2008-11-01, at 13:51EDT, Lou Iorio wrote:
>
>> not approved (I know, you didn't ask)
>>
>> The example still prints:
>>
>> 3=styled by 0x0000FF
>>
>> I think the second declaration should be deleted, not repeated.
>>
>> #vRGB {
>>    bgcolorRGB : "#0000FF";
>>    }
>>
>>    #tRGB {
>>    fgcolorRGB : "#0000FF";
>>    }
>>
>>    #vHex {
>>    bgcolorHex : "#0000FF";
>>    }
>>
>>    #tHex {
>>    fgcolorHex : "#0000FF";
>>    }
>>
>>
>> On Oct 30, 2008, at 5:11 AM, J Crowley wrote:
>>
>>> Change 20081030-laszlo-2 by laszlo <at> T43-L3XEXMW on 2008-10-30 
>>> 04:58:01 EDT
>>> in /home/laszlo/src/svn/openlaszlo/trunk-liquid
>>> for http://svn.openlaszlo.org/openlaszlo/trunk
>>>
>>> Summary: Color example 3 gives warnings.
>>>
>>> New Features:
>>>
>>> Bugs Fixed: LPP-7193 - Color example 3 gives warnings.
>>>
>>> Technical Reviewer: max
>>> QA Reviewer: promanik
>>> Doc Reviewer: (pending)
>>>
>>> Documentation:
>>>
>>> Release Notes:
>>>
>>> Details: Fixed the example as the warnings dictated.
>>> (CSS colors can't be of the format 0x000000.)
>>>
>>> Tests: Run the affected file. There should be no
>>> warnings about invalid color formats.
>>>
>>> Files:
>>> M docs/src/developers/programs/color-$3.lzx
>>>
>>> Changeset: 
>>> http://svn.openlaszlo.org/openlaszlo/patches/20081030-laszlo-2.tar
>>>
>>>
>>
>
>

For Review: Change 20081103-lou-B Summary: dguide, Understanding Instantiation chapter: fix typo, remove constraints restriction.

Change 20081103-lou-B by lou <at> loumac.local on 2008-11-03 11:23:07 AST
     in /Users/lou/src/svn/openlaszlo/trunk
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: dguide, Understanding Instantiation chapter: fix typo, remove  
constraints restriction.

Bugs Fixed: http://www.openlaszlo.org/jira/browse/LPP-7260

Technical Reviewer: (pending)
QA Reviewer: (pending)
Doc Reviewer: abargull

Details: remove: (does not include expressions, such width="$ 
{parent.width}")

Tests: visual verify

Files:
M      docs/src/developers/initialization-and-instantiation.dbk

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081103-lou-B.tar

Re: For Review: Change 20081103-lou-B Summary: dguide, Understanding Instantiation chapter: fix typo, remove constraints restriction.

Approved.

On 11/3/2008 4:27 PM, Lou Iorio wrote:
> Change 20081103-lou-B by lou <at> loumac.local on 2008-11-03 11:23:07 AST
>     in /Users/lou/src/svn/openlaszlo/trunk
>     for http://svn.openlaszlo.org/openlaszlo/trunk
> 
> Summary: dguide, Understanding Instantiation chapter: fix typo, remove 
> constraints restriction.
> 
> Bugs Fixed: http://www.openlaszlo.org/jira/browse/LPP-7260
> 
> Technical Reviewer: (pending)
> QA Reviewer: (pending)
> Doc Reviewer: abargull
> 
> Details: remove: (does not include expressions, such 
> width="${parent.width}")
> 
> Tests: visual verify
> 
> Files:
> M      docs/src/developers/initialization-and-instantiation.dbk
> 
> 
> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081103-lou-B.tar
> 

Re: Bracket syntax notation in AS3

I would say it is a Flex bug.  I bet their expander for ++ is just  
screwing up somehow, probably incorrectly trying to increment 'count'  
or something.  I would file a bug with Adobe.

On 2008-11-01, at 10:41EDT, André Bargull wrote:

> Can anyone explain to me, why `++(o['count'])` fails to compile for  
> AS3? Thanks!
>
>> <canvas>
>>  <handler name="oninit" >
>>    var o = {count:0};
>>    if (++(o.count) == 1) Debug.write("it's one");
>> //Error: Implicit coercion of a value of type String to an  
>> unrelated type Number, in line: if (++$2["count"] == 2) {
>> //Error: Comparison between a value with static type String and a  
>> possibly unrelated type int, in line: if (++$2["count"] == 2) {
>> //    if (++(o['count']) == 2) Debug.write("it's two");
>> //Error: Operand of increment must be a reference, in line: if (++ 
>> (o["count"] as int) == 3) {
>> //    if (++(o['count'] cast int) == 3) Debug.write("it's three");
>> //Error: Operand of increment must be a reference, in line: if (+ 
>> +int(o["count"]) == 4) {
>> //    if (++(int(o['count'])) == 4) Debug.write("it's four");
>>  </handler>
>> </canvas>
>

Re: Bracket syntax notation in AS3

Ok, I've created "http://bugs.adobe.com/jira/browse/ASC-3574".

On 11/3/2008 4:53 PM, P T Withington wrote:
> I would say it is a Flex bug.  I bet their expander for ++ is just 
> screwing up somehow, probably incorrectly trying to increment 'count' or 
> something.  I would file a bug with Adobe.
> 
> On 2008-11-01, at 10:41EDT, André Bargull wrote:
> 
>> Can anyone explain to me, why `++(o['count'])` fails to compile for 
>> AS3? Thanks!
>>
>>> <canvas>
>>>  <handler name="oninit" >
>>>    var o = {count:0};
>>>    if (++(o.count) == 1) Debug.write("it's one");
>>> //Error: Implicit coercion of a value of type String to an unrelated 
>>> type Number, in line: if (++$2["count"] == 2) {
>>> //Error: Comparison between a value with static type String and a 
>>> possibly unrelated type int, in line: if (++$2["count"] == 2) {
>>> //    if (++(o['count']) == 2) Debug.write("it's two");
>>> //Error: Operand of increment must be a reference, in line: if 
>>> (++(o["count"] as int) == 3) {
>>> //    if (++(o['count'] cast int) == 3) Debug.write("it's three");
>>> //Error: Operand of increment must be a reference, in line: if 
>>> (++int(o["count"]) == 4) {
>>> //    if (++(int(o['count'])) == 4) Debug.write("it's four");
>>>  </handler>
>>> </canvas>
>>
> 
>