When I look at the output, the sequence of ABC instructions generated by MXMLC should be:
Constructprop Coerce_a Jump SetProperty And for Falcon ConstructProp Jump Coerce_a SetProperty In x86 asm, a jump only moves the IP and doesn't change anything else. But for some reason, AIR (and not FlashPlayer) is sensitive to that difference. Very strange bug in AIR, IMO. Anyway, I do have Falcon generating the coerce_a where MXMLC outputs it. On 10/2/13 3:13 PM, "Darrell Loverin" <darrell.love...@gmail.com> wrote: >Nice job figuring this out! Does your change now generate the coerce_a >code in the same positions as the MXML compiler? The only difference I >saw in byte code with respect to coerce_a was a "jump L1" instruction >after (Falcon) a coerce_a instead before (mxmlc). > >mxmlc >>>>>> constructprop private:SomeClass (1) >>>>>> coerce_a >>>>>> jump L1 > >Falcon >>>>>> constructprop private:SomeClass (1) >>>>>> jump L1 >>>>>> L0: findpropstrict private:SomeOtherClass >>>>>> getlocal1 >>>>>> constructprop private:SomeOtherClass (1) >>>>>> L1: coerce_a > >Was the "jump L1" instruction before the coerce_a the issue? > > >-Darrell > >On Oct 2, 2013, at 4:24 PM, Alex Harui <aha...@adobe.com> wrote: > >> The reducer method now calls >>getAncestorOfType(IBinaryOperatorNode.class) >> and then checks if the operator is OoperatorType.ASSIGNMENT and further >> that the left node is a DynamicAccessNodel >> >> I think just checking parent isn't good enough for nested ternary >> expressions. >> >> Coerce is being called in a few other reduction methods that may take >>care >> of the other scenarios you mention. If not, we'll add calls as needed. >> >> -Alex >> >> >> On 10/2/13 1:18 PM, "Gordon Smith" <gosm...@adobe.com> wrote: >> >>> In the reducer method for the ternary expression, how do you know >>>whether >>> it going to be assigned to a foo[bar] expression? Do you look at the >>> parent node of the ternary expression? I have a feeling that that isn't >>> how JBurg is supposed to be used, but maybe you can get away with it. >>>You >>> should probably have a different JBurg pattern and reduce method just >>>for >>> this case. >>> >>> I'm also not convinced this covers all the relevant situations where a >>> coerce_a might be necessary. For example, suppose that instead of being >>> assigned to a left-hand-side of type *, the ternary expression is being >>> passed as a argument to a function that has a type * parameter. That >>> might also need a coerce_a. >>> >>> I'd put a comment in the code that this is questionable. But if it gets >>> your app further towards working, it's good. >>> >>> - Gordon >>> >>> -----Original Message----- >>> From: Alex Harui [mailto:aha...@adobe.com] >>> Sent: Wednesday, October 02, 2013 11:52 AM >>> To: dev@flex.apache.org >>> Subject: Re: [FALCON] using coerce_a >>> >>> The code only thinks about coercing if there is a bracket [] node. It >>> gets the type of the left hand side via resolveType and compares the >>> resolveType of the clause node and calls coerce if it doesn't match. >>>So >>> your example won't have a coerce_a in the ABC. >>> >>> -Alex >>> >>> On 10/2/13 11:19 AM, "Gordon Smith" <gosm...@adobe.com> wrote: >>> >>>> Does that work for ternary expressions and left-hand-sides with other >>>> types, such as >>>> >>>> var i:int = true ? 1 : 2; >>>> >>>> ? >>>> >>>> - Gordon >>>> >>>> On 10/2/13 11:01 AM, "Alex Harui" <aha...@adobe.com> wrote: >>>> >>>>> Update: Changing Falcon to generate the coerce_a in the ternary >>>>> clauses allowed it to work for AIR. The code change is only in >>>>> ternary expression reduction so I think it won't hurt performance too >>>>> much. >>>>> >>>>> -Alex >>>>> >>>>> On 10/1/13 10:09 PM, "Alex Harui" <aha...@adobe.com> wrote: >>>>> >>>>>> So, I added code to add the coerce_a and it did not help. I get the >>>>>> same corrupted output. >>>>>> >>>>>> Here is the AS: >>>>>> package { >>>>>> public class foo { >>>>>> private var dict:Dictionary = new Dictionary(); public function >>>>>> addInstance(instance:ISomeInterface):void >>>>>> { >>>>>> dict[instance.uid] = (instance.someBoolean ? new >>>>>>SomeClass(instance) : >>>>>> new SomeOtherClass(instance)); >>>>>> ... >>>>>> } >>>>>> } >>>>>> >>>>>> //internal class >>>>>> class SomeClass{ >>>>>> public function SomeClass(instance:ISomeInterface) >>>>>> { >>>>>> } >>>>>> //internal class >>>>>> class SomeOtherClass{ >>>>>> public function SomeOtherClass(instance:ISomeInterface) >>>>>> { >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Here is the ABC from MXMLC that works: >>>>>> >>>>>> >>>>>> getlocal0 >>>>>> pushscope >>>>>> getlocal0 >>>>>> getproperty private:dict >>>>>> getlocal1 >>>>>> getproperty ISomeInterface:uid >>>>>> getlocal1 >>>>>> getproperty ISomeInterface:someBoolean >>>>>> iffalse L0 >>>>>> >>>>>> findpropstrict private:SomeClass >>>>>> getlocal1 >>>>>> constructprop private:SomeClass (1) >>>>>> coerce_a >>>>>> jump L1 >>>>>> L0: findpropstrict private:SomeOtherClass >>>>>> getlocal1 >>>>>> constructprop private:SomeOtherClass (1) >>>>>> coerce_a >>>>>> L1: setproperty >>>>>> private,private,,http://adobe.com/AS3/2006/builtin:null >>>>>> >>>>>> Here is the ABC from Falcon that doesn't work: >>>>>> >>>>>> getlocal0 >>>>>> pushscope >>>>>> getlex private:dict >>>>>> getlocal1 >>>>>> getproperty ISomeInterface:uid >>>>>> getlocal1 >>>>>> getproperty ISomeInterface:someBoolean >>>>>> iffalse L0 >>>>>> >>>>>> findpropstrict private:SomeClass >>>>>> getlocal1 >>>>>> constructprop private:SomeClass (1) >>>>>> jump L1 >>>>>> L0: findpropstrict private:SomeOtherClass >>>>>> getlocal1 >>>>>> constructprop private:SomeOtherClass (1) >>>>>> L1: coerce_a >>>>>> setproperty >>>>>> >>>>>> >>>>>>private,flash.events:EventDispatcher,Object,private,,http://adobe.com >>>>>> /A >>>>>> S >>>>>> 3 >>>>>> / >>>>>> 2006/builtin:null >>>>>> >>>>>> I'm beginning to think this is an AIR bug since the Falcon ABC runs >>>>>> fine on Flash. I'm going to try to replicate the MXMLC's placement >>>>>> of coerce_a and see if that gets the code to work in AIR. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> -Alex >>>>>> >>>>>> >>>>>> >>>>>> On 9/30/13 10:50 PM, "Alex Harui" <aha...@adobe.com> wrote: >>>>>> >>>>>>> There's no error, the Dictionary value appears be a Number instead >>>>>>> of an instance. >>>>>>> >>>>>>> Are you sure that Vector access doesn't come through this code? I >>>>>>> think I'll start by testing only for ANY_TYPE and adding a coerce_a >>>>>>> instead of calling coerce() which would also coerce to any >>>>>>> destination type. >>>>>>> >>>>>>> Thanks for the advice, >>>>>>> -Alex >>>>>>> ________________________________________ >>>>>>> From: Darrell Loverin [darrell.love...@gmail.com] >>>>>>> Sent: Monday, September 30, 2013 6:11 PM >>>>>>> To: dev@flex.apache.org >>>>>>> Subject: Re: [FALCON] using coerce_a >>>>>>> >>>>>>> I generally agree. I don't think I'd try to do anything inside the >>>>>>> ternary expression reduce. >>>>>>> >>>>>>> I'd look at the coerce() method in ABCGeneratingReducer to try to >>>>>>> figure out why it is not being called. >>>>>>> >>>>>>> >>>>>>> Question for Alex. What error are you seeing on AIR? A TypeError, a >>>>>>> ReferenceError? >>>>>>> >>>>>>> -Darrell >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 30, 2013 at 8:00 PM, Gordon Smith <gosm...@adobe.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks Darrell. >>>>>>>> >>>>>>>> Here are my answers to Alex's questions: >>>>>>>> >>>>>>>>> Should a complex assignment statement like the above know about >>>>>>>>> the >>>>>>>> destination type as the clauses of the ternary statement are being >>>>>>>> reduced? >>>>>>>> >>>>>>>> No. >>>>>>>> >>>>>>>>> Is it safe to add a coerce_a before an assignment to a >>>>>>>>>Dictionary? >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>>> If so, what would be the recommended way to determine the >>>>>>>> assignment >>>>>>>> is >>>>>>>> to a Dictionary? >>>>>>>> >>>>>>>> The compile-time type of foo[bar], where foo has any type (not >>>>>>>> just Dictionary), is type *. So I think it is OK to codegen >>>>>>>> coerce_a before assignment to any foo[bar] expression. >>>>>>>> >>>>>>>> Darrell, do you agree or disagree? >>>>>>>> >>>>>>>> - Gordon >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Darrell Loverin [mailto:darrell.love...@gmail.com] >>>>>>>> Sent: Monday, September 30, 2013 3:41 PM >>>>>>>> To: dev@flex.apache.org >>>>>>>> Subject: Re: [FALCON] using coerce_a >>>>>>>> >>>>>>>> coerce_a Operation >>>>>>>> >>>>>>>> Coerce a value to the any type. >>>>>>>> >>>>>>>> Format >>>>>>>> >>>>>>>> coerce_a >>>>>>>> >>>>>>>> Forms >>>>>>>> >>>>>>>> Stack >>>>>>>> >>>>>>>> ..., value => ..., value Description >>>>>>>> >>>>>>>> Indicates to the verifier that the value on the stack is of the >>>>>>>> any type (*). Does nothing to value. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Sep 30, 2013 at 6:03 PM, Gordon Smith <gosm...@adobe.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Can you remind me what the "a" in coerce_a means? >>>>>>>>> >>>>>>>>> - Gordon >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alex Harui [mailto:aha...@adobe.com] >>>>>>>>> Sent: Monday, September 30, 2013 2:43 PM >>>>>>>>> To: dev@flex.apache.org >>>>>>>>> Subject: [FALCON] using coerce_a >>>>>>>>> >>>>>>>>> Gordon, Darrell (mostly) >>>>>>>>> >>>>>>>>> My latest problem appears to be in assigning to a Dictionary. >>>>>>>>> For >>>>>>>> the >>>>>>>>> following code: >>>>>>>>> >>>>>>>>> var dict:Dictionary = new Dictionary(); Var i:int; Dict["foo"] = >>>>>>>>> (i >>>>>>>> == >>>>>>>>> 0 ? new SomeClass() : new SomeOtherClass()); >>>>>>>>> >>>>>>>>> MXMLC generates a coerce_a after the constructProp for both >>>>>>>> SomeClass >>>>>>>>> and SomeOtherClass. >>>>>>>>> For some reason, FlashPlayer doesn't care if the coerce_a is >>>>>>>> missing, >>>>>>>>> but AIR seems to. >>>>>>>>> >>>>>>>>> The question is, should a complex assignment statement like the >>>>>>>> above >>>>>>>>> know about the destination type as the clauses of the ternary >>>>>>>>> statement are being reduced? And if so, how would we get that >>>>>>>> knowledge >>>>>>>> into the reducer. >>>>>>>>> >>>>>>>>> Alternatively, is it safe to add a coerce_a before an assignment >>>>>>>>> to >>>>>>>> a >>>>>>>>> Dictionary? If so, what would be the recommended way to >>>>>>>>> determine >>>>>>>> the >>>>>>>>> assignment is to a Dictionary? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -Alex >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >
