Re: [FalconJX] yet another one

[Alex Harui]

I pushed changes that should fix this.

On 3/7/17, 2:08 PM, "Harbs"  wrote:

>The other one is the problem:
>
>super.replaceChildren.apply(this, applyParams);
>
>Becomes:
>.replaceChildren.apply(this, applyParams);
>
>The “super” just drops out…
>
>My workaround attempts were in the AS3, nit the JS output.
>
>> On Mar 7, 2017, at 11:37 PM, Alex Harui  wrote:
>> 
>> The output JS looks ok to me.
>> 
>> AS:
>> super.replaceChildren(termIdx, termIdx+1);
>> 
>> 
>> JS:
>> 
>>org.apache.flex.textLayout.elements.ParagraphElement.superClass_.replaceC
>>hi
>> ldren.apply(this, [ termIdx, termIdx + 1] );
>> 
>> 
>> I could be wrong, but I thought there is no "super" in ES5.
>> 
>> Does it not work correctly?  Are you getting Closure Compiler issues or
>> runtime issues?
>> 
>> -Alex
>> 
>> On 3/7/17, 1:21 PM, "Harbs" >> wrote:
>> 
>>> I tried the following two workarounds and neither one worked:
>>> 
>>> super["replaceChildren"].apply(this, applyParams);
>>> 
>>> var func:Function = super.replaceChildren;
>>> func.apply(this, applyParams);
>>> 
 On Mar 7, 2017, at 11:13 PM, Harbs  wrote:
 
 Most of the other ones are “nice to fix”, but have been not too bad to
 work around.
 
 This one seems more serious to me. (i.e. I’m not sure how to work
 around it.)
 
 The “super” dropped off in the Javascript, and I don’t know why.
 
 https://paste.apache.org/FpNl 
>
 
 Harbs
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Alex Harui]

OK.  I'll take care of it.

On 3/7/17, 10:11 PM, "Greg Dove"  wrote:

>Yes, I think they are errors with the tests.
>
>iirc it was
>
>
>
>
>
>or something like that. So I think the new code is picking up the right
>things :)
>
>I am struggling for time right now, if you have time that would be
>fantastic, otherwise I will try to get to it later tonight.
>
>
>
>
>
>
>
>On Wed, Mar 8, 2017 at 7:06 PM, Alex Harui  wrote:
>
>> Greg,
>>
>> I just realized that these might be legitimate errors.  I can fix them
>>if
>> you don't have time.
>>
>> -Alex
>>
>> On 3/7/17, 1:32 PM, "Alex Harui"  wrote:
>>
>> >
>> >
>> >On 3/7/17, 1:04 PM, "Greg Dove"  wrote:
>> >
>> >>I had never run those tests specifically - I was not even aware of
>>those
>> >>yet, the unit tests run during ant all build had proceeded without
>> >>problems:
>> >
>> >There are three sets of unit tests.  Because the compiler is needed to
>> >build the AS framework, we can't have the compiler tests require the AS
>> >framework, so the set of tests that runs automatically don't have any
>>AS
>> >framework dependencies, then there is a set of tests with flex-sdk
>> >dependencies and one with flex-asjs dependencies, which is what you
>>just
>> >ran.
>> >
>> >Ignore the "Unable to parse" for now.
>> >
>> >IMO, no need to revert the changes.  I've got plenty of other things to
>> >do.
>> >
>> >Thanks for digging into it.
>> >-Alex
>> >
>>
>>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

Yes, I think they are errors with the tests.

iirc it was





or something like that. So I think the new code is picking up the right
things :)

I am struggling for time right now, if you have time that would be
fantastic, otherwise I will try to get to it later tonight.







On Wed, Mar 8, 2017 at 7:06 PM, Alex Harui  wrote:

> Greg,
>
> I just realized that these might be legitimate errors.  I can fix them if
> you don't have time.
>
> -Alex
>
> On 3/7/17, 1:32 PM, "Alex Harui"  wrote:
>
> >
> >
> >On 3/7/17, 1:04 PM, "Greg Dove"  wrote:
> >
> >>I had never run those tests specifically - I was not even aware of those
> >>yet, the unit tests run during ant all build had proceeded without
> >>problems:
> >
> >There are three sets of unit tests.  Because the compiler is needed to
> >build the AS framework, we can't have the compiler tests require the AS
> >framework, so the set of tests that runs automatically don't have any AS
> >framework dependencies, then there is a set of tests with flex-sdk
> >dependencies and one with flex-asjs dependencies, which is what you just
> >ran.
> >
> >Ignore the "Unable to parse" for now.
> >
> >IMO, no need to revert the changes.  I've got plenty of other things to
> >do.
> >
> >Thanks for digging into it.
> >-Alex
> >
>
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Alex Harui]

Greg,

I just realized that these might be legitimate errors.  I can fix them if
you don't have time.

-Alex

On 3/7/17, 1:32 PM, "Alex Harui"  wrote:

>
>
>On 3/7/17, 1:04 PM, "Greg Dove"  wrote:
>
>>I had never run those tests specifically - I was not even aware of those
>>yet, the unit tests run during ant all build had proceeded without
>>problems:
>
>There are three sets of unit tests.  Because the compiler is needed to
>build the AS framework, we can't have the compiler tests require the AS
>framework, so the set of tests that runs automatically don't have any AS
>framework dependencies, then there is a set of tests with flex-sdk
>dependencies and one with flex-asjs dependencies, which is what you just
>ran.
>
>Ignore the "Unable to parse" for now.
>
>IMO, no need to revert the changes.  I've got plenty of other things to
>do.
>
>Thanks for digging into it.
>-Alex
>

[4.16.0] # Apache Flex SDK 4.16.0 nightly build 252: Successful

[flex . ci . builds]

flex-sdk_release-candidate - Build #252 - Successful

Changes since last build:
No changes

For more information, check the console output at 
http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_release-candidate/252/.

Re: [FalconJX] yet another one

[Harbs]

The other one is the problem:

super.replaceChildren.apply(this, applyParams);

Becomes:
.replaceChildren.apply(this, applyParams);

The “super” just drops out…

My workaround attempts were in the AS3, nit the JS output.

> On Mar 7, 2017, at 11:37 PM, Alex Harui  wrote:
> 
> The output JS looks ok to me.
> 
> AS:
> super.replaceChildren(termIdx, termIdx+1);
> 
> 
> JS:
> org.apache.flex.textLayout.elements.ParagraphElement.superClass_.replaceChi
> ldren.apply(this, [ termIdx, termIdx + 1] );
> 
> 
> I could be wrong, but I thought there is no "super" in ES5.
> 
> Does it not work correctly?  Are you getting Closure Compiler issues or
> runtime issues?
> 
> -Alex
> 
> On 3/7/17, 1:21 PM, "Harbs"  > wrote:
> 
>> I tried the following two workarounds and neither one worked:
>> 
>> super["replaceChildren"].apply(this, applyParams);
>> 
>> var func:Function = super.replaceChildren;
>> func.apply(this, applyParams);
>> 
>>> On Mar 7, 2017, at 11:13 PM, Harbs  wrote:
>>> 
>>> Most of the other ones are “nice to fix”, but have been not too bad to
>>> work around.
>>> 
>>> This one seems more serious to me. (i.e. I’m not sure how to work
>>> around it.)
>>> 
>>> The “super” dropped off in the Javascript, and I don’t know why.
>>> 
>>> https://paste.apache.org/FpNl  
>>> >
>>> 
>>> Harbs

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Alex Harui]

On 3/7/17, 1:04 PM, "Greg Dove"  wrote:

>I had never run those tests specifically - I was not even aware of those
>yet, the unit tests run during ant all build had proceeded without
>problems:

There are three sets of unit tests.  Because the compiler is needed to
build the AS framework, we can't have the compiler tests require the AS
framework, so the set of tests that runs automatically don't have any AS
framework dependencies, then there is a set of tests with flex-sdk
dependencies and one with flex-asjs dependencies, which is what you just
ran.

Ignore the "Unable to parse" for now.

IMO, no need to revert the changes.  I've got plenty of other things to do.

Thanks for digging into it.
-Alex

Re: [FalconJX] yet another one

[Alex Harui]

The output JS looks ok to me.

AS:
super.replaceChildren(termIdx, termIdx+1);


JS:
org.apache.flex.textLayout.elements.ParagraphElement.superClass_.replaceChi
ldren.apply(this, [ termIdx, termIdx + 1] );


I could be wrong, but I thought there is no "super" in ES5.

Does it not work correctly?  Are you getting Closure Compiler issues or
runtime issues?

-Alex

On 3/7/17, 1:21 PM, "Harbs"  wrote:

>I tried the following two workarounds and neither one worked:
>
>super["replaceChildren"].apply(this, applyParams);
>
>var func:Function = super.replaceChildren;
>func.apply(this, applyParams);
>
>> On Mar 7, 2017, at 11:13 PM, Harbs  wrote:
>> 
>> Most of the other ones are “nice to fix”, but have been not too bad to
>>work around.
>> 
>> This one seems more serious to me. (i.e. I’m not sure how to work
>>around it.)
>> 
>> The “super” dropped off in the Javascript, and I don’t know why.
>> 
>> https://paste.apache.org/FpNl 
>> 
>> Harbs
>

[FalconJX] yet another one

[Harbs]

Most of the other ones are “nice to fix”, but have been not too bad to work 
around.

This one seems more serious to me. (i.e. I’m not sure how to work around it.)

The “super” dropped off in the Javascript, and I don’t know why.

https://paste.apache.org/FpNl 

Harbs

Re: [FalconJX] yet another one

[Harbs]

I tried the following two workarounds and neither one worked:

super["replaceChildren"].apply(this, applyParams);

var func:Function = super.replaceChildren;
func.apply(this, applyParams);

> On Mar 7, 2017, at 11:13 PM, Harbs  wrote:
> 
> Most of the other ones are “nice to fix”, but have been not too bad to work 
> around.
> 
> This one seems more serious to me. (i.e. I’m not sure how to work around it.)
> 
> The “super” dropped off in the Javascript, and I don’t know why.
> 
> https://paste.apache.org/FpNl 
> 
> Harbs

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

I had never run those tests specifically - I was not even aware of those
yet, the unit tests run during ant all build had proceeded without problems:

I am seeing this:

[junit] Running
org.apache.flex.compiler.internal.codegen.js.flexjs.TestFlexJSFile
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
4.76 sec
[junit] Running
org.apache.flex.compiler.internal.codegen.mxml.flexjs.TestFlexJSMXMLApplication
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.

I am not sure what 'Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml' is yet.

but the errors are related to my changes, but also seems like they found
something valid. I can look into this in a about 5-6 hours time. Do you
need me to revert the commit until I get a chance to address those tests?


On Wed, Mar 8, 2017 at 9:53 AM, Alex Harui  wrote:

>
>
> On 3/7/17, 9:41 AM, "Greg Dove"  wrote:
>
> >Anything else I should be doing?
>
> If you are using Ant to build flex-falcon, please run
>
>ant flexjs.dependent.tests
>
> This may require setting up an ASJS_HOME environment variable or setting
> in env.properties to point to the flex-asjs repo that has previously been
> built so it as the SWCs.
>
> The flex-falcon build just failed.  Not sure if it is due to your changes.
>
> Thanks,
> -Alex
>
>

Re: [compc] another output issue

[Alex Harui]

Bugs relating to internal classes wouldn't surprise me either.

-Alex

On 3/7/17, 12:59 PM, "Harbs"  wrote:

>There’s a class which has the following:
>https://paste.apache.org/KEw5 
>
>
>This is an internal class outside the file package.
>
>In Javascript, it outputs the following:
>
>  org.apache.flex.textLayout.edit.ModelEdit.DeleteTextMemento.base(this,
>'constructor', textFlow);
>  var /** @type {org.apache.flex.textLayout.elements.FlowLeafElement} */
>startLeaf = textFlow.findLeaf(absoluteStart);
>  var /** @type {org.apache.flex.textLayout.elements.FlowGroupElement} */
>this.commonRoot = startLeaf.getParagraph().parent;
>
>The third line is wrong. The “this” should not be there...

Re: [compc] issue #4

[Alex Harui]

On 3/7/17, 12:56 PM, "Harbs"  wrote:

>Yeah. Is the fact that it’s in static vars something that could break it?

That wouldn't surprise me too much.

-Alex

[compc] another output issue

[Harbs]

There’s a class which has the following:
https://paste.apache.org/KEw5 


This is an internal class outside the file package.

In Javascript, it outputs the following:

  org.apache.flex.textLayout.edit.ModelEdit.DeleteTextMemento.base(this, 
'constructor', textFlow);
  var /** @type {org.apache.flex.textLayout.elements.FlowLeafElement} */ 
startLeaf = textFlow.findLeaf(absoluteStart);
  var /** @type {org.apache.flex.textLayout.elements.FlowGroupElement} */ 
this.commonRoot = startLeaf.getParagraph().parent;

The third line is wrong. The “this” should not be there...

Re: [FalconJX] RegExp flags

[Alex Harui]

On 3/7/17, 12:36 PM, "Harbs"  wrote:

>ActionScript supports different RegExp flags than Javascript suports.
>
>ActionScript has: g, i, s, m and x
>Javascript has: g, i, m, u and y
>
>So we have a mismatch between “s” and “x” on one side and “u” and “y” on
>the other.
>
>Currently, ActionScript flags compile to Javascript, but the google
>compiler complains that they are not valid.
>
>What’s the “correct” way to deal with this incompatibility?

Don't use those flags?

I'm not sure where those flags get used. One option may be to map RegExp
to an org.apache.flex.utils.RegExp that we would have to wrate that either
subclasses RegExp or wraps it.  Another may be to map certain APIs on
RegExp to org.apache.flex.utils.Language.

-Alex

Re: [compc] issue #4

[Harbs]

Yeah. Is the fact that it’s in static vars something that could break it?

> On Mar 7, 2017, at 10:49 PM, Alex Harui  wrote:
> 
> 
> 
> On 3/7/17, 12:16 PM, "Harbs"  wrote:
> 
>> I might have been mistaken.
>> 
>> Right now, I’m seeing the goo.requires in the original js files, but they
>> seem to be missing from the js files in my test app. I’m not sure why
>> they are being stripped out — possibly it’s happening from
>> remove-circulars?
> 
> Remove-circulars will strip out goog.requires, but it should not break the
> app.  Some other file should be requiring it and it should get loaded
> before it is needed.
> 
> Of course, there could be a bug in all of that.
> 
> -Alex
> 

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Alex Harui]

On 3/7/17, 9:41 AM, "Greg Dove"  wrote:

>Anything else I should be doing?

If you are using Ant to build flex-falcon, please run

   ant flexjs.dependent.tests

This may require setting up an ASJS_HOME environment variable or setting
in env.properties to point to the flex-asjs repo that has previously been
built so it as the SWCs.

The flex-falcon build just failed.  Not sure if it is due to your changes.

Thanks,
-Alex

Re: [compc] issue #4

[Alex Harui]

On 3/7/17, 12:16 PM, "Harbs"  wrote:

>I might have been mistaken.
>
>Right now, I’m seeing the goo.requires in the original js files, but they
>seem to be missing from the js files in my test app. I’m not sure why
>they are being stripped out — possibly it’s happening from
>remove-circulars?

Remove-circulars will strip out goog.requires, but it should not break the
app.  Some other file should be requiring it and it should get loaded
before it is needed.

Of course, there could be a bug in all of that.

-Alex

[FalconJX] RegExp flags

[Harbs]

ActionScript supports different RegExp flags than Javascript suports.

ActionScript has: g, i, s, m and x
Javascript has: g, i, m, u and y

So we have a mismatch between “s” and “x” on one side and “u” and “y” on the 
other.

Currently, ActionScript flags compile to Javascript, but the google compiler 
complains that they are not valid.

What’s the “correct” way to deal with this incompatibility?

Harbs

Re: [compc] issue #4

[Harbs]

I might have been mistaken.

Right now, I’m seeing the goo.requires in the original js files, but they seem 
to be missing from the js files in my test app. I’m not sure why they are being 
stripped out — possibly it’s happening from remove-circulars?

I’m also getting errors from google compiler like this:

 [java] SEVERE: 
/Users/harbs/Documents/git/PrintUI/printui-flexjs/text_engine/test/HelloWorldTLF/bin/js-debug/org/apache/flex/textLayout/conversi
on/BaseTextLayoutExporter.js:207: ERROR - Parse error. Expected regular 
expression first char
 [java] 
org.apache.flex.textLayout.conversion.BaseTextLayoutExporter.brRegEx = /
/;
 [java] 
^
 [java]
 [java] Mar 07, 2017 9:52:31 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] SEVERE: 
/Users/harbs/Documents/git/PrintUI/printui-flexjs/text_engine/test/HelloWorldTLF/bin/js-debug/org/apache/flex/textLayout/conversi
on/BaseTextLayoutImporter.js:72: ERROR - Parse error. ']' expected
 [java] 
org.apache.flex.textLayout.conversion.BaseTextLayoutImporter.anyPrintChar = /[^


The original code looks like this:

static private const brRegEx:RegExp = /\u2028/;

and this:

static private const anyPrintChar:RegExp = 
/[^\u0009\u000a\u000d\u0020]/g; 

Which outputs:

org.apache.flex.textLayout.conversion.BaseTextLayoutExporter.brRegEx = /
/;

and

org.apache.flex.textLayout.conversion.BaseTextLayoutImporter.anyPrintChar = /[^ 
 ]/g;

We have had similar problems with string conversions when we used regex in our 
app.

> On Mar 7, 2017, at 9:09 PM, Alex Harui  wrote:
> 
> 
> 
> On 3/7/17, 10:49 AM, "Harbs"  wrote:
> 
>> There’s a lot of [ExcludeClass] tags in TLF. It seems like this prevents
>> the goog.requires to be created.
>> 
>> I’m guessing that [ExcludeClass] was used to prevent the classes from
>> winding up in the ASDocs? Is there some way to do that which does not
>> break the JS output?
> 
> I do not see any code in the compiler where [ExcludeClass] would alter JS
> output.
> 
> Start with a class that uses a class that has [ExcludeClass] metadata and
> check the JS output.  Is that "excluded" class mentioned anywhere in the
> JS output?
> 
> Thanks,
> -Alex
> 

Re: [compc] issue #4

[Alex Harui]

On 3/7/17, 10:49 AM, "Harbs"  wrote:

>There’s a lot of [ExcludeClass] tags in TLF. It seems like this prevents
>the goog.requires to be created.
>
>I’m guessing that [ExcludeClass] was used to prevent the classes from
>winding up in the ASDocs? Is there some way to do that which does not
>break the JS output?

I do not see any code in the compiler where [ExcludeClass] would alter JS
output.

Start with a class that uses a class that has [ExcludeClass] metadata and
check the JS output.  Is that "excluded" class mentioned anywhere in the
JS output?

Thanks,
-Alex

Re: git commit: [flex-asjs] [refs/heads/develop] - Added Shader files (with compiler argument)

[Alex Harui]

On 3/7/17, 10:26 AM, "Harbs"  wrote:

>I took the files from the flex-sdk repo. How did the files get there?

The pbj files are not under source control in flex-sdk.  They are
downloaded from the Apache Flex Pixel Bender release.

>
>Can you fix this issue, because you obviously understand how and I
>haven’t a clue…

In theory, you can copy and tweak the pixel bender portion of
flex-sdk/frameworks/downloads.xml.

>
>Oh. Are you saying that we should reference the files in the flex-sdk
>directory? Wouldn’t that require building the flex-sdk as well?

No.  There is a binary artifact available that we should be using.

-Alex

[compc] issue #4

[Harbs]

There’s a lot of [ExcludeClass] tags in TLF. It seems like this prevents the 
goog.requires to be created.

I’m guessing that [ExcludeClass] was used to prevent the classes from winding 
up in the ASDocs? Is there some way to do that which does not break the JS 
output?

Harbs

Re: git commit: [flex-asjs] [refs/heads/develop] - Added Shader files (with compiler argument)

[Harbs]

I took the files from the flex-sdk repo. How did the files get there?

Can you fix this issue, because you obviously understand how and I haven’t a 
clue…

Oh. Are you saying that we should reference the files in the flex-sdk 
directory? Wouldn’t that require building the flex-sdk as well?


> On Mar 7, 2017, at 8:01 PM, Alex Harui  wrote:
> 
> 
> 
> On 3/7/17, 9:29 AM, "Harbs"  wrote:
> 
>> I don’t understand what you mean.
>> 
>> These files were just copied from the flex-sdk.
>> 
>> Huh! The pbj files were not committed. It looks like they were excluded
>> in the .gitignore.
>> 
>> I just fixed that.
> 
> Funny!  That was exactly the opposite reaction that we needed ;-).
> 
> This is open source.  PBJ files are object files.  They should not be
> committed to our repos.
> 
> And that's the uber point.  The way to convert PBK to PBJ is via an Adobe
> tool, and most folks don't want to have to get the tool working in order
> to build our source releases.
> 
> So even for the flex-sdk, several years ago, we created a special one-off
> PixelBender release.  The flex-sdk download.xml script brings down the
> binary artifact and unpacks the PB files.  I was trying to get you to use
> those same files.  Otherwise, every PMC member who wants to vote on our
> source releases will have to install the Adobe tool.
> 
> Please make the switch to the PixelBender release instead of putting the
> PB files in flex-asjs.
> 
> Thanks,
> -Alex
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - Added Shader files (with compiler argument)

[Dev LFM]

Talking about pbj and pbk, does anyone have that oilpaint effect?

2017-03-07 18:01 GMT+00:00 Alex Harui :

>
>
> On 3/7/17, 9:29 AM, "Harbs"  wrote:
>
> >I don’t understand what you mean.
> >
> >These files were just copied from the flex-sdk.
> >
> >Huh! The pbj files were not committed. It looks like they were excluded
> >in the .gitignore.
> >
> >I just fixed that.
>
> Funny!  That was exactly the opposite reaction that we needed ;-).
>
> This is open source.  PBJ files are object files.  They should not be
> committed to our repos.
>
> And that's the uber point.  The way to convert PBK to PBJ is via an Adobe
> tool, and most folks don't want to have to get the tool working in order
> to build our source releases.
>
> So even for the flex-sdk, several years ago, we created a special one-off
> PixelBender release.  The flex-sdk download.xml script brings down the
> binary artifact and unpacks the PB files.  I was trying to get you to use
> those same files.  Otherwise, every PMC member who wants to vote on our
> source releases will have to install the Adobe tool.
>
> Please make the switch to the PixelBender release instead of putting the
> PB files in flex-asjs.
>
> Thanks,
> -Alex
>
>

Re: git commit: [flex-asjs] [refs/heads/develop] - Added Shader files (with compiler argument)

[Alex Harui]

On 3/7/17, 9:29 AM, "Harbs"  wrote:

>I don’t understand what you mean.
>
>These files were just copied from the flex-sdk.
>
>Huh! The pbj files were not committed. It looks like they were excluded
>in the .gitignore.
>
>I just fixed that.

Funny!  That was exactly the opposite reaction that we needed ;-).

This is open source.  PBJ files are object files.  They should not be
committed to our repos.

And that's the uber point.  The way to convert PBK to PBJ is via an Adobe
tool, and most folks don't want to have to get the tool working in order
to build our source releases.

So even for the flex-sdk, several years ago, we created a special one-off
PixelBender release.  The flex-sdk download.xml script brings down the
binary artifact and unpacks the PB files.  I was trying to get you to use
those same files.  Otherwise, every PMC member who wants to vote on our
source releases will have to install the Adobe tool.

Please make the switch to the PixelBender release instead of putting the
PB files in flex-asjs.

Thanks,
-Alex

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

Anything else I should be doing?

One thing I did not check (and generally have not checked specifically with
anything I did so far in FlexJS) is anything to do with inline
(fx:Component) mxml.

I *think* there are some unit tests for these, I would need to double
check but if you are using that anywhere it would just be helpful to
know that things work correctly inside that. I was intending to come back
and check this explicitly and also maybe add some new unit tests to the
compiler for these new errors.

Aside from that, no, there is nothing specific, apart from making sure that
your app compiles and runs as expected.
In theory, if you got errors on re-compile with the new code, it should
only be helping you. If you get no errors, then you can be more reassured
that your mxml is good (which I am sure it was anyway) :)



On Mon, Mar 6, 2017 at 10:07 PM, Harbs  wrote:

> I have noticed that MXML compiling does not produce the greatest error
> reports. I should have recorded issues as I saw them, but I didn’t. :-(
>
> These two cases make sense to me, and thanks for fixing them. I’ll be
> happy to update falcon and make sure that things still compile correctly in
> my apps. Anything else I should be doing?
>
> > On Mar 6, 2017, at 10:40 AM, Greg Dove  wrote:
> >
> > "It sound to me like you know what you’re talking about"
> >
> > Haha, Harbs that's probably more reassuring to me than it should be to
> you.
> > In terms of anything at all in the compiler, I am still LAYG (learning as
> > you go) here ;)
> > (btw, you can never have too many 'as you go' acronyms)
> >
> > I actually shared Alex's general concerns over making changes in the mxml
> > parsing, we don't have a large range of tests to cover all the potential
> > mxml variations (otherwise I expect this would have already been
> addressed).
> >
> > Harbs, I understand that you have a (quite possibly) large codebase so
> you
> > might provide the best real-world 'litmus test' in you have a large
> amount
> > of mxml.
> >
> >
> > In simple terms the changes will prevent the following 2 examples from
> > compiling, which currently compile fine in FlexJS, but should not:
> >
> > 
> >
> >
> > 
> >
> > in the above example the view2 instance was being created and assigned
> for
> > the initialView propertty, the first was ignored
> >
> > 
> >
> > 
> >
> > In this case the types are incompatible.
> >
> > I actually think the compiler errors for mxml could be more important
> than
> > a sesaoned Flex user would assume in terms of how new people will form
> > early impressions. When people who potentially don't know actionscript
> > (yet) take some FlexJS examples for a spin, they are probably going to
> look
> > at the mxml and think to themselves 'I can do that', so it will be the
> > first thing they mess with. Mxml-related errors might be the first thing
> > they see from the compiler after they start messing with stuff.
> > That's why I spent a bit of time discussing those...I have gone ahead and
> > gone with the two new ones as I suggested.
> >
> >
> >
> > On Mon, Mar 6, 2017 at 12:08 AM, Harbs  wrote:
> >
> >> I have to admit that you lost me pretty quickly… ;-)
> >>
> >> It sound to me like you know what you’re talking about, so I’m fine with
> >> whatever you did/want to do… :-)
> >>
> >> Harbs
> >>
> >>> On Mar 5, 2017, at 9:31 AM, Greg Dove  wrote:
> >>>
> >>> OK please brace yourself for an onslaught of text.
> >>>
> >>> I tested across Flex 4 and FlexJS through a bunch of variations. This
> >>> change passes all tests. In the end this is a very small and isolated
> >> code
> >>> change (I am almost certain it will not contribute to anyone's merge
> >>> conflicts) and I believe it gives greater compile-time type safety to
> >> mxml,
> >>> so I think it's necessary. But the error descriptions are open for more
> >>> input/review... I have favored a strong consistency with the Flex 4
> >>> descriptions, which were specific for mxml, over using the related
> >>> actionscript descriptions.
> >>>
> >>> BTW I had forgotten, but there was also a comment (it was not marked
> as a
> >>> todo) in the falcon MXMLPropertySpecifierNode class that indicated that
> >>> this type of work still needed to be done, so I expect it was an
> >> unfinished
> >>> implementation.
> >>>
> >>> If I hear nothing conflciting by EOD tomorrow I will commit what I
> have.
> >> It
> >>> can easily be reverted if anyone finds issues, or I am happy to address
> >> it
> >>> further if it is not correct for some cases that I did not anticipate.
> >>>
> >>> That's the end of the preamble best of luck getting through what
> >>> follows... it took me longer than the original coding part :)
> >>>
> >>> Test setup for Flex 4:
> >>> 'TestView' below is simply a Flex4 Group mxml component, like so:
> >>> http://ns.adobe.com/mxml/2009";
> >>>xmlns:s="library://ns.adobe.com/flex/spark"
> >>>creationComplete="onCreated()">
> >>>   
> >>>  

Re: git commit: [flex-asjs] [refs/heads/develop] - Added Shader files (with compiler argument)

[Harbs]

I don’t understand what you mean.

These files were just copied from the flex-sdk.

Huh! The pbj files were not committed. It looks like they were excluded in the 
.gitignore.

I just fixed that.

> On Mar 7, 2017, at 6:02 PM, Alex Harui  wrote:
> 
> Hi,
> 
> Is it possible to use the upstream release instead?  Even the flex-sdk
> uses pbj files from the upstream.  IIRC, we did that because not everyone
> wanted to deal with installing the PB compiler.
> 
> Thanks,
> -Alex
> 
> On 3/7/17, 2:25 AM, "ha...@apache.org " 
> mailto:ha...@apache.org>> wrote:
> 
>> Repository: flex-asjs
>> Updated Branches:
>> refs/heads/develop 9657c4e9a -> 281c77860
>> 
>> 
>> Added Shader files (with compiler argument)
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo 
>> 
>> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/281c7786 
>> 
>> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/281c7786 
>> 
>> Diff: ttp://git-wip-us.apache.org/repos/asf/flex-asjs/diff/281c7786 
>> 
>> 
>> Branch: refeads/develop
>> Commit: 281c778607522da2aeca24f8212d551687684ce0
>> Parents: 9657c4e
>> Author: Harbs mailto:ha...@in-tools.com>>
>> Authored: Tue Mar 7 12:25:26 2017 +0200
>> Committer: Harbs mailto:ha...@in-tools.com>>
>> Committed: Tue Mar 7 12:25:26 2017 +0200
>> 
>> --
>> frameworks/projects/Graphics/build.xml  |   1 +
>> .../Graphics/src/main/flex/GraphicsClasses.as   |   9 +
>> .../flex/graphics/utils/shaderClasses/Color.pbk | 101 +
>> .../grahics/utils/shaderClasses/ColorBurn.pbk  | 149 +
>> .../utils/shrClasses/ColorBurnShader.as  |  62 ++
>> .../graphics/utils/shaderClasses/ColorDodge.pbk | 151 +
>> .../utils/shaderClasses/ColorDodgeShader.as |  61 +
>> .../graphics/utils/shaderClasses/ColorShader.as |  61 +
>> .../graphics/utils/shaderClasses/Exclusion.pbk  | 105 +
>> .../utils/shaderClasses/ExclusionShader.as  |  61 +
>> .../flex/graphics/utils/shaderClasses/Hue.pbk   | 216 ++
>> .../graphics/utils/shaderClasses/HueShader.as   |  61 +
>> .../graphics/utils/shaderClasses/Luminosity.pbk | 103 +
>> .../shaderClasses/LuminosityMaskFilter.pbk  | 133 +++
>> .../utils/shaderClasses/LuminosityMaskShader.as |  97 
>> .../utils/shaderClasses/LuminosityShader.as |  60 +
>> .../graphics/utils/shaderClasses/Saturation.pbk | 222 +++
>> .../utils/shaderClasses/SaturationShader.as |  60 +
>> .../graphics/utils/shaderClasses/SoftLight.pbk  | 199 +
>> .../utils/shaderClasses/SoftLightShader.as  |  60 +
>> 20 files changed, 1972 insertions(+)
>> -
>> 
>> 
>> http://git-wip-us.apachrg/repos/asf/flex-asjs/blob/281c7786/frameworks/ 
>> 
>> projects/Graphics/build.xml
>> --
>> diff --git a/frameworks/projects/Graphics/build.xml
>> b/frameworks/projects/Graphics/build.xml
>> index b47b813..01cbeb5 100644
>> --- a/frameworks/projects/Graphics/build.xml
>> +++ b/frameworks/projects/Graphics/build.xml
>> @@ -83,6 +83,7 @@
>>
>>
>>   
>> + lue="-compiler.byte-array-embed-class=org.apache.flex.core.ByteArrayAsse
>> t" />
>>
>>> tofile="${FLEXJS_HOME}/frameworks/libs/${target.name}" />
>>
>> 
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/281c7786/frameworks/ 
>> 
>> projects/Graphics/src/main/flex/GraphicsClasses.as
>> --
>> diff --git 
>> a/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>> b/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>> index 3b87a56..5836c9e 100644
>> --- a/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>> +++ b/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>> @@ -41,6 +41,15 @@ internal class GraphicsClasses
>>  COMPILE::SWF
>>  {
>>  import org.apache.flex.graphics.utils.PathHelper; PathHelper;
>> +import 
>> org.apache.flex.graphics.utils.shaderClasses.ColorBurnShader;
>> ColorBurnShader;
>> +import 
>> org.apache.flex.graphics.utils.shaderClasses.ColorDodgeShader;
>> ColorDodgeShader;
>> +import org.apache.flex.graphics.utils.shaderClasses.ColorShader;
>> ColorShader;
>> +import 
>> org.apache.flex.graphics.utils.shaderClasses.ExclusionShader;
>> ExclusionShader;
>> +impo

Re: [FlexJS] Group container

[Alex Harui]

In theory, the API for Container should abstract away how many internal
pieces there are.  It should probably be a div in JS.  Adding a
ScrollingContainerView should be the PAYG way of turning on overflow:auto.

On the SWF side, the ScrollingContainerView has a lot more work to do.
But it should all be under the hood.  The coordinate system of children
should be the same on both platforms.

Essentially, we use PAYG to build up the SWF side to be the equivalent of
the HTML div.  So borders and backgrounds are not in the API surface.
They are under-the-hood.

Then, separately, IMO, there is the concept of what I'll call "user
chrome".  This is visuals in a container that appear to be outside the
content area.  It could be borders that are not describable in CSS and are
thus composited by children of the outer container.  It could be a
TitleBar/StatusBar/ControlBar/Menu-like row of widgets around some
content.  I don't know how resize handles are done in JS, but that might
be a candidate as well.

To me, the question is: what is the coordinate system and numChildren
expectations in the HTML/JS world for these kinds of custom containers,
and are there pain points related to them that we should solve better in
FlexJS?  Do people even make re-usable "Panels" in HTML?  Where someone
supplied a widget with a "title" property and you addChildren to it?  Or
do folks just grab a plain  and build Panels individually by placing
a div in there for the title and another for the children?

As usual, we want to see what is the optimal way to do this in JS, find
the patterns and encapsulate those patterns.

My 2 cents,
-Alex

On 3/7/17, 8:26 AM, "Peter Ent"  wrote:

>As I go through FlexJS, I am wondering if we need to continue the idea of
>chrome. Chrome is not something built into HTML/CSS/JS, it is artificial.
>We use it for the title bar and control bar in a Panel, but a Panel can be
>composed of nesting Groups and applying the correct styles.
>
>In Flex, scroll bars were chrome but they do not have that status in HTML.
>In fact, just using overflow:auto will get scrollbars (when needed) on a
>Group (aka ). To get scrollbars on the SWF side we do need to embed a
>scrollable area within an area that will mask the overflowing bits and
>provide interactive scroll bars.
>
>In my mind, Container serves the purpose of allowing those apps that run
>on SWF or SWF/JS platforms to have scrollable content. If you were to run
>only on JS, then you don't need Container, you can just style the div
>provided by Group. But we need to give SWF a hint which can be done by
>using Container instead of Group when you suspect the content will need to
>be scrolled. The CSS style for Container can have overflow:auto set and
>otherwise extend Group for the JS side. The SWF side can nest
>DisplayObjectContainers and put scrollbars into the outer container and
>use it as a mask. 
>
>Panel can be composed of an outer Group, with a Group for the title bar, a
>Container for the content, and another Group for the control bar. If
>anyone really needs to have chrome pieces they can do the same thing.
>
>What do you think? Should Container continue to support chrome (aka,
>components implementing IChrome interface) or should it just be for
>scrollable content?
>
>Thanks,
>Peter
>
>On 3/7/17, 10:31 AM, "Peter Ent"  wrote:
>
>>Thanks for the feedback!
>>
>>As I go through the examples, I see that we (mostly me) created a number
>>of nested elements, such as a  for an item renderer.
>>That makes it more difficult to lay out since the content of the div is
>>not always set to fill the div's space. I think each of the components
>>and
>>renderers need to be examined and updated.
>>
>>—peter
>>
>>On 3/7/17, 10:04 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>>
>>wrote:
>>
>>>Hi Peter, I think this awesome. get rid of the hardcoded styles in
>>>component classes is such important thing and first point not only in
>>>your
>>>effort of create a good layout strategy, but an important previous step
>>>if
>>>we want to implement theming in FlexJS.
>>>
>>>Great! :D
>>>
>>>Carlos
>>>
>>>
>>>2017-03-07 14:23 GMT+01:00 Peter Ent :
>>>
 This is the theory, yes. A way to do your own thing using AS and MXML
to
 construct the app which then generates the right amount of HTML
structure,
 making it easier to style. Or use pre-built constructions and layouts
as
 templates that also generate the right amount of HTML structure.

 I'm thinking that Panel would be a good case for a composite component
and
 maybe even move it into Express. In theory, you can compose a Panel
from:

  with VerticalFlexLayout
  with Horizontal Flex Layout for the Title Bar
  to provide scrollable area
  with Horizontal Flex Layout for the Control Bar
 

 We'll see how this goes.
 ‹peter

 On 3/6/17, 5:02 PM, "Alex Harui"  wrote:

 >
 >
 >On 3/6/17, 1:26 PM, "piotrz"  wro

Re: git commit: [flex-asjs] [refs/heads/develop] - Added Shader files (with compiler argument)

[Alex Harui]

Hi,

Is it possible to use the upstream release instead?  Even the flex-sdk
uses pbj files from the upstream.  IIRC, we did that because not everyone
wanted to deal with installing the PB compiler.

Thanks,
-Alex

On 3/7/17, 2:25 AM, "ha...@apache.org"  wrote:

>Repository: flex-asjs
>Updated Branches:
>  refs/heads/develop 9657c4e9a -> 281c77860
>
>
>Added Shader files (with compiler argument)
>
>
>Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
>Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/281c7786
>Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/281c7786
>Diff: ttp://git-wip-us.apache.org/repos/asf/flex-asjs/diff/281c7786
>
>Branch: refeads/develop
>Commit: 281c778607522da2aeca24f8212d551687684ce0
>Parents: 9657c4e
>Author: Harbs 
>Authored: Tue Mar 7 12:25:26 2017 +0200
>Committer: Harbs 
>Committed: Tue Mar 7 12:25:26 2017 +0200
>
>--
> frameworks/projects/Graphics/build.xml  |   1 +
> .../Graphics/src/main/flex/GraphicsClasses.as   |   9 +
> .../flex/graphics/utils/shaderClasses/Color.pbk | 101 +
> .../grahics/utils/shaderClasses/ColorBurn.pbk  | 149 +
> .../utils/shrClasses/ColorBurnShader.as  |  62 ++
> .../graphics/utils/shaderClasses/ColorDodge.pbk | 151 +
> .../utils/shaderClasses/ColorDodgeShader.as |  61 +
> .../graphics/utils/shaderClasses/ColorShader.as |  61 +
> .../graphics/utils/shaderClasses/Exclusion.pbk  | 105 +
> .../utils/shaderClasses/ExclusionShader.as  |  61 +
> .../flex/graphics/utils/shaderClasses/Hue.pbk   | 216 ++
> .../graphics/utils/shaderClasses/HueShader.as   |  61 +
> .../graphics/utils/shaderClasses/Luminosity.pbk | 103 +
> .../shaderClasses/LuminosityMaskFilter.pbk  | 133 +++
> .../utils/shaderClasses/LuminosityMaskShader.as |  97 
> .../utils/shaderClasses/LuminosityShader.as |  60 +
> .../graphics/utils/shaderClasses/Saturation.pbk | 222 +++
> .../utils/shaderClasses/SaturationShader.as |  60 +
> .../graphics/utils/shaderClasses/SoftLight.pbk  | 199 +
> .../utils/shaderClasses/SoftLightShader.as  |  60 +
> 20 files changed, 1972 insertions(+)
>-
>
>
>http://git-wip-us.apachrg/repos/asf/flex-asjs/blob/281c7786/frameworks/
>projects/Graphics/build.xml
>--
>diff --git a/frameworks/projects/Graphics/build.xml
>b/frameworks/projects/Graphics/build.xml
>index b47b813..01cbeb5 100644
>--- a/frameworks/projects/Graphics/build.xml
>+++ b/frameworks/projects/Graphics/build.xml
>@@ -83,6 +83,7 @@
> 
> 
>
>+
> 
> tofile="${FLEXJS_HOME}/frameworks/libs/${target.name}" />
> 
>
>http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/281c7786/frameworks/
>projects/Graphics/src/main/flex/GraphicsClasses.as
>--
>diff --git 
>a/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>b/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>index 3b87a56..5836c9e 100644
>--- a/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>+++ b/frameworks/projects/Graphics/src/main/flex/GraphicsClasses.as
>@@ -41,6 +41,15 @@ internal class GraphicsClasses
>   COMPILE::SWF
>   {
>   import org.apache.flex.graphics.utils.PathHelper; PathHelper;
>+  import 
>org.apache.flex.graphics.utils.shaderClasses.ColorBurnShader;
>ColorBurnShader;
>+  import 
>org.apache.flex.graphics.utils.shaderClasses.ColorDodgeShader;
>ColorDodgeShader;
>+  import org.apache.flex.graphics.utils.shaderClasses.ColorShader;
>ColorShader;
>+  import 
>org.apache.flex.graphics.utils.shaderClasses.ExclusionShader;
>ExclusionShader;
>+  import org.apache.flex.graphics.utils.shaderClasses.HueShader;
>HueShader;
>+  import 
>org.apache.flex.graphics.utils.shaderClasses.LuminosityMaskShader;
>LuminosityMaskShader;
>+  import 
>org.apache.flex.graphics.utils.shaderClasses.LuminosityShader;
>LuminosityShader;
>+  import 
>org.apach.flex.graphics.utils.shaderClasses.SaturationShader;
>SaturationShader;
>+  import 
>org.apache.flex.graphics.utils.shaderClasses.SoftLightShader;
>SoftLightShader;
>   }
>   import org.apache.flex.graphics.QuadrticCurve; QuadraticCurve;
>   import org.apache.flex.graphics.ICircle; ICircle;
>
>http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/281c7786/frameworks/
>projects/Graphics/src/main/flex/orgapache/flex/graphics/utils/shaderClass
>es/Color.pbk
>-
>diff --git 
>a/frameworks/projects/Graphics/src/main/flex/org/apache/f

Re: [FlexJS] Dual branch

[Alex Harui]

On 3/7/17, 4:36 AM, "Christofer Dutz"  wrote:

>Hi guys and especially Alex,
>
>I would like to ask you to give a short summary at what you changed in
>the dual branch. I don’t quite know as to what I should be looking for to
>make Maven support to match.
>
>Could you please summarize what new compiler options/arguments, which
>new/changed/obsolete compilation runs and how the packaging should have
>changed?
>Right now, I still see swc and js-swc as output of the compilation. I
>would expect one single swc to come out and this to contain two
>catalog.xml … ist that correct?

The goal of dual was just to get two "stacks" of SWCs (one for SWF, one
for JS) to work in the compiler.  Merging the two swcs into one and
renaming catalog.xml and library.swf is for later.  Getting two "stacks"
to work sets the foundation for merging later by first proving that we can
in fact produce runnable SWFs and JS from separate stacks and that having
two stacks allows us to find platform dependencies in our code.

So, there are still two SWCs produced from each frameworks/projects
folder.  However, instead of calling the JS oriented one a "typedefs" SWC,
I changed it to be a "js" classifier because the JS swc is now used to
build the JS app.  Before, the JS-oriented SWC was primarily used to
generate downstream JS-oriented SWCs so the "typedefs" classifier made
more sense.

The default SWC is the same as before.  It contains a library.swf compiled
with COMPILE::SWF,true and thus the code inside is used for linking into
SWFs.  It contains the cross-complled JS output like before which was
compiled with COMPILE::JS,true.  And it contains any defaults.css like
before.

The "js" SWC is a bit different.  It contains a library.swf compiled with
COMPILE::JS,true just like before, but now it also contains the
cross-compiled JS output (with COMPILE::JS, true) and any defaults.css.
So it is more of a peer of the main SWC, it just has a different
library.swf.

In order to do this, I still use CompileASMojo to build the default SWC.
I think the main changes there are that I switched the name of
compile-as-config.xml to compile-swf-config.xml, but more importantly, I
switched the mojo to use the FlexJS version of compc because the compc
from compiler-jx now can produce both SWF and JS output (by calling the
compc from the compiler folder for SWF output).  So, CompileASMojo also
learned how to filter artifacts and sort the js ones into js slots in the
-config.xml file.

The CompileJSMojo also now uses the compc from compiler-ix and filters
artifacts a bit differently to produce the "js" swc.

Then, once the framework is built, the CompileAppMojo now only needs one
default execution since it now calls the compiler-ix version of MXMLC
(MXMLJSC) which also now knows how to build both a SWF and JS output in
one execution.  So I took the second execution that had
outputJavaScript=true out of the pom.xml.

The main new compiler option is -compiler.targets which takes a set of
strings like "SWF, "JSFlex", "JS", "JSNode".  You can set compiler.targets
to one or more of these to dictate what output you want.  Then in order to
support that, lots of existing options got platform-specific options so
there is now a js-external-library-path and swf-external-library-path as
well as the old external-library-path option.  That way you can specify
one -config.xml file for all output targets.

I have essential obsoleted the -js-output-type parameter.  Folks should
use -compiler.targets instead for building SWCs and apps. Js-output-type
is still used by ASDoc though.

I think that's about it, although I'm sure I forgot to mention something.
I won't be too surprised if I did something that isn't with the Maven
philosophy.  My main goal was to get MXMLJSC to output both SWF and JS so
it would work better with most IDEs since most IDEs only know how to
launch one compiler.  And that has nothing to do with Maven.  But once I
got that working I decided that maybe Maven would prefer to have both
outputs from one execution as well.

HTH,
-Alex


>
>Thanks in advance,
>  Chris

Re: [FlexJS] Group container

[Peter Ent]

As I go through FlexJS, I am wondering if we need to continue the idea of
chrome. Chrome is not something built into HTML/CSS/JS, it is artificial.
We use it for the title bar and control bar in a Panel, but a Panel can be
composed of nesting Groups and applying the correct styles.

In Flex, scroll bars were chrome but they do not have that status in HTML.
In fact, just using overflow:auto will get scrollbars (when needed) on a
Group (aka ). To get scrollbars on the SWF side we do need to embed a
scrollable area within an area that will mask the overflowing bits and
provide interactive scroll bars.

In my mind, Container serves the purpose of allowing those apps that run
on SWF or SWF/JS platforms to have scrollable content. If you were to run
only on JS, then you don't need Container, you can just style the div
provided by Group. But we need to give SWF a hint which can be done by
using Container instead of Group when you suspect the content will need to
be scrolled. The CSS style for Container can have overflow:auto set and
otherwise extend Group for the JS side. The SWF side can nest
DisplayObjectContainers and put scrollbars into the outer container and
use it as a mask. 

Panel can be composed of an outer Group, with a Group for the title bar, a
Container for the content, and another Group for the control bar. If
anyone really needs to have chrome pieces they can do the same thing.

What do you think? Should Container continue to support chrome (aka,
components implementing IChrome interface) or should it just be for
scrollable content?

Thanks,
Peter

On 3/7/17, 10:31 AM, "Peter Ent"  wrote:

>Thanks for the feedback!
>
>As I go through the examples, I see that we (mostly me) created a number
>of nested elements, such as a  for an item renderer.
>That makes it more difficult to lay out since the content of the div is
>not always set to fill the div's space. I think each of the components and
>renderers need to be examined and updated.
>
>—peter
>
>On 3/7/17, 10:04 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>
>wrote:
>
>>Hi Peter, I think this awesome. get rid of the hardcoded styles in
>>component classes is such important thing and first point not only in
>>your
>>effort of create a good layout strategy, but an important previous step
>>if
>>we want to implement theming in FlexJS.
>>
>>Great! :D
>>
>>Carlos
>>
>>
>>2017-03-07 14:23 GMT+01:00 Peter Ent :
>>
>>> This is the theory, yes. A way to do your own thing using AS and MXML
>>>to
>>> construct the app which then generates the right amount of HTML
>>>structure,
>>> making it easier to style. Or use pre-built constructions and layouts
>>>as
>>> templates that also generate the right amount of HTML structure.
>>>
>>> I'm thinking that Panel would be a good case for a composite component
>>>and
>>> maybe even move it into Express. In theory, you can compose a Panel
>>>from:
>>>
>>>  with VerticalFlexLayout
>>>  with Horizontal Flex Layout for the Title Bar
>>>  to provide scrollable area
>>>  with Horizontal Flex Layout for the Control Bar
>>> 
>>>
>>> We'll see how this goes.
>>> ‹peter
>>>
>>> On 3/6/17, 5:02 PM, "Alex Harui"  wrote:
>>>
>>> >
>>> >
>>> >On 3/6/17, 1:26 PM, "piotrz"  wrote:
>>> >
>>> >>Hi Peter,
>>> >>
>>> >>It looks awesome. Cause if I'm enough skilled in CSS I can do
>>>whatever
>>> >>layout I want and I don't need to know any other one. - In theory. :)
>>> >
>>> >True, but like with everything else in FlexJS, we are trying to
>>> >encapsulate common patterns and make them easier to use.
>>> >
>>> >So for example if you have 3 children in a container and want to make
>>>the
>>> >first one stretchy,  you might have to write:
>>> >
>>> >
>>> >  
>>> >  
>>> >  
>>> >
>>> >
>>> >Whereas with a layout you could write:
>>> >
>>> >  
>>> >
>>> >  
>>> >
>>> >
>>> >That way you don't have to remember the names of the styles or look up
>>>how
>>> >to do it.
>>> >
>>> >Hopefully our Layouts will essentially do just that once Peter's done
>>>with
>>> >this refactor.
>>> >
>>> >Of course, I could be wrong...
>>> >-Alex
>>> >
>>>
>>>
>>
>>
>>-- 
>>
>>Carlos Rovira
>>Director General
>>M: +34 607 22 60 05
>>http://www.codeoscopic.com
>>http://www.avant2.es
>>
>>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>>información privilegiada o confidencial. Si ha recibido este mensaje por
>>error, le rogamos que nos lo comunique inmediatamente por esta misma vía
>>y
>>proceda a su destrucción.
>>
>>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>comunicamos
>>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>servicio o información solicitados, teniendo usted derecho de acceso,
>>rectificación, cancelación y oposición de sus datos dirigiéndose a
>>nuestras
>>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>>necesaria.
>

Re: [compc] error #3

[Josh Tynjala]

Have you tried xml["@class"] instead?

- Josh

On Tue, Mar 7, 2017 at 3:19 AM, Harbs  wrote:

> Related:
>
> This produces an error: Syntax error: ‘class’ is not allowed here.
> xml.@class = elem.styleName;
>
> and the following gets a null pointer:
> xml.@["class"] = elem.styleName;
>
> That doesn’t leave many options for assigning a “class” attribute to XML..
> ;-)
>
> > On Mar 7, 2017, at 1:09 PM, Harbs  wrote:
> >
> > Bingo.
> >
> > This is causing an error:
> > var version:String = xmlToParse.@["version”];
> >
> > Changing it to the following works:
> > var version:String = xmlToParse.@version;
> >
> >
> >> On Mar 6, 2017, at 9:31 PM, Alex Harui  wrote:
> >>
> >> Ah, after, digging deeper, it is the @ operator in XML.  And some bugs
> >> around that were also fixed in Dual.
> >>
> >> I think you can try dual now.  It is only failing on checkintests and I
> >> just pushed the fix for that.
> >>
> >> If you wait about 30 minutes, and you see the build passes email, you
> can
> >> try getting dual from the Installer.  I'll be sending out an email with
> >> more info later today.
> >>
> >> -Alex
> >>
> >> On 3/6/17, 11:23 AM, "Harbs"  wrote:
> >>
> >>> I can’t find anything like that. Still looking…
> >>>
>  On Mar 6, 2017, at 8:21 PM, Alex Harui  wrote:
> 
>  Looks like there is a unary operator that isn't expected.  Is there an
>  "at" operator in AS?
> 
>  -Alex
> 
>  On 3/6/17, 10:06 AM, "Harbs"  wrote:
> 
> > I eliminated my compilation errors, but I’m having trouble outputting
> > my
> > swc.
> >
> > AFAICT compile-asjs-swc is working correctly. I get a swc with the
> > library.swf and catalog.xml which at first glance has all the
> classes.
> >
> > However, I’m getting weird results from compile-asjs. Instead of the
> js
> > files being stuffed into the swc, I’m getting a second file calles
> > TLF.swc.new and it appears to be corrupted.
> >
> > Here is the ant script for compile-asjs:
> >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > There appears to be another null pointer error in the compiler.
> Here’s
> > the end of my output:
> >
> >  [java] Compiling file:
> > org.apache.flex.textLayout.conversion.TextLayoutImporter
> >  [java] java.lang.NullPointerException
> >  [java] 5.230256392 seconds
> >  [java]
> >
> > org.apache.flex.compiler.internal.codegen.as.
> ASBeforeNodeStrategy.handle
> > (A
> >
> > SBeforeNodeStrategy.java:47)org.apache.flex.compiler.
> internal.visitor.as
> > .B
> >
> > eforeAfterStrategy.before(BeforeAfterStrategy.java:139)
> org.apache.flex.c
> > om
> >
> > piler.internal.visitor.as.BeforeAfterStrategy.handle(
> BeforeAfterStrategy
> > .j
> >
> > ava:109)org.apache.flex.compiler.internal.codegen.as.
> ASBlockWalker.walk(
> > AS
> >
> > BlockWalker.java:157)org.apache.flex.compiler.internal.
> codegen.js.flexjs
> > .J
> >
> > SFlexJSEmitter.emitUnaryOperator(JSFlexJSEmitter.java:1064)org.
> apache.fl
> > ex
> >
> > .compiler.internal.codegen.as.ASBlockWalker.
> visitUnaryOperator(ASBlockWa
> > lk
> >
> > er.java:532)org.apache.flex.compiler.internal.visitor.as.
> ASNodeSwitch.ha
> > nd
> >
> > le(ASNodeSwitch.java:353)org.apache.flex.compiler.internal.
> visitor.as.AS
> > No
> >
> > deHandler.handle(ASNodeHandler.java:85)org.
> apache.flex.compiler.internal
> > .v
> >
> > isitor.as.BeforeAfterStrategy.handle(BeforeAfterStrategy.
> java:110)org.ap
> > ac
> >
> > he.flex.compiler.internal.codegen.as.ASBlockWalker.walk(
> ASBlockWalker.ja
> > va
> >
> > :157)org.apache.flex.compiler.internal.codegen.js.jx.
> DynamicAccessEmitte
> > r.
> >
> > emit(DynamicAccessEmitter.java:41)org.apache.flex.
> compiler.internal.code
> > ge
> >
> > n.js.jx.DynamicAccessEmitter.emit(DynamicAccessEmitter.
> java:29)org.apach
> > e.
> >
> > flex.compiler.internal.codegen.js.JSEmitter.
> emitDynamicAccess(JSEmitter.
> > ja
> >
> > va:296)org.apache.flex.compiler.internal.codegen.as.
> ASBlockWalker.visitD
> > yn
> >
> > amicAccess(ASBlockWalker.java:496)org.apache.flex.compiler.
> internal.visi
> > to
> >
> > r.as.ASNodeSwitch.handle(ASNodeSwitch.java:250)org.
> apache.flex.compiler.
> > in
> >
> > ternal.visitor.as.ASNodeHandler.handle(ASNodeHandler.java:85)org.
> apache.
> > fl
> >
> > ex.compiler.internal.visitor.as.BeforeAfterStrategy.handle(
> BeforeAfterSt
> > ra
> >
> > tegy.java:110)org.apache.flex.compiler.internal.codegen.as.
> ASBlockWalker

Re: [FlexJS] Embed Workaround

[Alex Harui]

On 3/7/17, 2:46 AM, "yishayw"  wrote:

>I guess nightly wasn't up2date. After rebuilding falcon I'm not getting
>anymore compile errors with embed. Thanks.
>
>I added
>
>org.apache.flex.core.ByteArrayAssetbed-class>
>to
>Graphics\src\main\config\compile-as-config.xml
>
>to make the ant build work, however my Maven build is failing. Where is
>the
>standard place to add a compiler option for Maven?

Look in MDLExample/pom.xml for "additionalCompilerOptions".

However, it may be better to make this apply to everyone by changing in
flex-falcon/flexjs-maven-plugin

src/main/resources/config/compile-app-config.xml
src/main/resources/config/compile-js-config.xml
src/main/resources/config/compile-as-config.xml




HTH,
-Alex

Re: [FlexJS] Group container

[Peter Ent]

Thanks for the feedback!

As I go through the examples, I see that we (mostly me) created a number
of nested elements, such as a  for an item renderer.
That makes it more difficult to lay out since the content of the div is
not always set to fill the div's space. I think each of the components and
renderers need to be examined and updated.

—peter

On 3/7/17, 10:04 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Peter, I think this awesome. get rid of the hardcoded styles in
>component classes is such important thing and first point not only in your
>effort of create a good layout strategy, but an important previous step if
>we want to implement theming in FlexJS.
>
>Great! :D
>
>Carlos
>
>
>2017-03-07 14:23 GMT+01:00 Peter Ent :
>
>> This is the theory, yes. A way to do your own thing using AS and MXML to
>> construct the app which then generates the right amount of HTML
>>structure,
>> making it easier to style. Or use pre-built constructions and layouts as
>> templates that also generate the right amount of HTML structure.
>>
>> I'm thinking that Panel would be a good case for a composite component
>>and
>> maybe even move it into Express. In theory, you can compose a Panel
>>from:
>>
>>  with VerticalFlexLayout
>>  with Horizontal Flex Layout for the Title Bar
>>  to provide scrollable area
>>  with Horizontal Flex Layout for the Control Bar
>> 
>>
>> We'll see how this goes.
>> ‹peter
>>
>> On 3/6/17, 5:02 PM, "Alex Harui"  wrote:
>>
>> >
>> >
>> >On 3/6/17, 1:26 PM, "piotrz"  wrote:
>> >
>> >>Hi Peter,
>> >>
>> >>It looks awesome. Cause if I'm enough skilled in CSS I can do whatever
>> >>layout I want and I don't need to know any other one. - In theory. :)
>> >
>> >True, but like with everything else in FlexJS, we are trying to
>> >encapsulate common patterns and make them easier to use.
>> >
>> >So for example if you have 3 children in a container and want to make
>>the
>> >first one stretchy,  you might have to write:
>> >
>> >
>> >  
>> >  
>> >  
>> >
>> >
>> >Whereas with a layout you could write:
>> >
>> >  
>> >
>> >  
>> >
>> >
>> >That way you don't have to remember the names of the styles or look up
>>how
>> >to do it.
>> >
>> >Hopefully our Layouts will essentially do just that once Peter's done
>>with
>> >this refactor.
>> >
>> >Of course, I could be wrong...
>> >-Alex
>> >
>>
>>
>
>
>-- 
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.

Re: [FlexJS] Group container

[Carlos Rovira]

Hi Peter, I think this awesome. get rid of the hardcoded styles in
component classes is such important thing and first point not only in your
effort of create a good layout strategy, but an important previous step if
we want to implement theming in FlexJS.

Great! :D

Carlos


2017-03-07 14:23 GMT+01:00 Peter Ent :

> This is the theory, yes. A way to do your own thing using AS and MXML to
> construct the app which then generates the right amount of HTML structure,
> making it easier to style. Or use pre-built constructions and layouts as
> templates that also generate the right amount of HTML structure.
>
> I'm thinking that Panel would be a good case for a composite component and
> maybe even move it into Express. In theory, you can compose a Panel from:
>
>  with VerticalFlexLayout
>  with Horizontal Flex Layout for the Title Bar
>  to provide scrollable area
>  with Horizontal Flex Layout for the Control Bar
> 
>
> We'll see how this goes.
> ‹peter
>
> On 3/6/17, 5:02 PM, "Alex Harui"  wrote:
>
> >
> >
> >On 3/6/17, 1:26 PM, "piotrz"  wrote:
> >
> >>Hi Peter,
> >>
> >>It looks awesome. Cause if I'm enough skilled in CSS I can do whatever
> >>layout I want and I don't need to know any other one. - In theory. :)
> >
> >True, but like with everything else in FlexJS, we are trying to
> >encapsulate common patterns and make them easier to use.
> >
> >So for example if you have 3 children in a container and want to make the
> >first one stretchy,  you might have to write:
> >
> >
> >  
> >  
> >  
> >
> >
> >Whereas with a layout you could write:
> >
> >  
> >
> >  
> >
> >
> >That way you don't have to remember the names of the styles or look up how
> >to do it.
> >
> >Hopefully our Layouts will essentially do just that once Peter's done with
> >this refactor.
> >
> >Of course, I could be wrong...
> >-Alex
> >
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS][FalconJX] Dual output Compilation

[Harbs]

The second time, it worked.

> On Mar 7, 2017, at 12:40 PM, Harbs  wrote:
> 
> Bah. I’m getting the following when I try to install dual:
> 
> Installer version 3.2.0 (mac)
> Using Locale: en_US
> Fetched the SDK download mirror URL from the CGI.
> SDK version Apache FlexJS Dual
> AIR version 3.1
> Flash Player version 11.1
> Creating Apache FlexJS home
> Creating temporary directory
> Downloading Apache FlexJS 
> from:http://apacheflexbuild.cloudapp.net:8080/job/flex-asjs-dual/lastSuccessfulBuild/artifact/out/apache-flex-flexjs-0.8.0-bin.tar.gz
> Unable to download Apache Flex SDK
> Installation aborted
> 
>> On Mar 7, 2017, at 3:30 AM, Alex Harui  wrote:
>> 
>> Hi,
>> 
>> I think I finally have the dual branch operational enough for folks to
>> poke at.  There is one issue with FB integration where it keeps starting a
>> compile right after the previous compile finishes.  I'm looking into that
>> today, but for now I just go to Project Properties and switch to another
>> FlexJS SDK.
>> 
>> One goal of the dual branch was to have one invocation of the compiler
>> generate both SWF and JS output.  That way, if you are using an IDE like
>> FlashBuilder and save your changes, the compiler will generate both SWF
>> and JS and catch any differences in the underlying APIs.
>> 
>> Another goal was to allow FlexJS classes to generate overrides of Flash
>> classes but with FlexJS types.  This would give us better control over the
>> APIs presented to FlexJS customers.  For example, in Flash, Sprite has a
>> dispatchEvent method that takes a flash.events.Event.  We'd like to tell
>> our users that UIBase has a dispatchEvent that takes an
>> org.apache.flex.events.Event.  But if you write:
>> 
>> class UIBase extends Sprite
>> {
>>   override public function
>> dispatchEvent(event:org.apache.flex.events.Event):Boolean
>>   {
>>   }
>> }
>> 
>> The compiler normally returns an error since the base class has:
>> 
>> public function dispatchEvent(event:flash.events.Event):Boolean
>> 
>> 
>> But now we can add metadata to our dispatchEvent override.
>> 
>> [SWFOverride(params="flash.events.Event",
>> altparams="org.apache.flex.events.Event:org.apache.flex.events.MouseEvent")
>> ]
>> override public function
>> dispatchEvent(event:org.apache.flex.events.Event):Boolean
>> 
>> And the FlexJS compiler will allow the override without an error.
>> However, it will actually generate SWF code for event being a
>> flash.events.Event since the runtime would otherwise throw an exception
>> about illegal overrides. As long as org.apache.flex.events.Event extends
>> flash.events.Event on the SWF side, then the code will operate normally in
>> the player.
>> 
>> 
>> The combination of these two goals make Flash Builder integration a bit
>> more seamless.  Before, you would save your changes and compile a SWF,
>> then go and run an Eclipse launch script that ran the cross-compiler.  And
>> errors found during the cross-compile couldn't be clicked on in the
>> problems pane.  But now, on each save you spend a bit more time compiling
>> for both platforms, but you immediately see errors against the JS APIs and
>> can examine them from the problems pane.  I found some missing APIs while
>> testing this.
>> 
>> In addition, the flex-config.xml and air-config.xml files have between
>> tweaked to be JS-oriented.  IOW, the external-library-path and
>> library-path in those files point to JS.swc and the FlexJS JS SWCs (like
>> BasicJS.swc).  This means that code-hinting is oriented towards the JS API
>> surface. That prevents a lot of Flash-only APIs from showing up in the
>> code hinting.  We might want to figure out a way to hide APIs since some
>> of the offerings don't have Flash support either.
>> 
>> One cool outcome of this work is that we can now generate the JS output
>> without playerglobal.swc or airglobal.swc.  I think they are needed for
>> Flash Builder to think of the SDK as a Flex SDK, but if you are not using
>> FB and just using Ant or Maven, it should be possible to create a release
>> package for those Ant and Maven customers that have no Adobe dependencies!
>> Of course, that means that you won't get SWF output, which I think is
>> still beneficial for many reasons, but if you think you don't need the SWF
>> output, we could come up with a release package that is truly all ALv2
>> compatible.
>> 
>> I made changes to the Maven mojos to exercise this dual output code, but
>> I'm waiting on Christofer and other maven experts to decide whether I've
>> broken any Maven rules.   Maven doesn't really need these changes since
>> you essentially dictate what outputs you want in the POM anyway.  The main
>> benefit of dual output was for IDEs like Flash Builder.
>> 
>> Anyway, you can try to use the Installer and install the FlexJS Dual build
>> or build it from the repos.  If you use the repos, be sure to get both the
>> flex-falcon and flex-asjs dual branches and build flex-falcon first.
>> 
>> Let me know what you think.
>> -Al

Re: [FlexJS] Group container

[Peter Ent]

This is the theory, yes. A way to do your own thing using AS and MXML to
construct the app which then generates the right amount of HTML structure,
making it easier to style. Or use pre-built constructions and layouts as
templates that also generate the right amount of HTML structure.

I'm thinking that Panel would be a good case for a composite component and
maybe even move it into Express. In theory, you can compose a Panel from:

 with VerticalFlexLayout
 with Horizontal Flex Layout for the Title Bar
 to provide scrollable area
 with Horizontal Flex Layout for the Control Bar


We'll see how this goes.
‹peter

On 3/6/17, 5:02 PM, "Alex Harui"  wrote:

>
>
>On 3/6/17, 1:26 PM, "piotrz"  wrote:
>
>>Hi Peter,
>>
>>It looks awesome. Cause if I'm enough skilled in CSS I can do whatever
>>layout I want and I don't need to know any other one. - In theory. :)
>
>True, but like with everything else in FlexJS, we are trying to
>encapsulate common patterns and make them easier to use.
>
>So for example if you have 3 children in a container and want to make the
>first one stretchy,  you might have to write:
>
>
>  
>  
>  
>
>
>Whereas with a layout you could write:
>
>  
>
>  
>
>
>That way you don't have to remember the names of the styles or look up how
>to do it.
>
>Hopefully our Layouts will essentially do just that once Peter's done with
>this refactor.
>
>Of course, I could be wrong...
>-Alex
>

Re: git commit: [flex-asjs] [refs/heads/develop] - Introducing the Group container.

[Peter Ent]

Will do on the my check-in.
‹peter

On 3/6/17, 2:28 PM, "Piotr Zarzycki"  wrote:

>Hi Peter,
>
>Nice job! Could you please add @productversion FlexJS 0.8 ? I think it can
>be useful in future.
>
>Thanks,
>Piotr
>
>2017-03-06 19:15 GMT+01:00 :
>
>> Repository: flex-asjs
>> Updated Branches:
>>   refs/heads/develop 8fe2f0831 -> 79d45cba0
>>
>>
>> Introducing the Group container.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/79d45cba
>> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/79d45cba
>> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/79d45cba
>>
>> Branch: refs/heads/develop
>> Commit: 79d45cba0616e394fddb68835859b1ffc87e6c48
>> Parents: 8fe2f08
>> Author: Peter Ent 
>> Authored: Mon Mar 6 13:15:34 2017 -0500
>> Committer: Peter Ent 
>> Committed: Mon Mar 6 13:15:34 2017 -0500
>>
>> --
>>  .../projects/HTML/src/main/flex/HTMLClasses.as  |   4 +-
>>  .../main/flex/org/apache/flex/core/GroupBase.as | 301
>>+++
>>  .../src/main/flex/org/apache/flex/html/Group.as |  92 ++
>>  .../org/apache/flex/html/beads/GroupView.as | 269 +
>>  .../flex/html/beads/layouts/BasicLayout.as  |  73 +
>>  .../HTML/src/main/resources/basic-manifest.xml  |   1 +
>>  .../HTML/src/main/resources/defaults.css|  10 +
>>  7 files changed, 689 insertions(+), 61 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
>> 79d45cba/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> --
>> diff --git a/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> b/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> index bfe204b..41cb877 100644
>> --- a/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> +++ b/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> @@ -26,8 +26,7 @@ package
>>   *  from the classes specified in manifest.xml.
>>   */
>>  internal class HTMLClasses
>> -{
>> -
>> +{
>>  import org.apache.flex.html.ToolTip; ToolTip;
>> import 
>>org.apache.flex.html.accessories.NumericOnlyTextInputBead;
>> NumericOnlyTextInputBead;
>> import org.apache.flex.html.beads.DispatchInputFinishedBead;
>> DispatchInputFinishedBead;
>> @@ -45,6 +44,7 @@ internal class HTMLClasses
>> }
>> import org.apache.flex.html.beads.ComboBoxView; ComboBoxView;
>>  import org.apache.flex.html.beads.ContainerView; ContainerView;
>> +   import org.apache.flex.html.beads.GroupView; GroupView;
>> COMPILE::SWF
>> {
>> import org.apache.flex.html.beads.ControlBarMeasurementBead;
>> ControlBarMeasurementBead;
>>
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
>> 79d45cba/frameworks/projects/HTML/src/main/flex/org/apache/
>> flex/core/GroupBase.as
>> --
>> diff --git 
>>a/frameworks/projects/HTML/src/main/flex/org/apache/flex/core/GroupBase.a
>>s
>> 
>>b/frameworks/projects/HTML/src/main/flex/org/apache/flex/core/GroupBase.a
>>s
>> new file mode 100644
>> index 000..7b945cc
>> --- /dev/null
>> +++ b/frameworks/projects/HTML/src/main/flex/org/apache/flex/
>> core/GroupBase.as
>> @@ -0,0 +1,301 @@
>> +///
>> /
>> +//
>> +//  Licensed to the Apache Software Foundation (ASF) under one or more
>> +//  contributor license agreements.  See the NOTICE file distributed
>>with
>> +//  this work for additional information regarding copyright ownership.
>> +//  The ASF licenses this file to You under the Apache License, Version
>> 2.0
>> +//  (the "License"); you may not use this file except in compliance
>>with
>> +//  the License.  You may obtain a copy of the License at
>> +//
>> +//  http://www.apache.org/licenses/LICENSE-2.0
>> +//
>> +//  Unless required by applicable law or agreed to in writing, software
>> +//  distributed under the License is distributed on an "AS IS" BASIS,
>> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> +//  See the License for the specific language governing permissions and
>> +//  limitations under the License.
>> +//
>> +///
>> /
>> +package org.apache.flex.core
>> +{
>> +   import org.apache.flex.core.IMXMLDocument;
>> +   import org.apache.flex.core.ValuesManager;
>> +   import org.apache.flex.events.Event;
>> +   import org.apache.flex.events.ValueChangeEvent;
>> +   import org.apache.flex.states.State;
>> +   import org.apache.flex.utils.MXMLDataInterpreter;
>> +
>> +/**
>> + *  Indicates that the state change has completed.  All properties
>> +

[FlexJS] Dual branch

[Christofer Dutz]

Hi guys and especially Alex,

I would like to ask you to give a short summary at what you changed in the dual 
branch. I don’t quite know as to what I should be looking for to make Maven 
support to match.

Could you please summarize what new compiler options/arguments, which 
new/changed/obsolete compilation runs and how the packaging should have changed?
Right now, I still see swc and js-swc as output of the compilation. I would 
expect one single swc to come out and this to contain two catalog.xml … ist 
that correct?

Thanks in advance,
  Chris

Re: [compc] error #3

[Harbs]

Related:

This produces an error: Syntax error: ‘class’ is not allowed here.
xml.@class = elem.styleName;

and the following gets a null pointer:
xml.@["class"] = elem.styleName;

That doesn’t leave many options for assigning a “class” attribute to XML.. ;-)

> On Mar 7, 2017, at 1:09 PM, Harbs  wrote:
> 
> Bingo.
> 
> This is causing an error:
> var version:String = xmlToParse.@["version”];
> 
> Changing it to the following works:
> var version:String = xmlToParse.@version;
> 
> 
>> On Mar 6, 2017, at 9:31 PM, Alex Harui  wrote:
>> 
>> Ah, after, digging deeper, it is the @ operator in XML.  And some bugs
>> around that were also fixed in Dual.
>> 
>> I think you can try dual now.  It is only failing on checkintests and I
>> just pushed the fix for that.
>> 
>> If you wait about 30 minutes, and you see the build passes email, you can
>> try getting dual from the Installer.  I'll be sending out an email with
>> more info later today.
>> 
>> -Alex
>> 
>> On 3/6/17, 11:23 AM, "Harbs"  wrote:
>> 
>>> I can’t find anything like that. Still looking…
>>> 
 On Mar 6, 2017, at 8:21 PM, Alex Harui  wrote:
 
 Looks like there is a unary operator that isn't expected.  Is there an
 "at" operator in AS?
 
 -Alex
 
 On 3/6/17, 10:06 AM, "Harbs"  wrote:
 
> I eliminated my compilation errors, but I’m having trouble outputting
> my
> swc.
> 
> AFAICT compile-asjs-swc is working correctly. I get a swc with the
> library.swf and catalog.xml which at first glance has all the classes.
> 
> However, I’m getting weird results from compile-asjs. Instead of the js
> files being stuffed into the swc, I’m getting a second file calles
> TLF.swc.new and it appears to be corrupted.
> 
> Here is the ant script for compile-asjs:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> There appears to be another null pointer error in the compiler. Here’s
> the end of my output:
> 
>  [java] Compiling file:
> org.apache.flex.textLayout.conversion.TextLayoutImporter
>  [java] java.lang.NullPointerException
>  [java] 5.230256392 seconds
>  [java] 
> 
> org.apache.flex.compiler.internal.codegen.as.ASBeforeNodeStrategy.handle
> (A
> 
> SBeforeNodeStrategy.java:47)org.apache.flex.compiler.internal.visitor.as
> .B
> 
> eforeAfterStrategy.before(BeforeAfterStrategy.java:139)org.apache.flex.c
> om
> 
> piler.internal.visitor.as.BeforeAfterStrategy.handle(BeforeAfterStrategy
> .j
> 
> ava:109)org.apache.flex.compiler.internal.codegen.as.ASBlockWalker.walk(
> AS
> 
> BlockWalker.java:157)org.apache.flex.compiler.internal.codegen.js.flexjs
> .J
> 
> SFlexJSEmitter.emitUnaryOperator(JSFlexJSEmitter.java:1064)org.apache.fl
> ex
> 
> .compiler.internal.codegen.as.ASBlockWalker.visitUnaryOperator(ASBlockWa
> lk
> 
> er.java:532)org.apache.flex.compiler.internal.visitor.as.ASNodeSwitch.ha
> nd
> 
> le(ASNodeSwitch.java:353)org.apache.flex.compiler.internal.visitor.as.AS
> No
> 
> deHandler.handle(ASNodeHandler.java:85)org.apache.flex.compiler.internal
> .v
> 
> isitor.as.BeforeAfterStrategy.handle(BeforeAfterStrategy.java:110)org.ap
> ac
> 
> he.flex.compiler.internal.codegen.as.ASBlockWalker.walk(ASBlockWalker.ja
> va
> 
> :157)org.apache.flex.compiler.internal.codegen.js.jx.DynamicAccessEmitte
> r.
> 
> emit(DynamicAccessEmitter.java:41)org.apache.flex.compiler.internal.code
> ge
> 
> n.js.jx.DynamicAccessEmitter.emit(DynamicAccessEmitter.java:29)org.apach
> e.
> 
> flex.compiler.internal.codegen.js.JSEmitter.emitDynamicAccess(JSEmitter.
> ja
> 
> va:296)org.apache.flex.compiler.internal.codegen.as.ASBlockWalker.visitD
> yn
> 
> amicAccess(ASBlockWalker.java:496)org.apache.flex.compiler.internal.visi
> to
> 
> r.as.ASNodeSwitch.handle(ASNodeSwitch.java:250)org.apache.flex.compiler.
> in
> 
> ternal.visitor.as.ASNodeHandler.handle(ASNodeHandler.java:85)org.apache.
> fl
> 
> ex.compiler.internal.visitor.as.BeforeAfterStrategy.handle(BeforeAfterSt
> ra
> 
> tegy.java:110)org.apache.flex.compiler.internal.codegen.as.ASBlockWalker
> .w
> 
> alk(ASBlockWalker.java:157)org.apache.flex.compiler.internal.codegen.as.
> AS
> 
> Emitter.stringifyNode(ASEmitter.java:1555)org.apache.flex.compiler.inter
> na
> 
> l.codegen.js.jx.MemberAccessEmitter.emit(MemberAccessEmitter.java:96)org
> .a
> 
> pache.flex.compiler.internal.codegen.js.flexjs.JSFlexJSEmitter.emitMembe
> rA
> 
> ccessExpression(JSFlexJSEmitter.java

Re: [compc] error #3

[Harbs]

Bingo.

This is causing an error:
var version:String = xmlToParse.@["version”];

Changing it to the following works:
var version:String = xmlToParse.@version;


> On Mar 6, 2017, at 9:31 PM, Alex Harui  wrote:
> 
> Ah, after, digging deeper, it is the @ operator in XML.  And some bugs
> around that were also fixed in Dual.
> 
> I think you can try dual now.  It is only failing on checkintests and I
> just pushed the fix for that.
> 
> If you wait about 30 minutes, and you see the build passes email, you can
> try getting dual from the Installer.  I'll be sending out an email with
> more info later today.
> 
> -Alex
> 
> On 3/6/17, 11:23 AM, "Harbs"  wrote:
> 
>> I can’t find anything like that. Still looking…
>> 
>>> On Mar 6, 2017, at 8:21 PM, Alex Harui  wrote:
>>> 
>>> Looks like there is a unary operator that isn't expected.  Is there an
>>> "at" operator in AS?
>>> 
>>> -Alex
>>> 
>>> On 3/6/17, 10:06 AM, "Harbs"  wrote:
>>> 
 I eliminated my compilation errors, but I’m having trouble outputting
 my
 swc.
 
 AFAICT compile-asjs-swc is working correctly. I get a swc with the
 library.swf and catalog.xml which at first glance has all the classes.
 
 However, I’m getting weird results from compile-asjs. Instead of the js
 files being stuffed into the swc, I’m getting a second file calles
 TLF.swc.new and it appears to be corrupted.
 
 Here is the ant script for compile-asjs:
 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
 
 There appears to be another null pointer error in the compiler. Here’s
 the end of my output:
 
   [java] Compiling file:
 org.apache.flex.textLayout.conversion.TextLayoutImporter
   [java] java.lang.NullPointerException
   [java] 5.230256392 seconds
   [java] 
 
 org.apache.flex.compiler.internal.codegen.as.ASBeforeNodeStrategy.handle
 (A
 
 SBeforeNodeStrategy.java:47)org.apache.flex.compiler.internal.visitor.as
 .B
 
 eforeAfterStrategy.before(BeforeAfterStrategy.java:139)org.apache.flex.c
 om
 
 piler.internal.visitor.as.BeforeAfterStrategy.handle(BeforeAfterStrategy
 .j
 
 ava:109)org.apache.flex.compiler.internal.codegen.as.ASBlockWalker.walk(
 AS
 
 BlockWalker.java:157)org.apache.flex.compiler.internal.codegen.js.flexjs
 .J
 
 SFlexJSEmitter.emitUnaryOperator(JSFlexJSEmitter.java:1064)org.apache.fl
 ex
 
 .compiler.internal.codegen.as.ASBlockWalker.visitUnaryOperator(ASBlockWa
 lk
 
 er.java:532)org.apache.flex.compiler.internal.visitor.as.ASNodeSwitch.ha
 nd
 
 le(ASNodeSwitch.java:353)org.apache.flex.compiler.internal.visitor.as.AS
 No
 
 deHandler.handle(ASNodeHandler.java:85)org.apache.flex.compiler.internal
 .v
 
 isitor.as.BeforeAfterStrategy.handle(BeforeAfterStrategy.java:110)org.ap
 ac
 
 he.flex.compiler.internal.codegen.as.ASBlockWalker.walk(ASBlockWalker.ja
 va
 
 :157)org.apache.flex.compiler.internal.codegen.js.jx.DynamicAccessEmitte
 r.
 
 emit(DynamicAccessEmitter.java:41)org.apache.flex.compiler.internal.code
 ge
 
 n.js.jx.DynamicAccessEmitter.emit(DynamicAccessEmitter.java:29)org.apach
 e.
 
 flex.compiler.internal.codegen.js.JSEmitter.emitDynamicAccess(JSEmitter.
 ja
 
 va:296)org.apache.flex.compiler.internal.codegen.as.ASBlockWalker.visitD
 yn
 
 amicAccess(ASBlockWalker.java:496)org.apache.flex.compiler.internal.visi
 to
 
 r.as.ASNodeSwitch.handle(ASNodeSwitch.java:250)org.apache.flex.compiler.
 in
 
 ternal.visitor.as.ASNodeHandler.handle(ASNodeHandler.java:85)org.apache.
 fl
 
 ex.compiler.internal.visitor.as.BeforeAfterStrategy.handle(BeforeAfterSt
 ra
 
 tegy.java:110)org.apache.flex.compiler.internal.codegen.as.ASBlockWalker
 .w
 
 alk(ASBlockWalker.java:157)org.apache.flex.compiler.internal.codegen.as.
 AS
 
 Emitter.stringifyNode(ASEmitter.java:1555)org.apache.flex.compiler.inter
 na
 
 l.codegen.js.jx.MemberAccessEmitter.emit(MemberAccessEmitter.java:96)org
 .a
 
 pache.flex.compiler.internal.codegen.js.flexjs.JSFlexJSEmitter.emitMembe
 rA
 
 ccessExpression(JSFlexJSEmitter.java:742)org.apache.flex.compiler.intern
 al
 
 .codegen.as.ASBlockWalker.visitMemberAccessExpression(ASBlockWalker.java
 :4
 
 81)org.apache.flex.compiler.internal.visitor.as.ASNodeSwitch.handle(ASNo
 de
 
 Switch.java:339)org.apache.flex.compiler.internal.visitor.as.ASNodeHandl
 er
 
 .handle(ASNodeHandler.java:85)org.apache.flex.compiler.internal.visitor.
 as
 
 .BeforeAfterStrategy.handle(B

RE: [FlexJS] Embed Workaround

[yishayw]

I guess nightly wasn't up2date. After rebuilding falcon I'm not getting
anymore compile errors with embed. Thanks.

I added

org.apache.flex.core.ByteArrayAsset
to
Graphics\src\main\config\compile-as-config.xml

to make the ant build work, however my Maven build is failing. Where is the
standard place to add a compiler option for Maven?



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Embed-Workaround-tp60136p60204.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][FalconJX] Dual output Compilation

[Harbs]

Bah. I’m getting the following when I try to install dual:

Installer version 3.2.0 (mac)
Using Locale: en_US
Fetched the SDK download mirror URL from the CGI.
SDK version Apache FlexJS Dual
AIR version 3.1
Flash Player version 11.1
Creating Apache FlexJS home
Creating temporary directory
Downloading Apache FlexJS 
from:http://apacheflexbuild.cloudapp.net:8080/job/flex-asjs-dual/lastSuccessfulBuild/artifact/out/apache-flex-flexjs-0.8.0-bin.tar.gz
Unable to download Apache Flex SDK
Installation aborted

> On Mar 7, 2017, at 3:30 AM, Alex Harui  wrote:
> 
> Hi,
> 
> I think I finally have the dual branch operational enough for folks to
> poke at.  There is one issue with FB integration where it keeps starting a
> compile right after the previous compile finishes.  I'm looking into that
> today, but for now I just go to Project Properties and switch to another
> FlexJS SDK.
> 
> One goal of the dual branch was to have one invocation of the compiler
> generate both SWF and JS output.  That way, if you are using an IDE like
> FlashBuilder and save your changes, the compiler will generate both SWF
> and JS and catch any differences in the underlying APIs.
> 
> Another goal was to allow FlexJS classes to generate overrides of Flash
> classes but with FlexJS types.  This would give us better control over the
> APIs presented to FlexJS customers.  For example, in Flash, Sprite has a
> dispatchEvent method that takes a flash.events.Event.  We'd like to tell
> our users that UIBase has a dispatchEvent that takes an
> org.apache.flex.events.Event.  But if you write:
> 
>  class UIBase extends Sprite
>  {
>override public function
> dispatchEvent(event:org.apache.flex.events.Event):Boolean
>{
>}
>  }
> 
> The compiler normally returns an error since the base class has:
> 
>  public function dispatchEvent(event:flash.events.Event):Boolean
> 
> 
> But now we can add metadata to our dispatchEvent override.
> 
>  [SWFOverride(params="flash.events.Event",
> altparams="org.apache.flex.events.Event:org.apache.flex.events.MouseEvent")
> ]
>  override public function
> dispatchEvent(event:org.apache.flex.events.Event):Boolean
> 
> And the FlexJS compiler will allow the override without an error.
> However, it will actually generate SWF code for event being a
> flash.events.Event since the runtime would otherwise throw an exception
> about illegal overrides. As long as org.apache.flex.events.Event extends
> flash.events.Event on the SWF side, then the code will operate normally in
> the player.
> 
> 
> The combination of these two goals make Flash Builder integration a bit
> more seamless.  Before, you would save your changes and compile a SWF,
> then go and run an Eclipse launch script that ran the cross-compiler.  And
> errors found during the cross-compile couldn't be clicked on in the
> problems pane.  But now, on each save you spend a bit more time compiling
> for both platforms, but you immediately see errors against the JS APIs and
> can examine them from the problems pane.  I found some missing APIs while
> testing this.
> 
> In addition, the flex-config.xml and air-config.xml files have between
> tweaked to be JS-oriented.  IOW, the external-library-path and
> library-path in those files point to JS.swc and the FlexJS JS SWCs (like
> BasicJS.swc).  This means that code-hinting is oriented towards the JS API
> surface. That prevents a lot of Flash-only APIs from showing up in the
> code hinting.  We might want to figure out a way to hide APIs since some
> of the offerings don't have Flash support either.
> 
> One cool outcome of this work is that we can now generate the JS output
> without playerglobal.swc or airglobal.swc.  I think they are needed for
> Flash Builder to think of the SDK as a Flex SDK, but if you are not using
> FB and just using Ant or Maven, it should be possible to create a release
> package for those Ant and Maven customers that have no Adobe dependencies!
> Of course, that means that you won't get SWF output, which I think is
> still beneficial for many reasons, but if you think you don't need the SWF
> output, we could come up with a release package that is truly all ALv2
> compatible.
> 
> I made changes to the Maven mojos to exercise this dual output code, but
> I'm waiting on Christofer and other maven experts to decide whether I've
> broken any Maven rules.   Maven doesn't really need these changes since
> you essentially dictate what outputs you want in the POM anyway.  The main
> benefit of dual output was for IDEs like Flash Builder.
> 
> Anyway, you can try to use the Installer and install the FlexJS Dual build
> or build it from the repos.  If you use the repos, be sure to get both the
> flex-falcon and flex-asjs dual branches and build flex-falcon first.
> 
> Let me know what you think.
> -Alex
> 
> 
> 

RE: [FlexJS] Embed Workaround

[Yishay Weiss]

I’m getting

command line Error: unknown configuration variable 
'compiler.byte-array-embed-class'.

After downloading the nightly.

From: Alex Harui
Sent: Monday, March 6, 2017 9:35 PM
To: dev@flex.apache.org
Subject: Re: [FlexJS] Embed Workaround

I just pushed an untested attempt to allow using a different class for
embeds.  It is in the develop branch.

Normally, the compiler expects to find a flex SDK swc with
mx.core.ByteArrayAsset in it.  You should be able to create an
org.apache.flex.core.ByteArrayAsset class that extends
flash.utils.ByteArray and add the compiler option
-compiler.byte-array-embed-class=org.apache.flex.core.ByteArrayAsset.  I
don't think the IFlexAsset interface is required.

HTH,
-Alex

On 3/6/17, 9:32 AM, "Harbs"  wrote:

>I’m sorry but you totally lost me there… ;-)
>
>What name, used where?
>
>I don’t understand how the [Embed] tag works and where the ByteArrayAsset
>comes from.
>
>> On Mar 6, 2017, at 7:27 PM, Alex Harui  wrote:
>>
>>
>>
>> On 3/6/17, 9:05 AM, "Harbs"  wrote:
>>
>>> How to add full support for [Embed] is a complicated question.
>>>
>>> I think it would be great to support it, but the details get sticky. I
>>> think we need a list of use cases for [Embed] to figure out the right
>>> behavior for each and a way to differentiate the use cases. On the
>>> simplest level, it could simply copy files and set src to the copied
>>> path. Maybe get fancy with BinaryData? What to do with BitmapData? What
>>> about Class assignment? I’m not sure what the right answer is to these
>>> questions.
>>>
>>> For the BlendBead, all we really need though, is SWF support. The JS
>>>side
>>> does not rely on the PixelBender files.
>>
>> Well, in keeping with other compiler changes, the answer would be to
>>make
>> the name of the ByteArrayAsset class configurable like we did for the
>> PropertyChangeEvent.  If you want a quick fix for now, just change the
>> name used in DataTranscoder.java.
>>
>> Thanks,
>> -Alex
>>
>