Re: [FlexJS] super method calls broken?

[Alex Harui]

Oh, make sure you've deleted the frameworks/js/FlexJS/generated-sources
folder from your repo working copy.  The build may not delete or overwrite
it, so maybe you have stale JS files in it that your old script copied.

-Alex

On 10/13/16, 9:21 AM, "Harbs"  wrote:

>It could also be that our scripts re-created the generated-sources folder
>which is why it wasn’t working.
>
>Thanks for the info. We’ll see if that does it…
>
>It think all-inclusive SWCs is a step in the right direction. Growing
>pains… ;-)
>
>On Oct 13, 2016, at 7:11 PM, Alex Harui  wrote:
>
>> 
>> 
>> On 10/13/16, 8:26 AM, "Harbs"  wrote:
>> 
>>> We tried restarting FB multiple times. It didn’t help.
>>> 
>>> Copying the SWCs did not help either. It still took the JS from the
>>> original location.
>> 
>> Ah yes, the generated-sources folder of JS files has priority so folks
>>can
>> monkey patch.  Delete the generated-sources folder from your SDK folder
>> unless you have a monkey-patch.  When did you last pull a nightly build?
>> The nightly should no longer have a generated-sources folder (I just
>> checked and it doesn't), and then just updating SWCs should do the
>>trick.
>> 
>>> 
>>> Is there some trick to make the compiler use the JS files in the SWCs?
>>> What makes the compiler decide where to get the JS files from?
>>> 
>>> We tried re-importing the build configurations, but that didn’t help
>>> either.
>>> 
>>> Maybe we did not copy some falcon file correctly, but I think the
>>>nightly
>>> was a recent one.
>> 
>> It sounds like your nightly was the last one before we removed the
>> generated-sources folder.  Might just be bad luck with timing.
>> 
>> -Alex
>> 
>

Re: [FlexJS] super method calls broken?

[Alex Harui]

On 10/13/16, 8:26 AM, "Harbs"  wrote:

>We tried restarting FB multiple times. It didn’t help.
>
>Copying the SWCs did not help either. It still took the JS from the
>original location.

Ah yes, the generated-sources folder of JS files has priority so folks can
monkey patch.  Delete the generated-sources folder from your SDK folder
unless you have a monkey-patch.  When did you last pull a nightly build?
The nightly should no longer have a generated-sources folder (I just
checked and it doesn't), and then just updating SWCs should do the trick.

>
>Is there some trick to make the compiler use the JS files in the SWCs?
>What makes the compiler decide where to get the JS files from?
>
>We tried re-importing the build configurations, but that didn’t help
>either.
>
>Maybe we did not copy some falcon file correctly, but I think the nightly
>was a recent one.

It sounds like your nightly was the last one before we removed the
generated-sources folder.  Might just be bad luck with timing.

-Alex

Re: [FlexJS] super method calls broken?

[Alex Harui]

On 10/13/16, 6:49 AM, "yishayw"  wrote:

>The key was indeed to recompile all packages, which generates the correct
>get/set functions along the chain of inheritance. The hard part was
>understanding where the js files were being generated but I'll elaborate
>on
>a different thread.

IMO, if you think you've pulled new compiler changes, it is a best
practice to re-compile all of the code.

Thanks,
-Alex

Re: [FlexJS] super method calls broken?

[Alex Harui]

Sorry about breaking your workflow.  It didn't occur to me that folks were
trying to update a FlexJS SDK by copying in JS files from a repo.  That
would only work if you know you didn't change any AS code paths.  IMO,
there are only two workflows I can think of that should work in all cases:

1) Shut down Flash Builder, copy in SWCs, re-open Flash Builder.
2) Don't use SWCs from a FlexJS SDK and set up the SWCs as library
projects in FB.

There may be issues with #2, but IMO, we should iron out the kinks in that
workflow as it is probably going to be the optimal one.

If you really want output JS files again, we could add another ant target
that generates them.  The compiler still knows how, you just have to
specify an output folder instead of an output swc.

I'll be looking at your other issues today.

-Alex

On 10/13/16, 2:05 AM, "Harbs"  wrote:

>We finally managed to get our project to build by extracting the js files
>from the SWC and copying them to where the JS files used to be in the
>nightly which we are building against.
>
>That’s a pretty poor work-around. We need instructions on how to get the
>new SWCs to work in Flash Builder.
>
>Thanks,
>Harbs
>
>On Oct 13, 2016, at 11:24 AM, Harbs  wrote:
>
>> It doesn’t “just work”. We’re having a lot of trouble figuring out
>>everything that changed.
>> 
>> This is really frustrating. We’ve wasted a couple of days chasing our
>>tails dues to things changing.
>> 
>> I don’t see any js files being generated in the latest version of
>>develop. I know there as some discussion about changing the JS SWCs for
>>easier use of libraries. Did that change using the Framework? We have
>>scripts which copy updated asjs files to use while we’re developing, but
>>they don’t seem to work anymore.
>> 
>> Right now, we cannot get anything done because we can’t get asjs to
>>compile and work right… :-(
>> 
>> On Oct 13, 2016, at 9:21 AM, Alex Harui  wrote:
>> 
>>> 
>>> 
>>> On 10/12/16, 11:12 PM, "Harbs"  wrote:
>>> 
 I obviously have not been following well enough.
 
 What was the reason for this change?
>>> 
>>> Lizhi found that the previous way of accessing the super setter or
>>>getter
>>> was significantly slower.
>>> 
>>> 
>>> But if everything was compiled with the same version of the compiler,
>>>it
>>> should "just work".
>>> 
>>> -Alex
>>> 
>> 
>

Re: [FlexJS] super method calls broken?

[yishayw]

The key was indeed to recompile all packages, which generates the correct
get/set functions along the chain of inheritance. The hard part was
understanding where the js files were being generated but I'll elaborate on
a different thread.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-super-method-calls-broken-tp55727p55742.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] super method calls broken?

[Harbs]

We finally managed to get our project to build by extracting the js files from 
the SWC and copying them to where the JS files used to be in the nightly which 
we are building against.

That’s a pretty poor work-around. We need instructions on how to get the new 
SWCs to work in Flash Builder.

Thanks,
Harbs

On Oct 13, 2016, at 11:24 AM, Harbs  wrote:

> It doesn’t “just work”. We’re having a lot of trouble figuring out everything 
> that changed.
> 
> This is really frustrating. We’ve wasted a couple of days chasing our tails 
> dues to things changing.
> 
> I don’t see any js files being generated in the latest version of develop. I 
> know there as some discussion about changing the JS SWCs for easier use of 
> libraries. Did that change using the Framework? We have scripts which copy 
> updated asjs files to use while we’re developing, but they don’t seem to work 
> anymore.
> 
> Right now, we cannot get anything done because we can’t get asjs to compile 
> and work right… :-(
> 
> On Oct 13, 2016, at 9:21 AM, Alex Harui  wrote:
> 
>> 
>> 
>> On 10/12/16, 11:12 PM, "Harbs"  wrote:
>> 
>>> I obviously have not been following well enough.
>>> 
>>> What was the reason for this change?
>> 
>> Lizhi found that the previous way of accessing the super setter or getter
>> was significantly slower.
>> 
>> 
>> But if everything was compiled with the same version of the compiler, it
>> should "just work".
>> 
>> -Alex
>> 
> 

Re: [FlexJS] super method calls broken?

[Harbs]

It doesn’t “just work”. We’re having a lot of trouble figuring out everything 
that changed.

This is really frustrating. We’ve wasted a couple of days chasing our tails 
dues to things changing.

I don’t see any js files being generated in the latest version of develop. I 
know there as some discussion about changing the JS SWCs for easier use of 
libraries. Did that change using the Framework? We have scripts which copy 
updated asjs files to use while we’re developing, but they don’t seem to work 
anymore.

Right now, we cannot get anything done because we can’t get asjs to compile and 
work right… :-(

On Oct 13, 2016, at 9:21 AM, Alex Harui  wrote:

> 
> 
> On 10/12/16, 11:12 PM, "Harbs"  wrote:
> 
>> I obviously have not been following well enough.
>> 
>> What was the reason for this change?
> 
> Lizhi found that the previous way of accessing the super setter or getter
> was significantly slower.
> 
> 
> But if everything was compiled with the same version of the compiler, it
> should "just work".
> 
> -Alex
> 

Re: [FlexJS] super method calls broken?

[Alex Harui]

On 10/12/16, 11:12 PM, "Harbs"  wrote:

>I obviously have not been following well enough.
>
>What was the reason for this change?

Lizhi found that the previous way of accessing the super setter or getter
was significantly slower.


But if everything was compiled with the same version of the compiler, it
should "just work".

-Alex

Re: [FlexJS] super method calls broken?

[Harbs]

I obviously have not been following well enough.

What was the reason for this change?

On Oct 13, 2016, at 8:52 AM, Alex Harui  wrote:

> Getters and Setters should now generate a get__ and set__ method.  So on
> your class A if you have:
> 
>  override public function set visible(value:Boolean):void
> 
> You should get:
> 
>  A.prototype.set__visible(value)
> 
> Super calls should then generate calls to base so
> 
>  super.visible = value;
> 
> Should produce:
> 
>  A.base(this, 'set__visible', value);
> 
> If that is all true, next step is to debug into the base() call.  I
> thought base() knew how to look up through the chain of ancestor classes
> and didn't expect that the super call was on the immediate ancestor.  A
> workaround might be to temporarily inject an override on each ancestor
> class.
> 
> Or if Core hasn't been re-compiled recently, then there won't be a
> set__visible call in it for base() to find.
> 
> HTH,
> -Alex
> 
> On 10/12/16, 10:11 PM, "yishayw"  wrote:
> 
>> On the JS side I'm getting
>> 
>> base.js:2498 Uncaught TypeError: Cannot read property 'apply' of undefined
>> 
>> For this line in base.js:
>> 
>> return parentCtor.prototype[methodName].apply(me, args);
>> 
>> where methodName is set__visible
>> 
>> The AS code is:
>> 
>>  super.visible = value;
>> 
>> for a method in class A which extends class B which extends
>> GraphicContainer
>> which extends UIBase
>> 
>> I'm using nightly build falcon from 2 days ago.
>> 
>> Any ideas?
>> 
>> Thanks 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://apache-flex-development.247.n4.nabble.com/FlexJS-super-method-c
>> alls-broken-tp55727.html
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
> 

Re: [FlexJS] super method calls broken?

[Alex Harui]

Getters and Setters should now generate a get__ and set__ method.  So on
your class A if you have:

  override public function set visible(value:Boolean):void
  
You should get:

  A.prototype.set__visible(value)

Super calls should then generate calls to base so

  super.visible = value;

Should produce:

  A.base(this, 'set__visible', value);

If that is all true, next step is to debug into the base() call.  I
thought base() knew how to look up through the chain of ancestor classes
and didn't expect that the super call was on the immediate ancestor.  A
workaround might be to temporarily inject an override on each ancestor
class.

Or if Core hasn't been re-compiled recently, then there won't be a
set__visible call in it for base() to find.

HTH,
-Alex

On 10/12/16, 10:11 PM, "yishayw"  wrote:

>On the JS side I'm getting
>
>base.js:2498 Uncaught TypeError: Cannot read property 'apply' of undefined
>
>For this line in base.js:
>
>return parentCtor.prototype[methodName].apply(me, args);
>
>where methodName is set__visible
>
>The AS code is:
>
>   super.visible = value;
>
>for a method in class A which extends class B which extends
>GraphicContainer
>which extends UIBase
>
>I'm using nightly build falcon from 2 days ago.
>
>Any ideas?
>
>Thanks 
>
>
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-super-method-c
>alls-broken-tp55727.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.