AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Christofer Dutz]

Well the Maven build went back to blue ... thanks for fixing :-)


I guess as I finished my work on the site deployment so the build works again. 
It's always worth to have a look at the official ASF Jenkins:


https://builds.apache.org/view/E-G/view/Flex/


Even if it builds with Maven, it does almost all of the tests and you should 
get feedback far more frequent as when using our external build system. And 
stuff that works with Ant and doesn't with Maven should be considered an error 
that needs further addressing.


Chris


Von: Alex Harui 
Gesendet: Mittwoch, 28. September 2016 02:51:23
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Right now, the flex_sdk Ant CI build is failing because a third-party
download is unavailable.  Once that comes back, flex_falcon will be built
again and hopefully it will all work.  Probably will take several hours to
shake out so don't spend any time thinking about it until after you see
the flex_sdk build pass again.

-Alex

On 9/27/16, 5:08 PM, "Greg Dove"  wrote:

>Alex, can you please let me know if this is related to something I did?
>Is there something I need to fix?
>I added some fixes this morning and checked that the maven build was
>working locally.
>But I don't know what I am doing that is different to the CI build.
>
>
>
>On Wed, Sep 28, 2016 at 12:40 PM, Alex Harui  wrote:
>
>> The CI Ant build now fails as well.  I just saw the email on the list.
>> The CI server keeps getting stuck on flex_sdk_test so Falcon hadn't run
>>in
>> a couple of days.  The CI falcon build also runs the sdk.dependent.tests
>> and flexjs.dependent.tests targets that don't run by default.
>>
>> -Alex
>>
>> On 9/27/16, 1:58 PM, "Christofer Dutz" 
>>wrote:
>>
>> >Hi Greg,
>> >
>> >
>> >Well investigating this had me worry a little ... not the problem
>>itself,
>> >but the Ant build seems to be reporting that all is fine and I could
>> >confirm the method being listed as successful in the build report.
>> >
>> >
>> >But even if I run the test in IntelliJ without Maven, the test fails
>>and
>> >from having a look at it, it should fail. So the question remains: why
>> >didn't the Ant build fail?
>> >
>> >
>> >Chris
>> >
>> >
>> >Von: Greg Dove 
>> >Gesendet: Dienstag, 27. September 2016 22:46:27
>> >An: dev@flex.apache.org
>> >Betreff: Re: [FlexJS] Problem with some test cases (@export was changed
>> >to @expose)?
>> >
>> >I wonder if I had something cached somewhere that needed an extra
>>'clean'
>> >-
>> >I am still learning this, I guess.
>> >
>> >On Wed, Sep 28, 2016 at 9:43 AM, Greg Dove  wrote:
>> >
>> >> I am working through these now with the maven build, I found a few
>>areas
>> >> that needed attention - sorry.
>> >> Yes I had expected this to work the same across the two builds as
>>well.
>> >>
>> >>
>> >>
>> >> On Wed, Sep 28, 2016 at 9:42 AM, Christofer Dutz <
>> >> christofer.d...@c-ware.de> wrote:
>> >>
>> >>> Ok ... so I tracked down the problem to
>> >>>
>> >>> JSGoogDocEmitter
>> >>>
>> >>> there in line 344 in emitPublic, you seem to have changed the
>>output.
>> >>>
>> >>> Should I adjust the testcase? I don't quite understand why the test
>> >>> doesn't break in the Ant build, because the output should be wrong
>> >>>there
>> >>> too ...
>> >>>
>> >>>
>> >>> Chris
>> >>>
>> >>>
>> >>> 
>> >>> Von: Greg Dove 
>> >>> Gesendet: Dienstag, 27. September 2016 19:53:45
>> >>> An: dev@flex.apache.org
>> >>> Betreff: Re: [FlexJS] Problem with some test cases (@export was
>>changed
>> >>> to @expose)?
>> >>>
>> >>> This was me, and was needed for reflection support into static
>>members.
>> >>>
>> >>> @expose is supposed to be deprecated, but currently seems to be the
>> >>>only
>> >>> option that works for statics. Josh discovered this a while back I
>> >>>think,
>> >>> with static accessors.
>> >>>
>> >>> I will check this test now, I thought I had them all updated.
>> >>>
>> >>> cheers
>> >>> Greg
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Sep 28, 2016 at 3:46 AM, Christofer Dutz <
>> >>> christofer.d...@c-ware.de>
>> >>> wrote:
>> >>>
>> >>> > Hi,
>> >>> >
>> >>> >
>> >>> > it seems some recent changes broke things in the test-suite. I am
>> >>> getting
>> >>> > failures in TestFlexJSClass.
>> >>> >
>> >>> > For:
>> >>> >
>> >>> >
>> >>> > org.apache.flex.compiler.internal.codegen.js.flexjs.
>> >>> > TestFlexJSClass#testConstants
>> >>> >
>> >>> >
>> >>> > and
>> >>> >
>> >>> >
>> >>> > org.apache.flex.compiler.internal.codegen.js.flexjs.
>> >>> > TestFlexJSClass#testMethods
>> >>> >
>> >>> >
>> >>> > it seems @export was changed to @expose ... would be cool if
>>someone
>> >>>who
>> >>> > knows what happened here could fix that.
>> >>> >
>> >>> >
>> >>> > Chris
>> >>> >
>> >>>
>> >>
>> >>
>>
>>

Re: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Greg Dove]

Chris, I was seeing something not working with Maven in typedefs, a patch
not being applied cleanly.
I did not see this with ant. Justin also checked and confirmed this.
Not sure if another url has changed?



On Wed, Sep 28, 2016 at 8:03 PM, Christofer Dutz 
wrote:

> Well the Maven build went back to blue ... thanks for fixing :-)
>
>
> I guess as I finished my work on the site deployment so the build works
> again. It's always worth to have a look at the official ASF Jenkins:
>
>
> https://builds.apache.org/view/E-G/view/Flex/
>
>
> Even if it builds with Maven, it does almost all of the tests and you
> should get feedback far more frequent as when using our external build
> system. And stuff that works with Ant and doesn't with Maven should be
> considered an error that needs further addressing.
>
>
> Chris
>
> 
> Von: Alex Harui 
> Gesendet: Mittwoch, 28. September 2016 02:51:23
> An: dev@flex.apache.org
> Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was
> changed to @expose)?
>
> Right now, the flex_sdk Ant CI build is failing because a third-party
> download is unavailable.  Once that comes back, flex_falcon will be built
> again and hopefully it will all work.  Probably will take several hours to
> shake out so don't spend any time thinking about it until after you see
> the flex_sdk build pass again.
>
> -Alex
>
> On 9/27/16, 5:08 PM, "Greg Dove"  wrote:
>
> >Alex, can you please let me know if this is related to something I did?
> >Is there something I need to fix?
> >I added some fixes this morning and checked that the maven build was
> >working locally.
> >But I don't know what I am doing that is different to the CI build.
> >
> >
> >
> >On Wed, Sep 28, 2016 at 12:40 PM, Alex Harui  wrote:
> >
> >> The CI Ant build now fails as well.  I just saw the email on the list.
> >> The CI server keeps getting stuck on flex_sdk_test so Falcon hadn't run
> >>in
> >> a couple of days.  The CI falcon build also runs the sdk.dependent.tests
> >> and flexjs.dependent.tests targets that don't run by default.
> >>
> >> -Alex
> >>
> >> On 9/27/16, 1:58 PM, "Christofer Dutz" 
> >>wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >
> >> >Well investigating this had me worry a little ... not the problem
> >>itself,
> >> >but the Ant build seems to be reporting that all is fine and I could
> >> >confirm the method being listed as successful in the build report.
> >> >
> >> >
> >> >But even if I run the test in IntelliJ without Maven, the test fails
> >>and
> >> >from having a look at it, it should fail. So the question remains: why
> >> >didn't the Ant build fail?
> >> >
> >> >
> >> >Chris
> >> >
> >> >
> >> >Von: Greg Dove 
> >> >Gesendet: Dienstag, 27. September 2016 22:46:27
> >> >An: dev@flex.apache.org
> >> >Betreff: Re: [FlexJS] Problem with some test cases (@export was changed
> >> >to @expose)?
> >> >
> >> >I wonder if I had something cached somewhere that needed an extra
> >>'clean'
> >> >-
> >> >I am still learning this, I guess.
> >> >
> >> >On Wed, Sep 28, 2016 at 9:43 AM, Greg Dove 
> wrote:
> >> >
> >> >> I am working through these now with the maven build, I found a few
> >>areas
> >> >> that needed attention - sorry.
> >> >> Yes I had expected this to work the same across the two builds as
> >>well.
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Sep 28, 2016 at 9:42 AM, Christofer Dutz <
> >> >> christofer.d...@c-ware.de> wrote:
> >> >>
> >> >>> Ok ... so I tracked down the problem to
> >> >>>
> >> >>> JSGoogDocEmitter
> >> >>>
> >> >>> there in line 344 in emitPublic, you seem to have changed the
> >>output.
> >> >>>
> >> >>> Should I adjust the testcase? I don't quite understand why the test
> >> >>> doesn't break in the Ant build, because the output should be wrong
> >> >>>there
> >> >>> too ...
> >> >>>
> >> >>>
> >> >>> Chris
> >> >>>
> >> >>>
> >> >>> 
> >> >>> Von: Greg Dove 
> >> >>> Gesendet: Dienstag, 27. September 2016 19:53:45
> >> >>> An: dev@flex.apache.org
> >> >>> Betreff: Re: [FlexJS] Problem with some test cases (@export was
> >>changed
> >> >>> to @expose)?
> >> >>>
> >> >>> This was me, and was needed for reflection support into static
> >>members.
> >> >>>
> >> >>> @expose is supposed to be deprecated, but currently seems to be the
> >> >>>only
> >> >>> option that works for statics. Josh discovered this a while back I
> >> >>>think,
> >> >>> with static accessors.
> >> >>>
> >> >>> I will check this test now, I thought I had them all updated.
> >> >>>
> >> >>> cheers
> >> >>> Greg
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Wed, Sep 28, 2016 at 3:46 AM, Christofer Dutz <
> >> >>> christofer.d...@c-ware.de>
> >> >>> wrote:
> >> >>>
> >> >>> > Hi,
> >> >>> >
> >> >>> >
> >> >>> > it seems some recent changes broke things in the test-suite. I am
> >> >>> getting
> >> >>> > failures in TestFlexJSClass.
> >> >>> >
> >> >>> > For:
> >> >>> >
> >> >>> >
> >> >>> > org.apache.flex.compiler.intern

AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Christofer Dutz]

Currently the framework seems to have problems ... I noticed that, but I was a 
little too consumed with my duties ad TAC member to deal with it ... I better 
have a look as soon as possible.


Chris


Von: Greg Dove 
Gesendet: Mittwoch, 28. September 2016 09:06:12
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Chris, I was seeing something not working with Maven in typedefs, a patch
not being applied cleanly.
I did not see this with ant. Justin also checked and confirmed this.
Not sure if another url has changed?



On Wed, Sep 28, 2016 at 8:03 PM, Christofer Dutz 
wrote:

> Well the Maven build went back to blue ... thanks for fixing :-)
>
>
> I guess as I finished my work on the site deployment so the build works
> again. It's always worth to have a look at the official ASF Jenkins:
>
>
> https://builds.apache.org/view/E-G/view/Flex/
>
>
> Even if it builds with Maven, it does almost all of the tests and you
> should get feedback far more frequent as when using our external build
> system. And stuff that works with Ant and doesn't with Maven should be
> considered an error that needs further addressing.
>
>
> Chris
>
> 
> Von: Alex Harui 
> Gesendet: Mittwoch, 28. September 2016 02:51:23
> An: dev@flex.apache.org
> Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was
> changed to @expose)?
>
> Right now, the flex_sdk Ant CI build is failing because a third-party
> download is unavailable.  Once that comes back, flex_falcon will be built
> again and hopefully it will all work.  Probably will take several hours to
> shake out so don't spend any time thinking about it until after you see
> the flex_sdk build pass again.
>
> -Alex
>
> On 9/27/16, 5:08 PM, "Greg Dove"  wrote:
>
> >Alex, can you please let me know if this is related to something I did?
> >Is there something I need to fix?
> >I added some fixes this morning and checked that the maven build was
> >working locally.
> >But I don't know what I am doing that is different to the CI build.
> >
> >
> >
> >On Wed, Sep 28, 2016 at 12:40 PM, Alex Harui  wrote:
> >
> >> The CI Ant build now fails as well.  I just saw the email on the list.
> >> The CI server keeps getting stuck on flex_sdk_test so Falcon hadn't run
> >>in
> >> a couple of days.  The CI falcon build also runs the sdk.dependent.tests
> >> and flexjs.dependent.tests targets that don't run by default.
> >>
> >> -Alex
> >>
> >> On 9/27/16, 1:58 PM, "Christofer Dutz" 
> >>wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >
> >> >Well investigating this had me worry a little ... not the problem
> >>itself,
> >> >but the Ant build seems to be reporting that all is fine and I could
> >> >confirm the method being listed as successful in the build report.
> >> >
> >> >
> >> >But even if I run the test in IntelliJ without Maven, the test fails
> >>and
> >> >from having a look at it, it should fail. So the question remains: why
> >> >didn't the Ant build fail?
> >> >
> >> >
> >> >Chris
> >> >
> >> >
> >> >Von: Greg Dove 
> >> >Gesendet: Dienstag, 27. September 2016 22:46:27
> >> >An: dev@flex.apache.org
> >> >Betreff: Re: [FlexJS] Problem with some test cases (@export was changed
> >> >to @expose)?
> >> >
> >> >I wonder if I had something cached somewhere that needed an extra
> >>'clean'
> >> >-
> >> >I am still learning this, I guess.
> >> >
> >> >On Wed, Sep 28, 2016 at 9:43 AM, Greg Dove 
> wrote:
> >> >
> >> >> I am working through these now with the maven build, I found a few
> >>areas
> >> >> that needed attention - sorry.
> >> >> Yes I had expected this to work the same across the two builds as
> >>well.
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Sep 28, 2016 at 9:42 AM, Christofer Dutz <
> >> >> christofer.d...@c-ware.de> wrote:
> >> >>
> >> >>> Ok ... so I tracked down the problem to
> >> >>>
> >> >>> JSGoogDocEmitter
> >> >>>
> >> >>> there in line 344 in emitPublic, you seem to have changed the
> >>output.
> >> >>>
> >> >>> Should I adjust the testcase? I don't quite understand why the test
> >> >>> doesn't break in the Ant build, because the output should be wrong
> >> >>>there
> >> >>> too ...
> >> >>>
> >> >>>
> >> >>> Chris
> >> >>>
> >> >>>
> >> >>> 
> >> >>> Von: Greg Dove 
> >> >>> Gesendet: Dienstag, 27. September 2016 19:53:45
> >> >>> An: dev@flex.apache.org
> >> >>> Betreff: Re: [FlexJS] Problem with some test cases (@export was
> >>changed
> >> >>> to @expose)?
> >> >>>
> >> >>> This was me, and was needed for reflection support into static
> >>members.
> >> >>>
> >> >>> @expose is supposed to be deprecated, but currently seems to be the
> >> >>>only
> >> >>> option that works for statics. Josh discovered this a while back I
> >> >>>think,
> >> >>> with static accessors.
> >> >>>
> >> >>> I will check this test now, I thought I had them all updated.
> >> >>>
> >> >>> cheers
> >> >>> Gr

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs]

The overhead to swfs seem to me like it’s really minimal. There’s not a lot of 
added code for using composition rather than inheritance.

Improving events is probably something which should be done for the JS side as 
well, so I’m not convinced that’s a major problem either. Some of the event 
issues we had had nothing to do with inheritance vs composition of Sprite and 
friends. It had to do with the fact that MouseEvent and Event are unrelated.

Additionally, I really don’t believe most folks will use swf output for much 
more than debugging purposes, so if there’s a little more overhead, so what?

Yes. Method and attribute conflicts were a major problem for us. This is 
especially true for code which is migrated from Flash. You get no compiler 
warnings, but things do not work as expected.

We’ve also done a lot of work on the sprite-refactor branch which would be hard 
to back-port.

In short, I think we should stick with composition and deal with the few issues 
it causes.

On Sep 27, 2016, at 10:43 PM, Alex Harui  wrote:

> Probably time to re-open this debate...
> 
> As I understand it, there are 3 issues:
> 
> 1.  When migrating code, it is important to where your code is relying on
> Flash APIs that aren't supported by FlexJS, but if UIBase extends Sprite
> the compiler will happily let your code make calls to Sprite APIs.
> 
> 2.  In code completion in Flash Builder and maybe other IDEs, lots of
> non-FlexJS APIs are offered.
> 
> 3.  When migrating code, an override of a SWF-only API will result in a
> compile error when compiling for JS since that API has no base class
> implementation on the JS side.  And vice versa.
> 
> Wrapping Sprite solves all of these problems, but introduces new ones like
> the need for a new event subsystem, and adds runtime and download overhead
> to every SWF.  I would rather solve these problems in the compiler so
> there is no runtime overhead.
> 
> Here are my latest thoughts:
> 
> A) We could require the exact same API surfaces on both SWF and JS but
> that seems like excessive overhead.  Would it be so bad if your code might
> run into a compile error during the JS compile if the SWF compile comes
> out clean?  I think that's a reasonable price to pay so everyone doesn't
> have to pay download and runtime overhead.
> B) I don't use Flash Builder code completion myself since I pretty much
> know the APIs.  When folks use it, do they want all public APIs or would
> they really want the list to be filtered to "usable" APIs.  For example,
> in Flex UIComponent, there are public APIs like the "initialized" property
> that application developers should not be setting.  I'm wondering if we
> should create different SWCs that have different APIs filtered on ASDoc
> directives so the "application" version of the SWC doesn't show APIs you
> shouldn't be using in building your app.  Of course, when you finally
> output something to run, you may still get errors if you used APIs we hid
> from you.  Having filters in ASDoc would also help ASDoc filter away APIs
> most folks won't need.
> 
> Thoughts?
> 
> -Alex
> 

Re: [FlexJS][VSCode-NextGenAS] Getting to work with VSCode

[Carlos Rovira]

Thanks Josh,

I updated asconfigc vía nom to 0.1.5 and now is working :)
Now that is compiling, I must figure how to run a simple example with
flexes components :)

2016-09-28 0:55 GMT+02:00 Josh Tynjala :

> Hey Carlos,
>
> The "unknown configuration variable" error was actually a bug in asconfigc.
> It was still trying to build a SWF. I guess I didn't test that path well
> enough, since I don't use the FlexJS components. Update asconfigc, and it
> should work now. Sorry about that!
>
> - Josh
>
> On Tue, Sep 27, 2016 at 2:53 PM, Carlos Rovira <
> carlos.rov...@codeoscopic.com> wrote:
>
> > Hi Josh,
> >
> > thanks for the responses:
> >
> > first, I try installing a Firefox VSCode debugger extension (Debugger for
> > Firefox 0.6.4 by Holger Benl) ...don't know if this is correct.
> > I add this in launch.json:
> >
> > {
> > "name": "Launch Firefox against debug.html, with sourcemaps",
> > "type": "firefox",
> > "request": "launch",
> > "file": "${workspaceRoot}/debug.html",
> > "sourceMaps": true,
> > "preLaunchTask": "asconfigc"
> > }
> >
> > (but says sourceMaps line is not supported)
> >
> > Anyway, selecting this config, firefox opens with the app running exactly
> > the same way as chrome, firefox stops not in Main but in a function
> called
> > by a click in a text. So, all the same as chrome.
> >
> > For 3.- I changed to "config": "flex" and I get imports and extends
> working
> > properly :)
> > but adding js-output-type like this:
> >
> > {
> > "config": "flex",
> > "compilerOptions": {
> > "debug": true,
> > "source-map": true*,*
> > *"js-output-type": "flexjs"*
> > },
> > "files":
> > [
> > "src/Main.as"
> > ]
> > }
> >
> > causes this compilation error:
> >
> > *command line*
> > *Error: unknown configuration variable 'source-map'.*
> >
> >
> > maybe is not correctly formulated?
> >
> > Regarding Maven, I'm talking with Chris about the config of a test
> project
> > and I think I have to dig a bit more on this. I'll report If I
> investigate
> > and find something useful.
> >
> > Thanks!
> >
> >
> >
> > 2016-09-27 19:36 GMT+02:00 Josh Tynjala :
> >
> > > Awesome. Thanks for the feedback, Carlos!
> > >
> > > In one of the browser debuggers (either Chrome or Firefox), I couldn't
> > get
> > > a breakpoint to work in the constructor of the main class. Just like
> you
> > > describe. Strangely, the main class constructor worked in the other
> > > browser's debugger, and constructors from other classes were fine in
> > both.
> > > Since I saw that you tried using VSCode's Chrome debugging extension,
> it
> > > must have been Firefox that worked properly with the main class
> > > constructor.
> > >
> > > I don't really know why this happens. I kind of wonder if the source
> map
> > > isn't fully loaded/parsed yet when the code starts running in Chrome.
> By
> > > the time the click listener is called, everything is finished
> > initializing,
> > > I guess. That seemed like the most likely explanation to me.
> > >
> > > I think you can tell the debugger to pause immediately after starting,
> so
> > > you might give that a try. If it works, let me know and I can make a
> note
> > > of it somewhere.
> > >
> > > 1. This is correct. For the initial release, I focused on ActionScript
> > > only. MXML probably isn't trivial, but hopefully the most challenging
> > parts
> > > of integrating with the compiler are already done, so it should be
> > easier.
> > >
> > > 2. Only the main class for your app is all that's required in the
> "files"
> > > field of asconfig.json. All dependencies will be detected by the
> > compiler.
> > > I just updated the description in the wiki to try to make that a little
> > > more clear. I'll get the description in the JSON schema updated too.
> > >
> > > A little background. In most cases, people pass only one class into
> > mxmlc,
> > > but technically, it supports passing in multiple classes, with the
> final
> > > one being considered the entry point. I think other classes that are
> > passed
> > > in are simply included, even if they aren't referenced. Probably so
> that
> > > they can be found by reflection or something.
> > >
> > > VSCode supports a similar tsconfig.json for TypeScript, and it also
> > allows
> > > multiple files to be passed in (but it resolves dependencies too). To
> me,
> > > it made sense to allow multiple files, even if it isn't commonly used.
> I
> > > think this just needs clear documentation so that people understand
> that
> > > they don't need to include every class that they use. Just the main
> one,
> > > most of the time.
> > >
> > > 3. Which libraries from the SDK are included depends on which "config"
> > > value you set in your asconfig.json. You probably want "config":
> "flex",
> > > but there's one gotcha to watch out for. By default, both the extension
> > and
> > > asconfigc consider "config": "flex"

Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import

[Carlos Rovira]

As Flex was evolving through the years and things like Swiz born, I always
want all this things implemented.
This haxe framework has more of the things you would want:
http://hexmachina.org/
But AFAIK, it lacks of something critical: MXML (for this reason haxe is
still no option for many of us, since the main focus is gaming and not
application development)

Flex has, for me, three key points that make it a pleasure to work with:
MXML, RPC (AMF mainly, but not alone) and Application System Manager
(managers, and all the things that make it work seamlessly). FlexJS, has
MXML, but still lacks RPC-AMF and App Sys Manager (AFAIK)

The things I would love to see in the future, and that will maintain the
difference with plain javascript frameworks and technologies will be
Generics, Anotations, Injection, IoC, and all modern facilities that are
already in server side but not in web front ends.

Btw, I think the import feature proposed by Josh will be cool



2016-09-27 17:10 GMT+02:00 Christofer Dutz :

> In general I have no objections and something like this could sometimes be
> really handy. But I with this we could be writing code that is called
> ActionScript3 but without it actually being ActionScript3.
>
>
> While preparing my talk to Solutions.Hamburg a few weeks ago, I had a
> detailed look at Typescript and noticed with a little jealousy some
> language features I would really like to have:
>
>
> - Generics
>
> - Arrow Functions
>
> - Enum types
>
>
> I guess we definitely shouldn't support all features, as I think a lot of
> them are simply crap, but if we were supporting these features we could
> eventually get more Typescript fans on board (Generics being the most
> important one from my point of view)
>
>
> I was thinking about proposing to define an ActionScript4 with file ending
> as4 so eventually this would be the better approach. Eventually it would be
> a good idea to start collecting features as we wouldn't want to do an AS5,
> AS6, ... AS2000 every now and then.
>
>
> Chris
>
> 
> Von: Josh Tynjala 
> Gesendet: Dienstag, 27. September 2016 16:59:33
> An: dev@flex.apache.org
> Betreff: [Falcon] Proposal for new ActionScript language feature:
> Optionally rename an import
>
> I would like to propose a new feature for the ActionScript language in the
> Apache Flex "Falcon" compiler. It would be nice if developers could
> (optionally) rename an import.
>
> Background
> ==
>
> Normally when you import a class, you can reference the name of the class,
> without the package (unless there is another class with the same name):
>
> // begin example
>
> import com.example.ImportedClass;
>
> var example:ImportedClass;
>
> //end example
>
> I would like to make it possible to optionally rename the shortened
> version, like this:
>
> // begin example
>
> import NewName = com.example.ImportedClass;
>
> var test:NewName;
>
> //end example
>
> This would make it possible to resolve ambiguities without using the
> fully-qualified class name. Consider the following situation that commonly
> comes up when developing Starling apps where the fully-qualified name is
> required for different types of events:
>
> // begin example
>
> import flash.events.Event;
> import starling.events.Event;
>
> var one:flash.events.Event;
> var two:starling.events.Event;
>
> // end example
>
> If we could rename imports, our code wouldn't require cumbersome
> fully-qualified names.
>
> Consider the following example, references to FlashEvent will resolve to
> flash.events.Event and StarlingEvent will resolve to starling.events.Event:
>
> // begin example
>
> import FlashEvent = flash.events.Event;
> import StarlingEvent = starling.events.Event;
>
> var one:FlashEvent;
> var two:StarlingEvent;
>
> // end example
>
> In the next example, references to FlashEvent will resolve to
> flash.events.Event, similar to the previous example. References to Event
> can resolve to starling.events.Event without ambiguity because
> flash.events.Event has been given a different name.
>
> // begin example
>
> import FlashEvent = flash.events.Event;
> import starling.events.Event;
>
> var one:FlashEvent;
> var two:Event;
>
> // end example
>
> This would also be useful for transpile-to-JS workflow where the top-level
> package is littered with a ton of HTML classes that may conflict with names
> user-defined classes. For instance, there's a top-level Event class. There
> is no way to specify a different fully-qualified name for things in the
> top-level package, so it's hard to resolve ambiguity when using these
> classes. We have a bit of a workaround in Falcon by supporting a fake
> "window." package, but that's not ideal. Especially if you consider
> Node.js, which doesn't actually have a global window object.
>
> Risks and Challenges
> ===
>
> * Renaming imports is a completely optional feature. Anyone can continue to
> code in ActionScript without ever using renamed imports.
> * Existing cod

AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Christofer Dutz]

Could one of you guys please have a look at what's going wrong?

I could track it back to the Framework expecting some different implementation 
of Class.as

This seems to be generated in the js externs module ... I could track it back 
to being generated by the missing.js (line 120ff)


I have no clue at what's going wrong here ... would be more than great if you 
could have a look at it.


Chris


Von: Christofer Dutz 
Gesendet: Mittwoch, 28. September 2016 09:20:52
An: dev@flex.apache.org
Betreff: AW: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Currently the framework seems to have problems ... I noticed that, but I was a 
little too consumed with my duties ad TAC member to deal with it ... I better 
have a look as soon as possible.


Chris


Von: Greg Dove 
Gesendet: Mittwoch, 28. September 2016 09:06:12
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Chris, I was seeing something not working with Maven in typedefs, a patch
not being applied cleanly.
I did not see this with ant. Justin also checked and confirmed this.
Not sure if another url has changed?



On Wed, Sep 28, 2016 at 8:03 PM, Christofer Dutz 
wrote:

> Well the Maven build went back to blue ... thanks for fixing :-)
>
>
> I guess as I finished my work on the site deployment so the build works
> again. It's always worth to have a look at the official ASF Jenkins:
>
>
> https://builds.apache.org/view/E-G/view/Flex/
>
>
> Even if it builds with Maven, it does almost all of the tests and you
> should get feedback far more frequent as when using our external build
> system. And stuff that works with Ant and doesn't with Maven should be
> considered an error that needs further addressing.
>
>
> Chris
>
> 
> Von: Alex Harui 
> Gesendet: Mittwoch, 28. September 2016 02:51:23
> An: dev@flex.apache.org
> Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was
> changed to @expose)?
>
> Right now, the flex_sdk Ant CI build is failing because a third-party
> download is unavailable.  Once that comes back, flex_falcon will be built
> again and hopefully it will all work.  Probably will take several hours to
> shake out so don't spend any time thinking about it until after you see
> the flex_sdk build pass again.
>
> -Alex
>
> On 9/27/16, 5:08 PM, "Greg Dove"  wrote:
>
> >Alex, can you please let me know if this is related to something I did?
> >Is there something I need to fix?
> >I added some fixes this morning and checked that the maven build was
> >working locally.
> >But I don't know what I am doing that is different to the CI build.
> >
> >
> >
> >On Wed, Sep 28, 2016 at 12:40 PM, Alex Harui  wrote:
> >
> >> The CI Ant build now fails as well.  I just saw the email on the list.
> >> The CI server keeps getting stuck on flex_sdk_test so Falcon hadn't run
> >>in
> >> a couple of days.  The CI falcon build also runs the sdk.dependent.tests
> >> and flexjs.dependent.tests targets that don't run by default.
> >>
> >> -Alex
> >>
> >> On 9/27/16, 1:58 PM, "Christofer Dutz" 
> >>wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >
> >> >Well investigating this had me worry a little ... not the problem
> >>itself,
> >> >but the Ant build seems to be reporting that all is fine and I could
> >> >confirm the method being listed as successful in the build report.
> >> >
> >> >
> >> >But even if I run the test in IntelliJ without Maven, the test fails
> >>and
> >> >from having a look at it, it should fail. So the question remains: why
> >> >didn't the Ant build fail?
> >> >
> >> >
> >> >Chris
> >> >
> >> >
> >> >Von: Greg Dove 
> >> >Gesendet: Dienstag, 27. September 2016 22:46:27
> >> >An: dev@flex.apache.org
> >> >Betreff: Re: [FlexJS] Problem with some test cases (@export was changed
> >> >to @expose)?
> >> >
> >> >I wonder if I had something cached somewhere that needed an extra
> >>'clean'
> >> >-
> >> >I am still learning this, I guess.
> >> >
> >> >On Wed, Sep 28, 2016 at 9:43 AM, Greg Dove 
> wrote:
> >> >
> >> >> I am working through these now with the maven build, I found a few
> >>areas
> >> >> that needed attention - sorry.
> >> >> Yes I had expected this to work the same across the two builds as
> >>well.
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Sep 28, 2016 at 9:42 AM, Christofer Dutz <
> >> >> christofer.d...@c-ware.de> wrote:
> >> >>
> >> >>> Ok ... so I tracked down the problem to
> >> >>>
> >> >>> JSGoogDocEmitter
> >> >>>
> >> >>> there in line 344 in emitPublic, you seem to have changed the
> >>output.
> >> >>>
> >> >>> Should I adjust the testcase? I don't quite understand why the test
> >> >>> doesn't break in the Ant build, because the output should be wrong
> >> >>>there
> >> >>> too ...
> >> >>>
> >> >>>
> >> >>> Chris
> >> >>>
> >> >>>
> >> >>> 
> >> >>> Von: Greg Dove 
> >> >>> 

AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Christofer Dutz]

Ok ... so I found out what the problem was :-)


I dug through the code and was confused why it didn't work, because it should 
have. Had a look at other changes applied to the compiler recently and these 
too didn't seem to have an effect. To me it looked as if it was using an old 
version of the compiler. Then it struck me and I had a look at the root pom of 
the typedefs. Here I set the version of the compiler to 0.7.0 for the release 
and didn't bump that to 0.8.0-SNAPSHOT after the release. So now with the 
0.8.0-SNAPSHOT version it seems to be working :-)


Chris


Von: Christofer Dutz 
Gesendet: Mittwoch, 28. September 2016 10:41:39
An: dev@flex.apache.org
Betreff: AW: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Could one of you guys please have a look at what's going wrong?

I could track it back to the Framework expecting some different implementation 
of Class.as

This seems to be generated in the js externs module ... I could track it back 
to being generated by the missing.js (line 120ff)


I have no clue at what's going wrong here ... would be more than great if you 
could have a look at it.


Chris


Von: Christofer Dutz 
Gesendet: Mittwoch, 28. September 2016 09:20:52
An: dev@flex.apache.org
Betreff: AW: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Currently the framework seems to have problems ... I noticed that, but I was a 
little too consumed with my duties ad TAC member to deal with it ... I better 
have a look as soon as possible.


Chris


Von: Greg Dove 
Gesendet: Mittwoch, 28. September 2016 09:06:12
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Chris, I was seeing something not working with Maven in typedefs, a patch
not being applied cleanly.
I did not see this with ant. Justin also checked and confirmed this.
Not sure if another url has changed?



On Wed, Sep 28, 2016 at 8:03 PM, Christofer Dutz 
wrote:

> Well the Maven build went back to blue ... thanks for fixing :-)
>
>
> I guess as I finished my work on the site deployment so the build works
> again. It's always worth to have a look at the official ASF Jenkins:
>
>
> https://builds.apache.org/view/E-G/view/Flex/
>
>
> Even if it builds with Maven, it does almost all of the tests and you
> should get feedback far more frequent as when using our external build
> system. And stuff that works with Ant and doesn't with Maven should be
> considered an error that needs further addressing.
>
>
> Chris
>
> 
> Von: Alex Harui 
> Gesendet: Mittwoch, 28. September 2016 02:51:23
> An: dev@flex.apache.org
> Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was
> changed to @expose)?
>
> Right now, the flex_sdk Ant CI build is failing because a third-party
> download is unavailable.  Once that comes back, flex_falcon will be built
> again and hopefully it will all work.  Probably will take several hours to
> shake out so don't spend any time thinking about it until after you see
> the flex_sdk build pass again.
>
> -Alex
>
> On 9/27/16, 5:08 PM, "Greg Dove"  wrote:
>
> >Alex, can you please let me know if this is related to something I did?
> >Is there something I need to fix?
> >I added some fixes this morning and checked that the maven build was
> >working locally.
> >But I don't know what I am doing that is different to the CI build.
> >
> >
> >
> >On Wed, Sep 28, 2016 at 12:40 PM, Alex Harui  wrote:
> >
> >> The CI Ant build now fails as well.  I just saw the email on the list.
> >> The CI server keeps getting stuck on flex_sdk_test so Falcon hadn't run
> >>in
> >> a couple of days.  The CI falcon build also runs the sdk.dependent.tests
> >> and flexjs.dependent.tests targets that don't run by default.
> >>
> >> -Alex
> >>
> >> On 9/27/16, 1:58 PM, "Christofer Dutz" 
> >>wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >
> >> >Well investigating this had me worry a little ... not the problem
> >>itself,
> >> >but the Ant build seems to be reporting that all is fine and I could
> >> >confirm the method being listed as successful in the build report.
> >> >
> >> >
> >> >But even if I run the test in IntelliJ without Maven, the test fails
> >>and
> >> >from having a look at it, it should fail. So the question remains: why
> >> >didn't the Ant build fail?
> >> >
> >> >
> >> >Chris
> >> >
> >> >
> >> >Von: Greg Dove 
> >> >Gesendet: Dienstag, 27. September 2016 22:46:27
> >> >An: dev@flex.apache.org
> >> >Betreff: Re: [FlexJS] Problem with some test cases (@export was changed
> >> >to @expose)?
> >> >
> >> >I wonder if I had something cached somewhere that needed an extra
> >>'clean'
> >> >-
> >> >I am still learning this, I guess.
> >> >
> >> >On Wed, Sep 28, 2016 at 9:43 AM, Greg Dove 
> wrote:
> >> >
> >> >> I am working through these now wit

[FlexJS] Circular dependency detected

[OK]

Hi,
while porting the "PureMVC EmployeeAdmin" demo to FlexJS I stumbled over the
"Circular dependency detected" issue several times.
I noticed that this was discussed here in the past but I can't find any
helpful informations.
So what I'd like to know if this is a bug with FlexJS (The swf version
works) or if I have to workaround this by re-organizing my code or if
there's any other chance to solve this issue.

Thanks for help!

Olaf





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

Re: [FlexJS] Circular dependency detected

[OK]

Forgot to mention:
Tried it with 0.7.0 and the nightly build.



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

AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Christofer Dutz]

Ok now the modules that were failing compile successfully. Unfortunately now a 
little more down the stream the examples seem to be failing. I am getting 
errors in the chart example (just the first example to be compiled) It seems 
the JS compilation is failing because it cant find generated classes.


https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20Framework%20(maven)/269/console


Did anything change in this part recently?


Chris


Von: Christofer Dutz 
Gesendet: Mittwoch, 28. September 2016 11:06:00
An: dev@flex.apache.org
Betreff: AW: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Ok ... so I found out what the problem was :-)


I dug through the code and was confused why it didn't work, because it should 
have. Had a look at other changes applied to the compiler recently and these 
too didn't seem to have an effect. To me it looked as if it was using an old 
version of the compiler. Then it struck me and I had a look at the root pom of 
the typedefs. Here I set the version of the compiler to 0.7.0 for the release 
and didn't bump that to 0.8.0-SNAPSHOT after the release. So now with the 
0.8.0-SNAPSHOT version it seems to be working :-)


Chris


Von: Christofer Dutz 
Gesendet: Mittwoch, 28. September 2016 10:41:39
An: dev@flex.apache.org
Betreff: AW: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Could one of you guys please have a look at what's going wrong?

I could track it back to the Framework expecting some different implementation 
of Class.as

This seems to be generated in the js externs module ... I could track it back 
to being generated by the missing.js (line 120ff)


I have no clue at what's going wrong here ... would be more than great if you 
could have a look at it.


Chris


Von: Christofer Dutz 
Gesendet: Mittwoch, 28. September 2016 09:20:52
An: dev@flex.apache.org
Betreff: AW: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Currently the framework seems to have problems ... I noticed that, but I was a 
little too consumed with my duties ad TAC member to deal with it ... I better 
have a look as soon as possible.


Chris


Von: Greg Dove 
Gesendet: Mittwoch, 28. September 2016 09:06:12
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was changed to 
@expose)?

Chris, I was seeing something not working with Maven in typedefs, a patch
not being applied cleanly.
I did not see this with ant. Justin also checked and confirmed this.
Not sure if another url has changed?



On Wed, Sep 28, 2016 at 8:03 PM, Christofer Dutz 
wrote:

> Well the Maven build went back to blue ... thanks for fixing :-)
>
>
> I guess as I finished my work on the site deployment so the build works
> again. It's always worth to have a look at the official ASF Jenkins:
>
>
> https://builds.apache.org/view/E-G/view/Flex/
>
>
> Even if it builds with Maven, it does almost all of the tests and you
> should get feedback far more frequent as when using our external build
> system. And stuff that works with Ant and doesn't with Maven should be
> considered an error that needs further addressing.
>
>
> Chris
>
> 
> Von: Alex Harui 
> Gesendet: Mittwoch, 28. September 2016 02:51:23
> An: dev@flex.apache.org
> Betreff: Re: AW: [FlexJS] Problem with some test cases (@export was
> changed to @expose)?
>
> Right now, the flex_sdk Ant CI build is failing because a third-party
> download is unavailable.  Once that comes back, flex_falcon will be built
> again and hopefully it will all work.  Probably will take several hours to
> shake out so don't spend any time thinking about it until after you see
> the flex_sdk build pass again.
>
> -Alex
>
> On 9/27/16, 5:08 PM, "Greg Dove"  wrote:
>
> >Alex, can you please let me know if this is related to something I did?
> >Is there something I need to fix?
> >I added some fixes this morning and checked that the maven build was
> >working locally.
> >But I don't know what I am doing that is different to the CI build.
> >
> >
> >
> >On Wed, Sep 28, 2016 at 12:40 PM, Alex Harui  wrote:
> >
> >> The CI Ant build now fails as well.  I just saw the email on the list.
> >> The CI server keeps getting stuck on flex_sdk_test so Falcon hadn't run
> >>in
> >> a couple of days.  The CI falcon build also runs the sdk.dependent.tests
> >> and flexjs.dependent.tests targets that don't run by default.
> >>
> >> -Alex
> >>
> >> On 9/27/16, 1:58 PM, "Christofer Dutz" 
> >>wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >
> >> >Well investigating this had me worry a little ... not the problem
> >>itself,
> >> >but the Ant build seems to be reporting that all is fine and I could
> >> >confirm the method being listed as successful in the build report.
> >> >
> >> >
> >> >But even if I run the test in IntelliJ without Mav

Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import

[Harbs]

I like this idea and would propose taking it one step further:

Currently transpiled javascript has fully qualified class names for pretty much 
everything. This is difficult for closure to minimize completely. I’d really 
like to have some way to “export” class names as well as “import” to define 
some compact name for packages. Based on my playing around, this could save at 
least tens of KB of JS downloads.

On Sep 27, 2016, at 5:59 PM, Josh Tynjala  wrote:

> I would like to propose a new feature for the ActionScript language in the
> Apache Flex "Falcon" compiler. It would be nice if developers could
> (optionally) rename an import.
> 
> Background
> ==
> 
> Normally when you import a class, you can reference the name of the class,
> without the package (unless there is another class with the same name):
> 
> // begin example
> 
> import com.example.ImportedClass;
> 
> var example:ImportedClass;
> 
> //end example
> 
> I would like to make it possible to optionally rename the shortened
> version, like this:
> 
> // begin example
> 
> import NewName = com.example.ImportedClass;
> 
> var test:NewName;
> 
> //end example
> 
> This would make it possible to resolve ambiguities without using the
> fully-qualified class name. Consider the following situation that commonly
> comes up when developing Starling apps where the fully-qualified name is
> required for different types of events:
> 
> // begin example
> 
> import flash.events.Event;
> import starling.events.Event;
> 
> var one:flash.events.Event;
> var two:starling.events.Event;
> 
> // end example
> 
> If we could rename imports, our code wouldn't require cumbersome
> fully-qualified names.
> 
> Consider the following example, references to FlashEvent will resolve to
> flash.events.Event and StarlingEvent will resolve to starling.events.Event:
> 
> // begin example
> 
> import FlashEvent = flash.events.Event;
> import StarlingEvent = starling.events.Event;
> 
> var one:FlashEvent;
> var two:StarlingEvent;
> 
> // end example
> 
> In the next example, references to FlashEvent will resolve to
> flash.events.Event, similar to the previous example. References to Event
> can resolve to starling.events.Event without ambiguity because
> flash.events.Event has been given a different name.
> 
> // begin example
> 
> import FlashEvent = flash.events.Event;
> import starling.events.Event;
> 
> var one:FlashEvent;
> var two:Event;
> 
> // end example
> 
> This would also be useful for transpile-to-JS workflow where the top-level
> package is littered with a ton of HTML classes that may conflict with names
> user-defined classes. For instance, there's a top-level Event class. There
> is no way to specify a different fully-qualified name for things in the
> top-level package, so it's hard to resolve ambiguity when using these
> classes. We have a bit of a workaround in Falcon by supporting a fake
> "window." package, but that's not ideal. Especially if you consider
> Node.js, which doesn't actually have a global window object.
> 
> Risks and Challenges
> ===
> 
> * Renaming imports is a completely optional feature. Anyone can continue to
> code in ActionScript without ever using renamed imports.
> * Existing code won't be broken by this new feature. Regular imports that
> don't do any renaming will continue to work the same as they always have.
> * Runtimes like Adobe Flash Player will not need to be modified to support
> renaming imports. Imports are completely resolved at compile-time.
> * A SWC compiled from code with renamed imports will work with compilers
> that don't support renaming imports. Again, a SWC contains compiled code,
> so imports were already resolved.
> * I have implemented this feature already, in a local branch of flex-falcon
> on my machine. The code already exists, and it works today.
> 
> The one tricky thing is that most IDEs probably won't play well with code
> that uses renamed imports. My NextGenAS extension for VSCode should have no
> problem because it loads the Falcon compiler from the Apache FlexJS SDK for
> its code intelligence features. If Falcon supports it, so will the
> extension. Adobe Flash Builder uses ASC 2.0 in a similar way, as I
> understand it. With that in mind, Flash Builder won't understand code with
> renamed imports unless Adobe modifies ASC 2.0 to add the same feature. I
> think third-party IDEs (like IntelliJ IDEA and FDT) have their own code
> models (rather than talking to the compiler), so they'd need to make their
> own changes to support this feature too.
> 
> I would like to contact the Flash runtimes team at Adobe and ask if they'd
> be willing to implement this feature in ASC 2.0 too. It's a small change,
> but useful for developer productivity, so it should be well received by the
> community. Additionally, since it will affect the compiler and not the
> runtime, it will be significantly less risky for Adobe than other new
> language features might be. Finally, considering that

AW: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Christofer Dutz]

Would also be a great opportunity to eventually cleanup some really anoying 
quirks in the Language specification ... stuff like if you try to cast to 
Array, you get a new one containing the input as single element ...


var test:* = ["lalala", "dumdidum"];

var arr:Array = Array(test);

trace(arr);


returns something like this:

[["lalala", "dumdidum"]]


if I do

var test:* = ["lalala", "dumdidum"];

var arr:Array = test as Array;

trace(arr);


I get:

["lalala", "dumdidum"]


I think there were one or two other exceptions, that really really anoy me and 
probably others too.


Chris


Von: Josh Tynjala 
Gesendet: Mittwoch, 28. September 2016 02:50:12
An: dev@flex.apache.org
Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript 
language feature: Optionally rename an import)

I agree with your point about numerous changes. I think that's something
that I didn't fully catch when reading your message. I think it's important
to start very small. For one, to get familiar with the process, and two, to
get a baseline for what might be too drastic, based on feedback and things.

Changing a programming language is a big deal, especially for those of us
who aren't primarily language designers. Let's take baby steps, but not shy
away completely. I think focusing on specific things that cause annoyances,
or hesitation to adopt, is a good way to focus and not go too crazy. Let's
have developers come back to something familiar, but also a little improved.

- Josh

On Sep 27, 2016 5:05 PM, "Greg Dove"  wrote:

> I think I expressed clear support for that feature. Please do not read
> otherwise.
> I support it, and I agree that it is a step forward, and I also don't think
> it could have any real negative consequences in isolation so long as people
> don't try the new code in an old compiler.
>
> My comments were more to provoke thinking of the possible implications of
> making *numerous* changes to the language. It was not even intended to be
> read as a reason 'not to do' something, but just to consider implications.
>
> I too have faced the exact same Event import annoyance so, as I said I
> would welcome this change for sure. I don't have any personal issue with
> *any* of this, including the other language features mentioned. Again, I
> would welcome them for my own use. What I don't know is whether I (you, we)
> acurately represent the bulk of people who would be interested in using
> FlexJS (I was a marketer in a former career so spent a lot of time thinking
> like this, dissociating my own views about what was 'obvious' from
> decision-making, and collecting the type of feedback you described before
> decisions were even made about changing things).
>
> I have also seen a number of discussions in the other project I mentioned
> over the years where there was tension over new features ('complicated' vs.
> 'familiar') so I am really just sharing that part of what I have observed
> elsewhere.
>
> e.g. "How important is familiarity in terms of popularity"
>
> If (hypothetically) returning actionscripters will represent the bulk of
> FlexJS users, will they be daunted by something that is unfamiliar?
> If (also hypothetically) you knew this to be true, it doesn't mean you
> can't do things about it, you could plan for it and make it more welcoming
> for them with loads of examples, tutorials, and messages to make sure they
> still felt 'at home' with the language etc. Not doing the right thing might
> 'hinder' growth.
>
> The other point I think is not illogical either - the more you become
> similar to something else that has other advantages (e.g. maturity), the
> more your points of difference need to be strong (both in terms of their
> actual implementation and in terms of how you manage their perception, the
> latter not always being front-of-mind for developers).
>
> I left marketing because I much prefer the direct cause and effect
> relationship associated with programming. But that doesn't stop me
> sometimes from thinking in my old ways. However I shall switch off those
> neurons now.
>
> The answer to all this (adding the extra features like generics and enums)
> might simply be "we can't get distracted by all that other stuff, let's do
> what works well for us". If this still results in a viable and vibrant
> future for FlexJS, then I am sold.
>
>
>
> On Wed, Sep 28, 2016 at 11:30 AM, Josh Tynjala 
> wrote:
>
> > I want to add a small feature that is meant to help developers with a
> real
> > annoyance that I have seen repeated complaints about over the years. It's
> > something I've run into myself, as you could see from the Starling
> examples
> > I included in my original post. I'm baffled that anyone would say that an
> > optional new feature with this kind of targeted impact could possibly
> > hinder the cause.
> >
> > ActionScript remaining completely stagnant for years is frequently stated
> > as a reason why people choose to stop using it. I

Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import

[OK]

If I understand you right you speak about "Single name aliases" [1].
This feature would be very helpful!
Seems to me that tt was dropped from AS3 for whatever reason.

Maybe this is helpful [2][3].

Thanks,
Olaf

[1]
http://apache-flex-users.246.n4.nabble.com/AS3-Alias-name-for-imports-td13245.html
[2]
http://help.adobe.com/livedocs/specs/actionscript/3/wwhelp/wwhimpl/js/html/wwhelp.htm?href=as3_specification106.html
[3]
http://www.sephiroth.it/weblog/archives/2007/03/actionscript_4_import_alias_where_is.php





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Falcon-Proposal-for-new-ActionScript-language-feature-Optionally-rename-an-import-tp55355p55400.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Josh Tynjala]

For core classes like Number, Array, Boolean, etc. what looks like a cast
is actually a function call. There's a global function named Array, and
calling that takes precedence over casting.

Personally, I think we should avoid breaking changes like this.

- Josh

On Wed, Sep 28, 2016 at 4:58 AM, Christofer Dutz 
wrote:

> Would also be a great opportunity to eventually cleanup some really
> anoying quirks in the Language specification ... stuff like if you try to
> cast to Array, you get a new one containing the input as single element ...
>
>
> var test:* = ["lalala", "dumdidum"];
>
> var arr:Array = Array(test);
>
> trace(arr);
>
>
> returns something like this:
>
> [["lalala", "dumdidum"]]
>
>
> if I do
>
> var test:* = ["lalala", "dumdidum"];
>
> var arr:Array = test as Array;
>
> trace(arr);
>
>
> I get:
>
> ["lalala", "dumdidum"]
>
>
> I think there were one or two other exceptions, that really really anoy me
> and probably others too.
>
>
> Chris
>
> 
> Von: Josh Tynjala 
> Gesendet: Mittwoch, 28. September 2016 02:50:12
> An: dev@flex.apache.org
> Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript
> language feature: Optionally rename an import)
>
> I agree with your point about numerous changes. I think that's something
> that I didn't fully catch when reading your message. I think it's important
> to start very small. For one, to get familiar with the process, and two, to
> get a baseline for what might be too drastic, based on feedback and things.
>
> Changing a programming language is a big deal, especially for those of us
> who aren't primarily language designers. Let's take baby steps, but not shy
> away completely. I think focusing on specific things that cause annoyances,
> or hesitation to adopt, is a good way to focus and not go too crazy. Let's
> have developers come back to something familiar, but also a little
> improved.
>
> - Josh
>
> On Sep 27, 2016 5:05 PM, "Greg Dove"  wrote:
>
> > I think I expressed clear support for that feature. Please do not read
> > otherwise.
> > I support it, and I agree that it is a step forward, and I also don't
> think
> > it could have any real negative consequences in isolation so long as
> people
> > don't try the new code in an old compiler.
> >
> > My comments were more to provoke thinking of the possible implications of
> > making *numerous* changes to the language. It was not even intended to be
> > read as a reason 'not to do' something, but just to consider
> implications.
> >
> > I too have faced the exact same Event import annoyance so, as I said I
> > would welcome this change for sure. I don't have any personal issue with
> > *any* of this, including the other language features mentioned. Again, I
> > would welcome them for my own use. What I don't know is whether I (you,
> we)
> > acurately represent the bulk of people who would be interested in using
> > FlexJS (I was a marketer in a former career so spent a lot of time
> thinking
> > like this, dissociating my own views about what was 'obvious' from
> > decision-making, and collecting the type of feedback you described before
> > decisions were even made about changing things).
> >
> > I have also seen a number of discussions in the other project I mentioned
> > over the years where there was tension over new features ('complicated'
> vs.
> > 'familiar') so I am really just sharing that part of what I have observed
> > elsewhere.
> >
> > e.g. "How important is familiarity in terms of popularity"
> >
> > If (hypothetically) returning actionscripters will represent the bulk of
> > FlexJS users, will they be daunted by something that is unfamiliar?
> > If (also hypothetically) you knew this to be true, it doesn't mean you
> > can't do things about it, you could plan for it and make it more
> welcoming
> > for them with loads of examples, tutorials, and messages to make sure
> they
> > still felt 'at home' with the language etc. Not doing the right thing
> might
> > 'hinder' growth.
> >
> > The other point I think is not illogical either - the more you become
> > similar to something else that has other advantages (e.g. maturity), the
> > more your points of difference need to be strong (both in terms of their
> > actual implementation and in terms of how you manage their perception,
> the
> > latter not always being front-of-mind for developers).
> >
> > I left marketing because I much prefer the direct cause and effect
> > relationship associated with programming. But that doesn't stop me
> > sometimes from thinking in my old ways. However I shall switch off those
> > neurons now.
> >
> > The answer to all this (adding the extra features like generics and
> enums)
> > might simply be "we can't get distracted by all that other stuff, let's
> do
> > what works well for us". If this still results in a viable and vibrant
> > future for FlexJS, then I am sold.
> >
> >
> >
> > On Wed, Sep 28, 2016 at 11:30 AM, Josh Tynjala 
> > wrote:
> >
>

Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import

[Josh Tynjala]

Interesting! Thanks for sharing, Olaf. As I understand it, Adobe tried to
be very conservative about what they put into AS3 because they wanted to
avoid adding things that didn't end up in the final approved version of
ES4. I think I heard that there were already some differences, and they
didn't want it to go any further, if they could help it. I guess they
decided to be careful about this one.

This is a cool discovery, like a little time capsule. It makes me happy
that my assignment syntax is the same. I considered using "as" instead, but
assignment felt better.

- Josh


On Wed, Sep 28, 2016 at 7:22 AM, OK  wrote:

> If I understand you right you speak about "Single name aliases" [1].
> This feature would be very helpful!
> Seems to me that tt was dropped from AS3 for whatever reason.
>
> Maybe this is helpful [2][3].
>
> Thanks,
> Olaf
>
> [1]
> http://apache-flex-users.246.n4.nabble.com/AS3-Alias-name-for-imports-
> td13245.html
> [2]
> http://help.adobe.com/livedocs/specs/actionscript/3/
> wwhelp/wwhimpl/js/html/wwhelp.htm?href=as3_specification106.html
> [3]
> http://www.sephiroth.it/weblog/archives/2007/03/
> actionscript_4_import_alias_where_is.php
>
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/Falcon-Proposal-for-new-
> ActionScript-language-feature-Optionally-rename-an-import-
> tp55355p55400.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] Circular dependency detected

[Alex Harui]

On 9/28/16, 2:12 AM, "OK"  wrote:

>Hi,
>while porting the "PureMVC EmployeeAdmin" demo to FlexJS I stumbled over
>the
>"Circular dependency detected" issue several times.
>I noticed that this was discussed here in the past but I can't find any
>helpful informations.
>So what I'd like to know if this is a bug with FlexJS (The swf version
>works) or if I have to workaround this by re-organizing my code or if
>there's any other chance to solve this issue.

https://cwiki.apache.org/confluence/display/FLEX/Circular+Dependencies

HTH,
-Alex

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Alex Harui]

The Ant build doesn't build the examples.  Maybe it should.  The
ChartExample fails for me from Ant as well.  I will look into it.

-Alex

On 9/28/16, 2:30 AM, "Christofer Dutz"  wrote:

>Ok now the modules that were failing compile successfully. Unfortunately
>now a little more down the stream the examples seem to be failing. I am
>getting errors in the chart example (just the first example to be
>compiled) It seems the JS compilation is failing because it cant find
>generated classes.
>
>
>https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20Framework%20(mav
>en)/269/console
>
>
>Did anything change in this part recently?

Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui]

On 9/28/16, 3:25 AM, "Harbs"  wrote:

>I like this idea and would propose taking it one step further:
>
>Currently transpiled javascript has fully qualified class names for
>pretty much everything. This is difficult for closure to minimize
>completely. I’d really like to have some way to “export” class names as
>well as “import” to define some compact name for packages. Based on my
>playing around, this could save at least tens of KB of JS downloads.

For sure, the amount of download for strings is a significant waste of
bytes in most cases.  However, I'm not sure we need to provide renaming
controls for folks building FlexJS apps, at least not for the mainstream.

AIUI, every public property and method in FlexJS is "exported" to prevent
renaming for a few "just-in-case" reasons.  First, a review of renaming:

FlexJS uses the Google Closure Compiler to optimize/minify the output JS
file.  In doing so, GCC tries to renaming variables.  For example, every
FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might rename
that property to just "a", so the original JS might look like:

UIBase.prototype.FLEXJS_CLASS_INFO = {..};

But GCC will cause that to look like:

UIBase.prototype.a = {..};

If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you can
save quite a bit of download size.  But then, what happens if someone
writes code that looks like:

var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];

For the first line, GCC will know to alter the code to look like:

var foo:Object = someUIBase.a;

And everything will work fine, but AIUI, GCC does not try to alter strings
so it will not touch the "bar" code and that would fail at runtime since
there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.


But I think that GCC is now smart enough that if you actually have a line
like the "bar" line, that will prevent GCC from renaming
FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that the
output must have the bytes for "FLEXJS_CLASS_INFO" once in order to honor
the string literal, so it will create an alias like aa =
"FLEXJS_CLASS_INFO" and then the code is output as:

UIBase.prototype[aa] = {..};
And
var foo:Object = someUIBase[aa];
var bar:Object = someUIBase[aa];

IOW, GCC has a pretty good alias generator, which is why I don't think our
tool chain needs to provide folks with the manual options to rename.  We
should just let GCC do its thing.


So, AIUI, the reason we export every public thing isn't for the standard
dynamic access case as shown above, but for two others (and related
scenarios):
-Dynamic access using generated strings
-Binding expressions with "dot-paths"

Dynamic access using generated strings are scenarios where you know that
every property starts with "str_" and run code like:

   var foo:String = bar["str_" + i];

GCC isn't smart enough to handle this.

Dot-path Binding Expressions are where you want to use data binding to
bind to "myModel.subObject.someProperty".  GCC will just look at the
entire string and since it doesn't match any property it will rename
myModel and subObject and someProperty and the binding will fail at
runtime.

So, AIUI, we have huge string tables in our apps for these two cases even
though 99% or even 100% of the time, your app isn't going to access those
methods and properties in a way that GCC can't detect.  So, before we add
some user-controlled renaming, I think we should first explore a compiler
option like -no-rename where you guarantee that your app doesn't use
generated strings or dot-path binding expressions and we clear all the
@exports out of the code before sending it to GCC.

I'll bet somewhere in the framework we do use generated strings and will
have to fix that up, but I think that should be doable.  I think the
compiler could also output string literals with "." in them as separate
strings and that might solve the dot-path problem.  IOW, instead of simply
outputting "myModel.subObject.someProperty", the compiler would output:

  "myModel" + "." + "subObject" + "." + "someProperty"

I've also seen information that indicates we might be able to control or
provide hints to GCC about what it can rename such that a smarter FalconJX
could look for dynamic access and tell GCC not to rename properties in
classes it knows will be dynamically accesses and let GCC rename
everything else.

Volunteers are welcome to do more research on leveraging and controlling
GCC renaming.  I haven't made it a high priority for me.

My 2 cents,
-Alex

Re: [FlexJS] Maven generated site online

[Carlos Rovira]

Hi Chris,

I checking the generated site, and can't see nothing related to asjs. Could
I expect to see the flexjs components API there?

btw,  in other thread I ask you for a simple pom. I can't make it work for
a simple project and would need one simple example to start. One not living
in examples, and that output on target (like you suggest), hope you could
share one.

thanks



2016-09-27 18:01 GMT+02:00 Carlos Rovira :

> Hi Chris, this is pretty amazing! a looks so good! :))
>
> Congrats to get it up and running! :)
>
> 2016-09-27 17:04 GMT+02:00 Christofer Dutz :
>
>> Hi guys,
>>
>>
>> today I finally managed to get the site generation and deployment working
>> for the ASF infrastructure. The content produced now contains quite a lot
>> of stuff and we could extend it to produce even more. Currently the most
>> important parts are:
>>
>> - documentation
>>
>> - JavaDoc
>>
>> - Test-Coverage reports
>>
>>
>> Ok ... I ran it without tests on my machine ... will re-run things on the
>> ASF build agents as soon as they have one final thing resolved. Then we
>> could be updating the content on that page on a daily basis automatically.
>>
>>
>> Please feel free to have a look: http://flex.apache.org/maven/f
>> lexjs/latest-dev/
>>
>>
>> Particularly interesting should be these pages here:
>>
>> http://flex.apache.org/maven/flexjs/latest-dev/build.html
>>
>> http://flex.apache.org/maven/flexjs/latest-dev/structure.html
>>
>> Which are generated from the content in the flex-falcon/src/site/asciidoc
>> directory using asciidoctor.
>>
>>
>> Chris
>>
>
>
>
> --
>
> 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.
>
>


-- 

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: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui]

On 9/28/16, 8:37 AM, "Josh Tynjala"  wrote:

>For core classes like Number, Array, Boolean, etc. what looks like a cast
>is actually a function call. There's a global function named Array, and
>calling that takes precedence over casting.
>
>Personally, I think we should avoid breaking changes like this.

Me too, especially since, on the SWF side, the runtime is handling this.
As annoying as it is, we have to maintain backward compatibility.

-Alex

Re: [2/4] git commit: [flex-sdk] [refs/heads/develop] - FLEX-35126 Added a unit test to reprouce the bug. Currently it passes, as expected. (But if I manually put back the fix for FLEX-34088, it fails

[Alex Harui]

Mihai,

The http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/ job keeps
hanging on this new test.  I have disabled the job.  Please investigate
and re-enable the job when things are working again.

Thanks,
-Alex

On 9/19/16, 4:36 AM, "mih...@apache.org"  wrote:

>FLEX-35126 Added a unit test to reprouce the bug. Currently it passes, as
>expected. (But if I manually put back the fix for FLEX-34088, it fails,
>as it should, meaning it actually tests the correct bug.)
>
>
>Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
>Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/3d71f1b5
>Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/3d71f1b5
>Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/3d71f1b5
>
>Branch: refs/heads/develop
>Commit: 3d71f1b5e458ee39f439ef68db092ed08a8935df
>Parents: a797884
>Author: Mihai Chira 
>Authored: Mon Sep 19 13:24:17 2016 +0200
>Committer: Mihai Chira 
>Committed: Mon Sep 19 13:24:17 2016 +0200
>
>--
> .../components/DropDownList_FLEX_35126_Tests.as | 182 +++
> 1 file changed, 182 insertions(+)
>--
>
>
>http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/3d71f1b5/frameworks/p
>rojects/spark/tests/spark/components/DropDownList_FLEX_35126_Tests.as
>--
>diff --git 
>a/frameworks/projects/spark/tests/spark/components/DropDownList_FLEX_35126
>_Tests.as 
>b/frameworks/projects/spark/tests/spark/components/DropDownList_FLEX_35126
>_Tests.as
>new file mode 100644
>index 000..82ab10e
>--- /dev/null
>+++ 
>b/frameworks/projects/spark/tests/spark/components/DropDownList_FLEX_35126
>_Tests.as
>@@ -0,0 +1,182 @@
>+/
>///
>+//
>+//  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 spark.components {
>+import flash.events.Event;
>+import flash.events.EventDispatcher;
>+import flash.events.MouseEvent;
>+
>+import mx.events.FlexMouseEvent;
>+
>+import org.flexunit.assertThat;
>+import org.flexunit.asserts.assertEquals;
>+import org.flexunit.asserts.assertFalse;
>+import org.flexunit.asserts.assertTrue;
>+import org.flexunit.async.Async;
>+import org.fluint.uiImpersonation.UIImpersonator;
>+
>+public class DropDownList_FLEX_35126_Tests
>+{
>+private static const NO_ENTER_FRAMES_TO_ALLOW:int = 2;
>+private static var noEnterFramesRemaining:int = NaN;
>+private static const _finishNotifier:EventDispatcher = new
>EventDispatcher();
>+
>+private static var _sut:DropDownListInspectable;
>+private static var _dropDownListOnStage:DropDownList;
>+private var _popUp:PopUpAnchor;
>+
>+[Before]
>+public function setUp():void
>+{
>+_popUp = new PopUpAnchor();
>+_popUp.displayPopUp = true;
>+
>+_sut = new DropDownListInspectable();
>+_sut.addEventListener(FlexMouseEvent.MOUSE_DOWN_OUTSIDE,
>onMouseDownOutsidePopup);
>+
>+_popUp.popUp = _sut;
>+
>+_dropDownListOnStage = new DropDownList();
>+}
>+
>+private function
>onMouseDownOutsidePopup(event:FlexMouseEvent):void
>+{
>+_popUp.displayPopUp = false;
>+}
>+
>+[After]
>+public function tearDown():void
>+{
>+_sut = null;
>+_popUp = null;
>+_dropDownListOnStage = null;
>+}
>+
>+[Test(async, timeout=1000)]
>+public function
>test_dropdown_doesnt_close_when_item_selected_from_DropDownList():void
>+{
>+//given
>+_popUp.width = _sut.width = 150;
>+_dropDownListOnStage.x = 200;
>+UIImpersonator.addChild(_popUp);
>+UIImpersonator.addChild(_dropDownListOnStage);
>+
>+//then
>+assertTrue(_popUp.displayPopUp);
>+
>assertThat(isNaN(_sut.dropDo

AW: [FlexJS] Maven generated site online

[Christofer Dutz]

Hi Carlos,


the Flex/Actionscript part is currently missing from that because we don't have 
ASDoc working properly. If I extended the maven plugin to run asdoc for the 
framework part, we could start shipping that the same way the javadoc is 
shipped. That's also the reason I haven't started adding a site to the typedefs 
or the framework.


Chris


Von: carlos.rov...@gmail.com  im Auftrag von Carlos 
Rovira 
Gesendet: Mittwoch, 28. September 2016 19:25:05
An: dev@flex.apache.org
Betreff: Re: [FlexJS] Maven generated site online

Hi Chris,

I checking the generated site, and can't see nothing related to asjs. Could
I expect to see the flexjs components API there?

btw,  in other thread I ask you for a simple pom. I can't make it work for
a simple project and would need one simple example to start. One not living
in examples, and that output on target (like you suggest), hope you could
share one.

thanks



2016-09-27 18:01 GMT+02:00 Carlos Rovira :

> Hi Chris, this is pretty amazing! a looks so good! :))
>
> Congrats to get it up and running! :)
>
> 2016-09-27 17:04 GMT+02:00 Christofer Dutz :
>
>> Hi guys,
>>
>>
>> today I finally managed to get the site generation and deployment working
>> for the ASF infrastructure. The content produced now contains quite a lot
>> of stuff and we could extend it to produce even more. Currently the most
>> important parts are:
>>
>> - documentation
>>
>> - JavaDoc
>>
>> - Test-Coverage reports
>>
>>
>> Ok ... I ran it without tests on my machine ... will re-run things on the
>> ASF build agents as soon as they have one final thing resolved. Then we
>> could be updating the content on that page on a daily basis automatically.
>>
>>
>> Please feel free to have a look: http://flex.apache.org/maven/f
>> lexjs/latest-dev/
>>
>>
>> Particularly interesting should be these pages here:
>>
>> http://flex.apache.org/maven/flexjs/latest-dev/build.html
>>
>> http://flex.apache.org/maven/flexjs/latest-dev/structure.html
>>
>> Which are generated from the content in the flex-falcon/src/site/asciidoc
>> directory using asciidoctor.
>>
>>
>> Chris
>>
>
>
>
> --
>
> 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.
>
>


--

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.

AW: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Christofer Dutz]

That was initially the reasoning for me suggesting an as4 instead of extending 
as3.

An alternative would be to control this with a compiler switch ... sort of like 
the quirks mode in the browsers (does that still exist?). I'm just thinking of 
all of these "Fun with JavaScript" in which you can fill hours with 
unexpectable JavaScript results.


Chris


Von: Alex Harui 
Gesendet: Mittwoch, 28. September 2016 19:29:22
An: dev@flex.apache.org
Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript 
language feature: Optionally rename an import)



On 9/28/16, 8:37 AM, "Josh Tynjala"  wrote:

>For core classes like Number, Array, Boolean, etc. what looks like a cast
>is actually a function call. There's a global function named Array, and
>calling that takes precedence over casting.
>
>Personally, I think we should avoid breaking changes like this.

Me too, especially since, on the SWF side, the runtime is handling this.
As annoying as it is, we have to maintain backward compatibility.

-Alex

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove]

Alex, I had also considered the same idea of doing the qualifiedName
splitting in the reflection data because I think you would reduce a lot of
long string variation in the GCC release build simply by doing
'org.apache.flex.'+'Package.'+'ClassName' etc

Isn't using the reflection member definition names for access also another
use that would qualify as 'dynamic' access? I am not sure if GCC can make
the connection between the reflection data field names and the original
naming of the fields which is why we need @export on instance members and
@expose on static members (without those it fails iirc).

One option for the future might be to make Reflection support optional. I
think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
the reflection support could be opt-in (or opt-out). This alone could
reduce a lot of code for people who don't need that.




On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui  wrote:

>
>
> On 9/28/16, 3:25 AM, "Harbs"  wrote:
>
> >I like this idea and would propose taking it one step further:
> >
> >Currently transpiled javascript has fully qualified class names for
> >pretty much everything. This is difficult for closure to minimize
> >completely. I’d really like to have some way to “export” class names as
> >well as “import” to define some compact name for packages. Based on my
> >playing around, this could save at least tens of KB of JS downloads.
>
> For sure, the amount of download for strings is a significant waste of
> bytes in most cases.  However, I'm not sure we need to provide renaming
> controls for folks building FlexJS apps, at least not for the mainstream.
>
> AIUI, every public property and method in FlexJS is "exported" to prevent
> renaming for a few "just-in-case" reasons.  First, a review of renaming:
>
> FlexJS uses the Google Closure Compiler to optimize/minify the output JS
> file.  In doing so, GCC tries to renaming variables.  For example, every
> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might rename
> that property to just "a", so the original JS might look like:
>
> UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>
> But GCC will cause that to look like:
>
> UIBase.prototype.a = {..};
>
> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you can
> save quite a bit of download size.  But then, what happens if someone
> writes code that looks like:
>
> var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
> var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>
> For the first line, GCC will know to alter the code to look like:
>
> var foo:Object = someUIBase.a;
>
> And everything will work fine, but AIUI, GCC does not try to alter strings
> so it will not touch the "bar" code and that would fail at runtime since
> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>
>
> But I think that GCC is now smart enough that if you actually have a line
> like the "bar" line, that will prevent GCC from renaming
> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that the
> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to honor
> the string literal, so it will create an alias like aa =
> "FLEXJS_CLASS_INFO" and then the code is output as:
>
> UIBase.prototype[aa] = {..};
> And
> var foo:Object = someUIBase[aa];
> var bar:Object = someUIBase[aa];
>
> IOW, GCC has a pretty good alias generator, which is why I don't think our
> tool chain needs to provide folks with the manual options to rename.  We
> should just let GCC do its thing.
>
>
> So, AIUI, the reason we export every public thing isn't for the standard
> dynamic access case as shown above, but for two others (and related
> scenarios):
> -Dynamic access using generated strings
> -Binding expressions with "dot-paths"
>
> Dynamic access using generated strings are scenarios where you know that
> every property starts with "str_" and run code like:
>
>var foo:String = bar["str_" + i];
>
> GCC isn't smart enough to handle this.
>
> Dot-path Binding Expressions are where you want to use data binding to
> bind to "myModel.subObject.someProperty".  GCC will just look at the
> entire string and since it doesn't match any property it will rename
> myModel and subObject and someProperty and the binding will fail at
> runtime.
>
> So, AIUI, we have huge string tables in our apps for these two cases even
> though 99% or even 100% of the time, your app isn't going to access those
> methods and properties in a way that GCC can't detect.  So, before we add
> some user-controlled renaming, I think we should first explore a compiler
> option like -no-rename where you guarantee that your app doesn't use
> generated strings or dot-path binding expressions and we clear all the
> @exports out of the code before sending it to GCC.
>
> I'll bet somewhere in the framework we do use generated strings and will
> have to fix that up, but I think that should be doable.  I think the
> compiler could also output string lite

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove]

 "reflection support could be opt-in (or opt-out)"

On reflection (pun unintended) maybe that is not sensible, given it is
baked in to the framework classes. If GCC does dead-code elimination, maybe
that does the job anyhow.



On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove  wrote:

> Alex, I had also considered the same idea of doing the qualifiedName
> splitting in the reflection data because I think you would reduce a lot of
> long string variation in the GCC release build simply by doing
> 'org.apache.flex.'+'Package.'+'ClassName' etc
>
> Isn't using the reflection member definition names for access also another
> use that would qualify as 'dynamic' access? I am not sure if GCC can make
> the connection between the reflection data field names and the original
> naming of the fields which is why we need @export on instance members and
> @expose on static members (without those it fails iirc).
>
> One option for the future might be to make Reflection support optional. I
> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
> the reflection support could be opt-in (or opt-out). This alone could
> reduce a lot of code for people who don't need that.
>
>
>
>
> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui  wrote:
>
>>
>>
>> On 9/28/16, 3:25 AM, "Harbs"  wrote:
>>
>> >I like this idea and would propose taking it one step further:
>> >
>> >Currently transpiled javascript has fully qualified class names for
>> >pretty much everything. This is difficult for closure to minimize
>> >completely. I’d really like to have some way to “export” class names as
>> >well as “import” to define some compact name for packages. Based on my
>> >playing around, this could save at least tens of KB of JS downloads.
>>
>> For sure, the amount of download for strings is a significant waste of
>> bytes in most cases.  However, I'm not sure we need to provide renaming
>> controls for folks building FlexJS apps, at least not for the mainstream.
>>
>> AIUI, every public property and method in FlexJS is "exported" to prevent
>> renaming for a few "just-in-case" reasons.  First, a review of renaming:
>>
>> FlexJS uses the Google Closure Compiler to optimize/minify the output JS
>> file.  In doing so, GCC tries to renaming variables.  For example, every
>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might rename
>> that property to just "a", so the original JS might look like:
>>
>> UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>>
>> But GCC will cause that to look like:
>>
>> UIBase.prototype.a = {..};
>>
>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you can
>> save quite a bit of download size.  But then, what happens if someone
>> writes code that looks like:
>>
>> var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>> var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>>
>> For the first line, GCC will know to alter the code to look like:
>>
>> var foo:Object = someUIBase.a;
>>
>> And everything will work fine, but AIUI, GCC does not try to alter strings
>> so it will not touch the "bar" code and that would fail at runtime since
>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>>
>>
>> But I think that GCC is now smart enough that if you actually have a line
>> like the "bar" line, that will prevent GCC from renaming
>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that the
>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to honor
>> the string literal, so it will create an alias like aa =
>> "FLEXJS_CLASS_INFO" and then the code is output as:
>>
>> UIBase.prototype[aa] = {..};
>> And
>> var foo:Object = someUIBase[aa];
>> var bar:Object = someUIBase[aa];
>>
>> IOW, GCC has a pretty good alias generator, which is why I don't think our
>> tool chain needs to provide folks with the manual options to rename.  We
>> should just let GCC do its thing.
>>
>>
>> So, AIUI, the reason we export every public thing isn't for the standard
>> dynamic access case as shown above, but for two others (and related
>> scenarios):
>> -Dynamic access using generated strings
>> -Binding expressions with "dot-paths"
>>
>> Dynamic access using generated strings are scenarios where you know that
>> every property starts with "str_" and run code like:
>>
>>var foo:String = bar["str_" + i];
>>
>> GCC isn't smart enough to handle this.
>>
>> Dot-path Binding Expressions are where you want to use data binding to
>> bind to "myModel.subObject.someProperty".  GCC will just look at the
>> entire string and since it doesn't match any property it will rename
>> myModel and subObject and someProperty and the binding will fail at
>> runtime.
>>
>> So, AIUI, we have huge string tables in our apps for these two cases even
>> though 99% or even 100% of the time, your app isn't going to access those
>> methods and properties in a way that GCC can't detect.  So, before we add
>> some user-controlled renaming, I think we should first exp

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui]

In fact, when I last touched it, Reflection was optional.  Unless you
actually use a reflection API (whose code path access
FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
minified results.  Probably worth verifying that is still true.

What I don't know is whether dead code is removed before renaming.  I hope
so (and it makes sense to do it that way), otherwise the strings in
FLEXJS_REFLECTION_INFO may prevent renaming.

All that is part of Pay-as-you-go.  A related goal is to make the "opt-in"
automatic.  IOW, we don't want folks to have to set compiler options to
get features. They should come in as you use the APIs.

-Alex

On 9/28/16, 11:05 AM, "Greg Dove"  wrote:

> "reflection support could be opt-in (or opt-out)"
>
>On reflection (pun unintended) maybe that is not sensible, given it is
>baked in to the framework classes. If GCC does dead-code elimination,
>maybe
>that does the job anyhow.
>
>
>
>On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove  wrote:
>
>> Alex, I had also considered the same idea of doing the qualifiedName
>> splitting in the reflection data because I think you would reduce a lot
>>of
>> long string variation in the GCC release build simply by doing
>> 'org.apache.flex.'+'Package.'+'ClassName' etc
>>
>> Isn't using the reflection member definition names for access also
>>another
>> use that would qualify as 'dynamic' access? I am not sure if GCC can
>>make
>> the connection between the reflection data field names and the original
>> naming of the fields which is why we need @export on instance members
>>and
>> @expose on static members (without those it fails iirc).
>>
>> One option for the future might be to make Reflection support optional.
>>I
>> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
>> the reflection support could be opt-in (or opt-out). This alone could
>> reduce a lot of code for people who don't need that.
>>
>>
>>
>>
>> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui  wrote:
>>
>>>
>>>
>>> On 9/28/16, 3:25 AM, "Harbs"  wrote:
>>>
>>> >I like this idea and would propose taking it one step further:
>>> >
>>> >Currently transpiled javascript has fully qualified class names for
>>> >pretty much everything. This is difficult for closure to minimize
>>> >completely. I’d really like to have some way to “export” class names
>>>as
>>> >well as “import” to define some compact name for packages. Based on my
>>> >playing around, this could save at least tens of KB of JS downloads.
>>>
>>> For sure, the amount of download for strings is a significant waste of
>>> bytes in most cases.  However, I'm not sure we need to provide renaming
>>> controls for folks building FlexJS apps, at least not for the
>>>mainstream.
>>>
>>> AIUI, every public property and method in FlexJS is "exported" to
>>>prevent
>>> renaming for a few "just-in-case" reasons.  First, a review of
>>>renaming:
>>>
>>> FlexJS uses the Google Closure Compiler to optimize/minify the output
>>>JS
>>> file.  In doing so, GCC tries to renaming variables.  For example,
>>>every
>>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might
>>>rename
>>> that property to just "a", so the original JS might look like:
>>>
>>> UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>>>
>>> But GCC will cause that to look like:
>>>
>>> UIBase.prototype.a = {..};
>>>
>>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you
>>>can
>>> save quite a bit of download size.  But then, what happens if someone
>>> writes code that looks like:
>>>
>>> var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>>> var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>>>
>>> For the first line, GCC will know to alter the code to look like:
>>>
>>> var foo:Object = someUIBase.a;
>>>
>>> And everything will work fine, but AIUI, GCC does not try to alter
>>>strings
>>> so it will not touch the "bar" code and that would fail at runtime
>>>since
>>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>>>
>>>
>>> But I think that GCC is now smart enough that if you actually have a
>>>line
>>> like the "bar" line, that will prevent GCC from renaming
>>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that
>>>the
>>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to
>>>honor
>>> the string literal, so it will create an alias like aa =
>>> "FLEXJS_CLASS_INFO" and then the code is output as:
>>>
>>> UIBase.prototype[aa] = {..};
>>> And
>>> var foo:Object = someUIBase[aa];
>>> var bar:Object = someUIBase[aa];
>>>
>>> IOW, GCC has a pretty good alias generator, which is why I don't think
>>>our
>>> tool chain needs to provide folks with the manual options to rename.
>>>We
>>> should just let GCC do its thing.
>>>
>>>
>>> So, AIUI, the reason we export every public thing isn't for the
>>>standard
>>> dynamic access case as shown above, but for two others (and related
>>> scenarios):
>>> -Dynamic access using generated strings
>>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove]

I hadn't investigated any of this, just wondered about it I will check the
reflection results today.
I had actually assumed that @export and @expose explicitly prevented
renaming, but also had not checked this.



On Thu, Sep 29, 2016 at 7:13 AM, Alex Harui  wrote:

> In fact, when I last touched it, Reflection was optional.  Unless you
> actually use a reflection API (whose code path access
> FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
> minified results.  Probably worth verifying that is still true.
>
> What I don't know is whether dead code is removed before renaming.  I hope
> so (and it makes sense to do it that way), otherwise the strings in
> FLEXJS_REFLECTION_INFO may prevent renaming.
>
> All that is part of Pay-as-you-go.  A related goal is to make the "opt-in"
> automatic.  IOW, we don't want folks to have to set compiler options to
> get features. They should come in as you use the APIs.
>
> -Alex
>
> On 9/28/16, 11:05 AM, "Greg Dove"  wrote:
>
> > "reflection support could be opt-in (or opt-out)"
> >
> >On reflection (pun unintended) maybe that is not sensible, given it is
> >baked in to the framework classes. If GCC does dead-code elimination,
> >maybe
> >that does the job anyhow.
> >
> >
> >
> >On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove  wrote:
> >
> >> Alex, I had also considered the same idea of doing the qualifiedName
> >> splitting in the reflection data because I think you would reduce a lot
> >>of
> >> long string variation in the GCC release build simply by doing
> >> 'org.apache.flex.'+'Package.'+'ClassName' etc
> >>
> >> Isn't using the reflection member definition names for access also
> >>another
> >> use that would qualify as 'dynamic' access? I am not sure if GCC can
> >>make
> >> the connection between the reflection data field names and the original
> >> naming of the fields which is why we need @export on instance members
> >>and
> >> @expose on static members (without those it fails iirc).
> >>
> >> One option for the future might be to make Reflection support optional.
> >>I
> >> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
> >> the reflection support could be opt-in (or opt-out). This alone could
> >> reduce a lot of code for people who don't need that.
> >>
> >>
> >>
> >>
> >> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui  wrote:
> >>
> >>>
> >>>
> >>> On 9/28/16, 3:25 AM, "Harbs"  wrote:
> >>>
> >>> >I like this idea and would propose taking it one step further:
> >>> >
> >>> >Currently transpiled javascript has fully qualified class names for
> >>> >pretty much everything. This is difficult for closure to minimize
> >>> >completely. I’d really like to have some way to “export” class names
> >>>as
> >>> >well as “import” to define some compact name for packages. Based on my
> >>> >playing around, this could save at least tens of KB of JS downloads.
> >>>
> >>> For sure, the amount of download for strings is a significant waste of
> >>> bytes in most cases.  However, I'm not sure we need to provide renaming
> >>> controls for folks building FlexJS apps, at least not for the
> >>>mainstream.
> >>>
> >>> AIUI, every public property and method in FlexJS is "exported" to
> >>>prevent
> >>> renaming for a few "just-in-case" reasons.  First, a review of
> >>>renaming:
> >>>
> >>> FlexJS uses the Google Closure Compiler to optimize/minify the output
> >>>JS
> >>> file.  In doing so, GCC tries to renaming variables.  For example,
> >>>every
> >>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might
> >>>rename
> >>> that property to just "a", so the original JS might look like:
> >>>
> >>> UIBase.prototype.FLEXJS_CLASS_INFO = {..};
> >>>
> >>> But GCC will cause that to look like:
> >>>
> >>> UIBase.prototype.a = {..};
> >>>
> >>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you
> >>>can
> >>> save quite a bit of download size.  But then, what happens if someone
> >>> writes code that looks like:
> >>>
> >>> var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
> >>> var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
> >>>
> >>> For the first line, GCC will know to alter the code to look like:
> >>>
> >>> var foo:Object = someUIBase.a;
> >>>
> >>> And everything will work fine, but AIUI, GCC does not try to alter
> >>>strings
> >>> so it will not touch the "bar" code and that would fail at runtime
> >>>since
> >>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
> >>>
> >>>
> >>> But I think that GCC is now smart enough that if you actually have a
> >>>line
> >>> like the "bar" line, that will prevent GCC from renaming
> >>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that
> >>>the
> >>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to
> >>>honor
> >>> the string literal, so it will create an alias like aa =
> >>> "FLEXJS_CLASS_INFO" and then the code is output as:
> >>>
> >>> UIBase.prototype[aa] = {..};
> >>> And
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove]

OT: I am getting a lot of warnings in the GCC release build phase. I recall
you mentioning something in the past about this being related to GCC
versions - is there anything I can do to address this?



On Thu, Sep 29, 2016 at 7:19 AM, Greg Dove  wrote:

> I hadn't investigated any of this, just wondered about it I will check the
> reflection results today.
> I had actually assumed that @export and @expose explicitly prevented
> renaming, but also had not checked this.
>
>
>
>
> On Thu, Sep 29, 2016 at 7:13 AM, Alex Harui  wrote:
>
>> In fact, when I last touched it, Reflection was optional.  Unless you
>> actually use a reflection API (whose code path access
>> FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
>> minified results.  Probably worth verifying that is still true.
>>
>> What I don't know is whether dead code is removed before renaming.  I hope
>> so (and it makes sense to do it that way), otherwise the strings in
>> FLEXJS_REFLECTION_INFO may prevent renaming.
>>
>> All that is part of Pay-as-you-go.  A related goal is to make the "opt-in"
>> automatic.  IOW, we don't want folks to have to set compiler options to
>> get features. They should come in as you use the APIs.
>>
>> -Alex
>>
>> On 9/28/16, 11:05 AM, "Greg Dove"  wrote:
>>
>> > "reflection support could be opt-in (or opt-out)"
>> >
>> >On reflection (pun unintended) maybe that is not sensible, given it is
>> >baked in to the framework classes. If GCC does dead-code elimination,
>> >maybe
>> >that does the job anyhow.
>> >
>> >
>> >
>> >On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove  wrote:
>> >
>> >> Alex, I had also considered the same idea of doing the qualifiedName
>> >> splitting in the reflection data because I think you would reduce a lot
>> >>of
>> >> long string variation in the GCC release build simply by doing
>> >> 'org.apache.flex.'+'Package.'+'ClassName' etc
>> >>
>> >> Isn't using the reflection member definition names for access also
>> >>another
>> >> use that would qualify as 'dynamic' access? I am not sure if GCC can
>> >>make
>> >> the connection between the reflection data field names and the original
>> >> naming of the fields which is why we need @export on instance members
>> >>and
>> >> @expose on static members (without those it fails iirc).
>> >>
>> >> One option for the future might be to make Reflection support optional.
>> >>I
>> >> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of
>> the
>> >> the reflection support could be opt-in (or opt-out). This alone could
>> >> reduce a lot of code for people who don't need that.
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui  wrote:
>> >>
>> >>>
>> >>>
>> >>> On 9/28/16, 3:25 AM, "Harbs"  wrote:
>> >>>
>> >>> >I like this idea and would propose taking it one step further:
>> >>> >
>> >>> >Currently transpiled javascript has fully qualified class names for
>> >>> >pretty much everything. This is difficult for closure to minimize
>> >>> >completely. I’d really like to have some way to “export” class names
>> >>>as
>> >>> >well as “import” to define some compact name for packages. Based on
>> my
>> >>> >playing around, this could save at least tens of KB of JS downloads.
>> >>>
>> >>> For sure, the amount of download for strings is a significant waste of
>> >>> bytes in most cases.  However, I'm not sure we need to provide
>> renaming
>> >>> controls for folks building FlexJS apps, at least not for the
>> >>>mainstream.
>> >>>
>> >>> AIUI, every public property and method in FlexJS is "exported" to
>> >>>prevent
>> >>> renaming for a few "just-in-case" reasons.  First, a review of
>> >>>renaming:
>> >>>
>> >>> FlexJS uses the Google Closure Compiler to optimize/minify the output
>> >>>JS
>> >>> file.  In doing so, GCC tries to renaming variables.  For example,
>> >>>every
>> >>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might
>> >>>rename
>> >>> that property to just "a", so the original JS might look like:
>> >>>
>> >>> UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>> >>>
>> >>> But GCC will cause that to look like:
>> >>>
>> >>> UIBase.prototype.a = {..};
>> >>>
>> >>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you
>> >>>can
>> >>> save quite a bit of download size.  But then, what happens if someone
>> >>> writes code that looks like:
>> >>>
>> >>> var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>> >>> var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>> >>>
>> >>> For the first line, GCC will know to alter the code to look like:
>> >>>
>> >>> var foo:Object = someUIBase.a;
>> >>>
>> >>> And everything will work fine, but AIUI, GCC does not try to alter
>> >>>strings
>> >>> so it will not touch the "bar" code and that would fail at runtime
>> >>>since
>> >>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>> >>>
>> >>>
>> >>> But I think that GCC is now smart enough that if you actually have a
>> >>>line
>> >>> like the "

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui]

On 9/28/16, 11:19 AM, "Greg Dove"  wrote:

>I hadn't investigated any of this, just wondered about it I will check the
>reflection results today.
>I had actually assumed that @export and @expose explicitly prevented
>renaming, but also had not checked this.
>

Maybe I wasn't clear.

@export and @expose do prevent renaming.  But so does certain uses of
string literals, so some day, if we make an option that sweeps away all of
the @exports and @exposes, we want to know if the copies of the method and
property names in FLEXJS_REFLECTION_INFO would also prevent renaming.

No needed to investigate that until we get around to having a feature that
sweeps away @expose and @export, I just am hoping that
FLEXJS_REFLECTION_INFO is still seen as dead code to the Hello World app.

Thanks,
-Alex

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Alex Harui]

Looked into it.  It appears to be related to Greg's changes in
0bde1ec7a47341294280082331ce8b2c023d756f

In MXMLFlexJSEmitter, the namesToAdd is including internal classes which
it shouldn't.  Probably the subDocuments list can be used to further
filter what gets added to namesToAdd.

Also, the reflection data for internal classes is being emitted at the top
of the output file.  That should probably get changed as well.

I'm going back to other things.  I expect Greg will take care of this.
Greg, let us know if you need help or don't have time.

-Alex

On 9/28/16, 9:40 AM, "Alex Harui"  wrote:

>The Ant build doesn't build the examples.  Maybe it should.  The
>ChartExample fails for me from Ant as well.  I will look into it.
>
>-Alex
>
>On 9/28/16, 2:30 AM, "Christofer Dutz"  wrote:
>
>>Ok now the modules that were failing compile successfully. Unfortunately
>>now a little more down the stream the examples seem to be failing. I am
>>getting errors in the chart example (just the first example to be
>>compiled) It seems the JS compilation is failing because it cant find
>>generated classes.
>>
>>
>>https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20Framework%20(ma
>>v
>>en)/269/console
>>
>>
>>Did anything change in this part recently?
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove]

Thanks for clarifying. I see that you mentioned that originally now :)
I think if GCC is smart enough to follow the indirection between those
reflection field names and all possible uses of reflection it would be
quite impressive. I don't think it works as is, because if it wasn't for
some static fields that had '@export' on them which I had to change to
'@expose' to make them work, unless the original @export was preventing it
working. I might do a quick check of this sometime in the next couple of
weeks to see if I can remove some of the annotations and see whether it
works or not.

I will check the deadcode elimination for relection info in helloworld today



On Thu, Sep 29, 2016 at 7:25 AM, Alex Harui  wrote:

>
>
> On 9/28/16, 11:19 AM, "Greg Dove"  wrote:
>
> >I hadn't investigated any of this, just wondered about it I will check the
> >reflection results today.
> >I had actually assumed that @export and @expose explicitly prevented
> >renaming, but also had not checked this.
> >
>
> Maybe I wasn't clear.
>
> @export and @expose do prevent renaming.  But so does certain uses of
> string literals, so some day, if we make an option that sweeps away all of
> the @exports and @exposes, we want to know if the copies of the method and
> property names in FLEXJS_REFLECTION_INFO would also prevent renaming.
>
> No needed to investigate that until we get around to having a feature that
> sweeps away @expose and @export, I just am hoping that
> FLEXJS_REFLECTION_INFO is still seen as dead code to the Hello World app.
>
> Thanks,
> -Alex
>
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui]

On 9/28/16, 11:23 AM, "Greg Dove"  wrote:

>OT: I am getting a lot of warnings in the GCC release build phase. I
>recall
>you mentioning something in the past about this being related to GCC
>versions - is there anything I can do to address this?

Every once in a while, we have to upgrade to the latest GCC and GCL
together.

The GCC is determined by the compiler-jx/src/main/resources/downloads.xml
build script in flex-falcon.  I think we always pull the latest GCL, so
maybe just try updating GCC.  If you look at source code history you might
find other things that had to change when we upgrade.  Depending on your
setup, your copy of GCL might be stale and not refreshed by the build so
you may need to delete your GCL.

Also, I think the version of GCC is set in a pom.xml somewhere for Maven.

There is also a chance that the compiler needs to change its codeine.

HTH,
-Alex

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Greg Dove]

I will look at this now.

I had intended for relection to always be at the end, so that definitely
sounds wrong.
I did find the usedNames/postProcess sequence to be a possible candidate
for refactor at some point, but was not keen to mess with this at the
moment. I think I found that some usedNames were not being added to
goog.requires as it was originally.



On Thu, Sep 29, 2016 at 7:33 AM, Alex Harui  wrote:

> Looked into it.  It appears to be related to Greg's changes in
> 0bde1ec7a47341294280082331ce8b2c023d756f
>
> In MXMLFlexJSEmitter, the namesToAdd is including internal classes which
> it shouldn't.  Probably the subDocuments list can be used to further
> filter what gets added to namesToAdd.
>
> Also, the reflection data for internal classes is being emitted at the top
> of the output file.  That should probably get changed as well.
>
> I'm going back to other things.  I expect Greg will take care of this.
> Greg, let us know if you need help or don't have time.
>
> -Alex
>
> On 9/28/16, 9:40 AM, "Alex Harui"  wrote:
>
> >The Ant build doesn't build the examples.  Maybe it should.  The
> >ChartExample fails for me from Ant as well.  I will look into it.
> >
> >-Alex
> >
> >On 9/28/16, 2:30 AM, "Christofer Dutz"  wrote:
> >
> >>Ok now the modules that were failing compile successfully. Unfortunately
> >>now a little more down the stream the examples seem to be failing. I am
> >>getting errors in the chart example (just the first example to be
> >>compiled) It seems the JS compilation is failing because it cant find
> >>generated classes.
> >>
> >>
> >>https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%
> 20Framework%20(ma
> >>v
> >>en)/269/console
> >>
> >>
> >>Did anything change in this part recently?
> >
>
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui]

On 9/28/16, 11:36 AM, "Greg Dove"  wrote:

>Thanks for clarifying. I see that you mentioned that originally now :)
>I think if GCC is smart enough to follow the indirection between those
>reflection field names and all possible uses of reflection it would be
>quite impressive. I don't think it works as is, because if it wasn't for
>some static fields that had '@export' on them which I had to change to
>'@expose' to make them work, unless the original @export was preventing it
>working. I might do a quick check of this sometime in the next couple of
>weeks to see if I can remove some of the annotations and see whether it
>works or not.

I agree that the reflection data is unlikely to prevent renaming.  But I
think you can do static code-flow analysis and potentially find that a
data structure is being used for dynamic access.

>
>I will check the deadcode elimination for relection info in helloworld
>today
>

Please see about fixing the flex-falcon build first.  I just passed the
buck to you on that thread a few minutes ago.

Thanks,
-Alex

Re: [FlexJS][Maven] Simple pom with js output

[Carlos Rovira]

Hi Chris,

final y I get a BUILD SUCCESS :)
But there's no target and no output :(
Do you know what could be happen?

This is the pom.xml (notice that the project only has one file in src
folder called 'HelloWorld.mxml'):


http://maven.apache.org/POM/4.0.0";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0

  com.carlosrovira.flexjs.examples
  TestFlexJS
  0.1.0-SNAPSHOT
  pom

  My Own TestFlexJS

  
0.7.0
  

  
src

  

  org.apache.flex.flexjs.compiler
  flexjs-maven-plugin
  ${flexjs.compiler.version}
  true
  


  compile-javascript
  compile
  
compile-app
  
  
HelloWorld.mxml
true
  

  

  

  org.apache.flex.flexjs.compiler
  compiler-jx
  ${flexjs.compiler.version}

  

  

  



Thanks










2016-09-27 23:25 GMT+02:00 Carlos Rovira :

> Thanks Chris,
>
> I start to see the way...but something is failing. I try some combinations
> without luck. The following pom I try is what I think is more close to
> something OK:
>
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>
>   com.carlosrovira.flexjs.examples
>   TestFlexJS
>   0.8.0-SNAPSHOT
>   swf
>
>   Apache Flex - FlexJS: Examples: FlexJS: TestFlexJS
>
>   
> 
>   
> org.apache.flex.flexjs.compiler
> flexjs-maven-plugin
> true
> 
>   Main.as
>   true
> 
>   
> 
>   
>
> 
>
> but I get:
>
> [INFO] BUILD FAILURE
>
> [INFO] 
> 
>
> [ERROR] Failed to execute goal org.apache.flex.flexjs.
> compiler:flexjs-maven-plugin:0.7.0:compile-app (default-compile-app) on
> project TestFlexJS: *Could not find tool group: FlexJS* -> [Help 1]
>
> Some clue about what can be the problem?
>
> Thanks
>
>
> 2016-09-27 21:14 GMT+02:00 Christofer Dutz :
>
>> Hi Carlos,
>>
>>
>> "swf" and "swc" is more a placeholder for "application" or "library" ...
>> it's more historically to name them that way.
>>
>>
>> The default of a "swf" module would produce a swf file. But by using the
>> config option:
>>
>> true
>>
>> the output should be JavaScript instead.
>>
>>
>> In the examples I use the default to produce the swf and add a second
>> "execution" to produce the JavaScript output (see the pom in
>> flex-asjs/examples/flexjs/pom.xml). Additionally I use the
>> maven-war-plugin to create a war file from the debug-output and add that to
>> the build using the build-helper-maven-plugin (This way the war is
>> automatically installed and deployed). The cool thing about this is that
>> you can use this war as an overlay to bundle the client with a server
>> application.
>>
>>
>> I guess I'll be writing some documentation, now that the site deployment
>> seems to be setup.
>>
>>
>> When building pure JavaScript output you can probably omit the
>> playerglobal. Just give it a try.
>>
>>
>> I just had a look at your pom ... you need a packaging of swf,
>> additionally you need the outputJavaScript = true. You can omit the war and
>> buildhelper plugin for now, the output will be in
>>
>> target/javascript/bin/js-debug
>>
>>
>> Chris
>>
>>
>>
>> 
>> Von: carlos.rov...@gmail.com  im Auftrag von
>> Carlos Rovira 
>> Gesendet: Dienstag, 27. September 2016 18:12:29
>> An: dev@flex.apache.org
>> Betreff: [FlexJS][Maven] Simple pom with js output
>>
>> Hi Chris,
>>
>> I'm trying to make a test flex's maven project. I check some projects in
>> "examples" folder and the poms has SWF packing
>> (swf)
>> So first question is...to get JS output I should use other kind of
>> packaging?)
>>
>> I could remove the dependency on player global?
>>
>> Hope you could help me to configure it a get a successful build.
>>
>> This is a my basic pom.xml (note: I suppose I can use Main.as as main
>> class
>> or Main.mxml, I used .as since I'm testing VisualCode extension from
>> NextGenAS in parallel)
>>
>> http://maven.apache.org/POM/4.0.0";
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd";>
>>   4.0.0
>>
>>   com.carlosrovira.flexjs.examples
>>   TestFlexJS
>>   0.1.0-SNAPSHOT
>>   ???
>>
>>   Apache Flex - FlexJS: Examples: FlexJS: TestFlexJS
>>
>>   
>> 
>>   
>> org.apache.flex.flexjs.compiler
>> flexjs-maven-plugin
>> true
>> 
>>   Ma

AW: [FlexJS][Maven] Simple pom with js output

[Christofer Dutz]

Hi Carlos,


remove the pluginManagment tags and make the plugins a direct child of build.



http://maven.apache.org/POM/4.0.0";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";

XML Schema instance namespace - 
w3.org
www.w3.org
$Date: 2001/03/16 20:25:57 $ $Id: XMLSchema-instance.xsd,v 1.4 2001/03/16 
20:25:57 ht Exp $ This schema should never be used as such: the XML ...



 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0

  com.carlosrovira.flexjs.examples
  TestFlexJS
  0.1.0-SNAPSHOT
  pom

  My Own TestFlexJS

  
0.7.0
  

  
src
  

  org.apache.flex.flexjs.compiler
  flexjs-maven-plugin
  ${flexjs.compiler.version}
  true
  


  compile-javascript
  compile
  
compile-app
  
  
HelloWorld.mxml
true
  

  

  

  org.apache.flex.flexjs.compiler
  compiler-jx
  ${flexjs.compiler.version}

  

  
  




That should probably do the trick.


By the way ... I'm currently working on some maven archetypes. These are 
something like templates to automatically generate and setup new maven 
projects. Was stuck in preparations for ApacheCon today and struggling to find 
out why the builds wasn't working, but perhaps I'll manage to deliver something 
tomorrow.


Chris


Chris


Von: carlos.rov...@gmail.com  im Auftrag von Carlos 
Rovira 
Gesendet: Mittwoch, 28. September 2016 23:04:04
An: dev@flex.apache.org
Betreff: Re: [FlexJS][Maven] Simple pom with js output

Hi Chris,

final y I get a BUILD SUCCESS :)
But there's no target and no output :(
Do you know what could be happen?

This is the pom.xml (notice that the project only has one file in src
folder called 'HelloWorld.mxml'):


http://maven.apache.org/POM/4.0.0";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0

  com.carlosrovira.flexjs.examples
  TestFlexJS
  0.1.0-SNAPSHOT
  pom

  My Own TestFlexJS

  
0.7.0
  

  
src

  

  org.apache.flex.flexjs.compiler
  flexjs-maven-plugin
  ${flexjs.compiler.version}
  true
  


  compile-javascript
  compile
  
compile-app
  
  
HelloWorld.mxml
true
  

  

  

  org.apache.flex.flexjs.compiler
  compiler-jx
  ${flexjs.compiler.version}

  

  

  



Thanks










2016-09-27 23:25 GMT+02:00 Carlos Rovira :

> Thanks Chris,
>
> I start to see the way...but something is failing. I try some combinations
> without luck. The following pom I try is what I think is more close to
> something OK:
>
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>
>   com.carlosrovira.flexjs.examples
>   TestFlexJS
>   0.8.0-SNAPSHOT
>   swf
>
>   Apache Flex - FlexJS: Examples: FlexJS: TestFlexJS
>
>   
> 
>   
> org.apache.flex.flexjs.compiler
> flexjs-maven-plugin
> true
> 
>   Main.as
>   true
> 
>   
> 
>   
>
> 
>
> but I get:
>
> [INFO] BUILD FAILURE
>
> [INFO] 
> 
>
> [ERROR] Failed to execute goal org.apache.flex.flexjs.
> compiler:flexjs-maven-plugin:0.7.0:compile-app (default-compile-app) on
> project TestFlexJS: *Could not find tool group: FlexJS* -> [Help 1]
>
> Some clue about what can be the problem?
>
> Thanks
>
>
> 2016-09-27 21:14 GMT+02:00 Christofer Dutz :
>
>> Hi Carlos,
>>
>>
>> "swf" and "swc" is more a placeholder for "application" or "library" ...
>> it's more historically to name them that way.
>>
>>
>> The default of a "swf" module would produce a swf file. But by using the
>> config option:
>>
>> true
>>
>> the output should be JavaScript instead.
>>
>>
>> In the examples I use the default to produce the swf and add a second
>> "execution" to produce the JavaScript output (see the pom in
>> flex-asjs/examples/flexjs/pom.xml). Additionally I use the
>> maven-war-plugin to create a war file from the debug-output and add that to
>> the build using the build-helper-maven-plugin (This way the war is
>> automatically installed and deployed). The cool thing about this is that
>> you can use this

Re: [FlexJS][Maven] Simple pom with js output

[Carlos Rovira]

Hi Chris,

thanks, I try to remove that tag but now I get a failure :(

[INFO]


[INFO] Building My Own TestFlexJS 0.1.0-SNAPSHOT

[INFO]


[INFO]

[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ TestFlexJS ---

[INFO] Deleting
/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/target

[INFO]

[INFO] --- flexjs-maven-plugin:0.7.0:compile-app (compile-javascript) @
TestFlexJS ---

[INFO] Executing MXMLC in tool group FlexJS with args:
[-load-config=/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/target/compile-app-javascript-config.xml,
/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/src/HelloWorld.mxml]

Missing builtin type Object


Unable to build SWF
/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/target/javascript


[INFO]


[INFO] BUILD FAILURE

[INFO]


[INFO] Total time: 0.951 s

[INFO] Finished at: 2016-09-28T23:28:08+02:00

[INFO] Final Memory: 12M/307M

[INFO]


[ERROR] Failed to execute goal
org.apache.flex.flexjs.compiler:flexjs-maven-plugin:0.7.0:compile-app
(compile-javascript) on project TestFlexJS: There were errors during the
build. -> [Help 1]



btw, it would be great to get a template and simplify a project setup :)

Thanks

Carlos



2016-09-28 23:15 GMT+02:00 Christofer Dutz :

> Hi Carlos,
>
>
> remove the pluginManagment tags and make the plugins a direct child of
> build.
>
>
> 
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> XML Schema instance namespace - w3.org XMLSchema-instance>
> www.w3.org
> $Date: 2001/03/16 20:25:57 $ $Id: XMLSchema-instance.xsd,v 1.4 2001/03/16
> 20:25:57 ht Exp $ This schema should never be used as such: the XML ...
>
>
>
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>
>   com.carlosrovira.flexjs.examples
>   TestFlexJS
>   0.1.0-SNAPSHOT
>   pom
>
>   My Own TestFlexJS
>
>   
> 0.7.0
>   
>
>   
> src
>   
> 
>   org.apache.flex.flexjs.compiler
>   flexjs-maven-plugin
>   ${flexjs.compiler.version}
>   true
>   
> 
> 
>   compile-javascript
>   compile
>   
> compile-app
>   
>   
> HelloWorld.mxml
> true
>   
> 
>   
>
>   
> 
>   org.apache.flex.flexjs.compiler
>   compiler-jx
>   ${flexjs.compiler.version}
> 
>   
> 
>   
>   
>
> 
>
>
> That should probably do the trick.
>
>
> By the way ... I'm currently working on some maven archetypes. These are
> something like templates to automatically generate and setup new maven
> projects. Was stuck in preparations for ApacheCon today and struggling to
> find out why the builds wasn't working, but perhaps I'll manage to deliver
> something tomorrow.
>
>
> Chris
>
>
> Chris
>
> 
> Von: carlos.rov...@gmail.com  im Auftrag von
> Carlos Rovira 
> Gesendet: Mittwoch, 28. September 2016 23:04:04
> An: dev@flex.apache.org
> Betreff: Re: [FlexJS][Maven] Simple pom with js output
>
> Hi Chris,
>
> final y I get a BUILD SUCCESS :)
> But there's no target and no output :(
> Do you know what could be happen?
>
> This is the pom.xml (notice that the project only has one file in src
> folder called 'HelloWorld.mxml'):
>
> 
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>
>   com.carlosrovira.flexjs.examples
>   TestFlexJS
>   0.1.0-SNAPSHOT
>   pom
>
>   My Own TestFlexJS
>
>   
> 0.7.0
>   
>
>   
> src
> 
>   
> 
>   org.apache.flex.flexjs.compiler
>   flexjs-maven-plugin
>   ${flexjs.compiler.version}
>   true
>   
> 
> 
>   compile-javascript
>   compile
>   
> compile-app
>   
>   
> HelloWorld.mxml
> true
>   
> 
>   
>
>   
> 
>   org.apache.flex.flexjs.compiler
>   compiler-jx
>   ${flexjs.compiler.version}
> 
>   
> 
>   
> 
>   
>
> 
>
> Thanks
>
>
>
>
>
>
>
>
>
>
> 2016-09-27 23:25 GMT+02:00 Carlos Rovira :
>
> > Thanks Chris,
> >
> > 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui]

On 9/28/16, 12:21 AM, "Harbs"  wrote:

>The overhead to swfs seem to me like it’s really minimal. There’s not a
>lot of added code for using composition rather than inheritance.

Well, at Adobe, we said "the overhead is minimal" so many times in Flex
that UIComponent grew to 13,000 lines of code.  I could put the code
through a profiler, but my understanding is that the refactor creates
twice as many objects and probably at least twice as many function calls
at runtime.  Yes, we will accept bigger sizes and slower performance on
the SWF side in order to make sure the JS side is as efficient as
possible, but IMO, we aren't wrapping Sprite to help the JS side.

>
>Improving events is probably something which should be done for the JS
>side as well, so I’m not convinced that’s a major problem either. Some of
>the event issues we had had nothing to do with inheritance vs composition
>of Sprite and friends. It had to do with the fact that MouseEvent and
>Event are unrelated.

Yup, and once we decide on the sprite refactor we can then decide on how
to deal with events.

>
>Additionally, I really don’t believe most folks will use swf output for
>much more than debugging purposes, so if there’s a little more overhead,
>so what?

Ideally, the SWF version would remain viable for deployment so folks who
can use Flash can continue to save on cross-browser testing, but also, we
need big apps to load the SWF version fast enough to make it efficient to
use as a debugging version.  Doubling objects and function calls isn't
going to help.


>We’ve also done a lot of work on the sprite-refactor branch which would
>be hard to back-port.

I would think if we abandon the sprite wrapping, we would revert UIBase
and Application to extend Sprite in the refactor branch, then the branch
merge to develop would pick up everything else.

IMO, if it were easy to upgrade every Flex IDE, we would solve the issue
of detecting which Flash APIs aren't available by modifying the IDEs.
This means to me that it isn't required to solve this problem by making
changes to the runtime output.

Today, I played with a "new workflow" for migrating apps that might solve
this problem for FB and maybe other IDEs.  I created a test app called
"NewFlexJSProject" and selected FlexJS as the SDK.  It looked like this:

http://ns.adobe.com/mxml/2009";
   xmlns:js="library://ns.apache.org/flexjs/basic" >



...


As you can see it overrides the buttonMode setter on Sprite, which isn't
supported by FlexJS.  AIUI, this is typical of the kinds of problems you
ran into.  The SWF version compiles just fine.


Next, I created another Flex project and made the application look like
this:

http://ns.adobe.com/mxml/2009";
xmlns:js="library://ns.apache.org/flexjs/basic" >





I set the source path to point to NewFlexJSProject/src, then I modified
the library-path to remove the standard FlexJS SWCs and playerglobal, then
add in the js.swc from js/libs and the SWC folder from
frameworks/js/FlexJS/libs.  That folder contains xxxJS.swc that present
the JS-side APIs to downstream SWCs.


When I did that, this project showed errors about buttonMode in
NewFlexJSProject.mxml.

IMO, a workflow like this might be sufficient for speeding up migration
without requiring the extra overhead of wrapping Sprite.  We could
possibly teach our compilers to compile twice, once with each library path
so you don't have to set up the second project.  That's why I believe
there are ways to solve the problem of catching use of Sprite APIs without
wrapping Sprite and making all SWFs pay the price via the tool chain and
not code running at runtime.

Thoughts?
-Alex

AW: [FlexJS][Maven] Simple pom with js output

[Christofer Dutz]

In contrast to the usual setup using Ant where you simply always add all 
framework SWCs, with maven you only add the ones you use, so you need some of 
the Framework dependencies in you pom.


Let me whip up the artifacts ... I think that will help a lot :-)


Chris


Von: carlos.rov...@gmail.com  im Auftrag von Carlos 
Rovira 
Gesendet: Mittwoch, 28. September 2016 23:31:57
An: dev@flex.apache.org
Betreff: Re: [FlexJS][Maven] Simple pom with js output

Hi Chris,

thanks, I try to remove that tag but now I get a failure :(

[INFO]


[INFO] Building My Own TestFlexJS 0.1.0-SNAPSHOT

[INFO]


[INFO]

[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ TestFlexJS ---

[INFO] Deleting
/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/target

[INFO]

[INFO] --- flexjs-maven-plugin:0.7.0:compile-app (compile-javascript) @
TestFlexJS ---

[INFO] Executing MXMLC in tool group FlexJS with args:
[-load-config=/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/target/compile-app-javascript-config.xml,
/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/src/HelloWorld.mxml]

Missing builtin type Object


Unable to build SWF
/Users/carlosrovira/Dev/Flex/projects/flexjs/TestFlexJS/target/javascript


[INFO]


[INFO] BUILD FAILURE

[INFO]


[INFO] Total time: 0.951 s

[INFO] Finished at: 2016-09-28T23:28:08+02:00

[INFO] Final Memory: 12M/307M

[INFO]


[ERROR] Failed to execute goal
org.apache.flex.flexjs.compiler:flexjs-maven-plugin:0.7.0:compile-app
(compile-javascript) on project TestFlexJS: There were errors during the
build. -> [Help 1]



btw, it would be great to get a template and simplify a project setup :)

Thanks

Carlos



2016-09-28 23:15 GMT+02:00 Christofer Dutz :

> Hi Carlos,
>
>
> remove the pluginManagment tags and make the plugins a direct child of
> build.
>
>
> 
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> XML Schema instance namespace - w3.org XMLSchema-instance>
> www.w3.org
> $Date: 2001/03/16 20:25:57 $ $Id: XMLSchema-instance.xsd,v 1.4 2001/03/16
> 20:25:57 ht Exp $ This schema should never be used as such: the XML ...
>
>
>
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>
>   com.carlosrovira.flexjs.examples
>   TestFlexJS
>   0.1.0-SNAPSHOT
>   pom
>
>   My Own TestFlexJS
>
>   
> 0.7.0
>   
>
>   
> src
>   
> 
>   org.apache.flex.flexjs.compiler
>   flexjs-maven-plugin
>   ${flexjs.compiler.version}
>   true
>   
> 
> 
>   compile-javascript
>   compile
>   
> compile-app
>   
>   
> HelloWorld.mxml
> true
>   
> 
>   
>
>   
> 
>   org.apache.flex.flexjs.compiler
>   compiler-jx
>   ${flexjs.compiler.version}
> 
>   
> 
>   
>   
>
> 
>
>
> That should probably do the trick.
>
>
> By the way ... I'm currently working on some maven archetypes. These are
> something like templates to automatically generate and setup new maven
> projects. Was stuck in preparations for ApacheCon today and struggling to
> find out why the builds wasn't working, but perhaps I'll manage to deliver
> something tomorrow.
>
>
> Chris
>
>
> Chris
>
> 
> Von: carlos.rov...@gmail.com  im Auftrag von
> Carlos Rovira 
> Gesendet: Mittwoch, 28. September 2016 23:04:04
> An: dev@flex.apache.org
> Betreff: Re: [FlexJS][Maven] Simple pom with js output
>
> Hi Chris,
>
> final y I get a BUILD SUCCESS :)
> But there's no target and no output :(
> Do you know what could be happen?
>
> This is the pom.xml (notice that the project only has one file in src
> folder called 'HelloWorld.mxml'):
>
> 
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>
>   com.carlosrovira.flexjs.examples
>   TestFlexJS
>   0.1.0-SNAPSHOT
>   pom
>
>   My Own TestFlexJS
>
>   
> 0.7.0
>   
>
>   
> src
> 
>   
> 
>   org.apache.flex.flexjs.compiler
>   flexjs-maven-plugin
>   ${flexjs.compiler.version}
>   true
>   
> 
> 
>   compile-javascript
>   compile
> 

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Greg Dove]

I got this working quite quickly for the charts but also experienced issues
with FlexJSStore bulding, which I have since addressed.

I am just checking all examples - the ant build of all examples now
completes, I just want to visually check them all - and then I will run a
full set of tests before pushing the fix.



On Thu, Sep 29, 2016 at 7:44 AM, Greg Dove  wrote:

> I will look at this now.
>
> I had intended for relection to always be at the end, so that definitely
> sounds wrong.
> I did find the usedNames/postProcess sequence to be a possible candidate
> for refactor at some point, but was not keen to mess with this at the
> moment. I think I found that some usedNames were not being added to
> goog.requires as it was originally.
>
>
>
> On Thu, Sep 29, 2016 at 7:33 AM, Alex Harui  wrote:
>
>> Looked into it.  It appears to be related to Greg's changes in
>> 0bde1ec7a47341294280082331ce8b2c023d756f
>>
>> In MXMLFlexJSEmitter, the namesToAdd is including internal classes which
>> it shouldn't.  Probably the subDocuments list can be used to further
>> filter what gets added to namesToAdd.
>>
>> Also, the reflection data for internal classes is being emitted at the top
>> of the output file.  That should probably get changed as well.
>>
>> I'm going back to other things.  I expect Greg will take care of this.
>> Greg, let us know if you need help or don't have time.
>>
>> -Alex
>>
>> On 9/28/16, 9:40 AM, "Alex Harui"  wrote:
>>
>> >The Ant build doesn't build the examples.  Maybe it should.  The
>> >ChartExample fails for me from Ant as well.  I will look into it.
>> >
>> >-Alex
>> >
>> >On 9/28/16, 2:30 AM, "Christofer Dutz" 
>> wrote:
>> >
>> >>Ok now the modules that were failing compile successfully. Unfortunately
>> >>now a little more down the stream the examples seem to be failing. I am
>> >>getting errors in the chart example (just the first example to be
>> >>compiled) It seems the JS compilation is failing because it cant find
>> >>generated classes.
>> >>
>> >>
>> >>https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20
>> Framework%20(ma
>> >>v
>> >>en)/269/console
>> >>
>> >>
>> >>Did anything change in this part recently?
>> >
>>
>>
>

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Alex Harui]

Hi Greg,

The build failed for some strange reason.  Might be a threading issue
unrelated to your changes.  I pulled everything and was able to build.
I've restarted the CI build to see if the same error comes up again.

I also ran "ant sdk.dependent.tests flexjs.dependent.tests" and there were
a couple of failures in the compiler-ix tests.  There are files in
compiler-jx/src/test/resources/flexjs that need updating but it also looks
like an extra new-line is being added after goog.inherits in some cases.
Let us know if you get the same results.

Results are available in compiler-jx/target/junit-results.  If
TestFlexJSFile is reporting errors, there will be an xml file that ends
with TestFlexJSFIle.xml.  It will contain the string "http://www.freeformatter.com/xml-escape.html#ad-output to get
readable text, then I have a utility hosted on at
http://home.apache.org/~aharui/TestResultCompare/TestResultCompare.html
that you can use to help you compare the results.  Paste the readable
results and hit the button, then scroll down the other TextAreas.  The
text will turn to bold where the first difference is found.  There is no
way to see all differences, just the first one so you have to make and
adjustment, re-run the test, re-compare the results.

Hopefully that's enough info so you can figure it out.

Thanks,
-Alex

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Greg Dove]

oh. I thought I had this sorted, I can run the ant and maven builds
locally, and all the examples were building for me.

I will check again.

On Thu, Sep 29, 2016 at 6:00 PM, Alex Harui  wrote:

> Hi Greg,
>
> The build failed for some strange reason.  Might be a threading issue
> unrelated to your changes.  I pulled everything and was able to build.
> I've restarted the CI build to see if the same error comes up again.
>
> I also ran "ant sdk.dependent.tests flexjs.dependent.tests" and there were
> a couple of failures in the compiler-ix tests.  There are files in
> compiler-jx/src/test/resources/flexjs that need updating but it also looks
> like an extra new-line is being added after goog.inherits in some cases.
> Let us know if you get the same results.
>
> Results are available in compiler-jx/target/junit-results.  If
> TestFlexJSFile is reporting errors, there will be an xml file that ends
> with TestFlexJSFIle.xml.  It will contain the string " failure.  You will see an xml-escaped string with the error, in this case,
> comparing the expected vs actual results.  You can use an unescape tool
> like http://www.freeformatter.com/xml-escape.html#ad-output to get
> readable text, then I have a utility hosted on at
> http://home.apache.org/~aharui/TestResultCompare/TestResultCompare.html
> that you can use to help you compare the results.  Paste the readable
> results and hit the button, then scroll down the other TextAreas.  The
> text will turn to bold where the first difference is found.  There is no
> way to see all differences, just the first one so you have to make and
> adjustment, re-run the test, re-compare the results.
>
> Hopefully that's enough info so you can figure it out.
>
> Thanks,
> -Alex
>
>

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Greg Dove]

btw I added an extra case to the if chain in the css code in a recent
commit. It was to cover an rgba variation in DatabindingExample_Flat iirc.
But I don't think it processes the alpha part of the rgba anywhere... I
added todo: comments for this, but I am not sure how important it might be



On Thu, Sep 29, 2016 at 6:03 PM, Greg Dove  wrote:

> oh. I thought I had this sorted, I can run the ant and maven builds
> locally, and all the examples were building for me.
>
> I will check again.
>
> On Thu, Sep 29, 2016 at 6:00 PM, Alex Harui  wrote:
>
>> Hi Greg,
>>
>> The build failed for some strange reason.  Might be a threading issue
>> unrelated to your changes.  I pulled everything and was able to build.
>> I've restarted the CI build to see if the same error comes up again.
>>
>> I also ran "ant sdk.dependent.tests flexjs.dependent.tests" and there were
>> a couple of failures in the compiler-ix tests.  There are files in
>> compiler-jx/src/test/resources/flexjs that need updating but it also
>> looks
>> like an extra new-line is being added after goog.inherits in some cases.
>> Let us know if you get the same results.
>>
>> Results are available in compiler-jx/target/junit-results.  If
>> TestFlexJSFile is reporting errors, there will be an xml file that ends
>> with TestFlexJSFIle.xml.  It will contain the string "> failure.  You will see an xml-escaped string with the error, in this case,
>> comparing the expected vs actual results.  You can use an unescape tool
>> like http://www.freeformatter.com/xml-escape.html#ad-output to get
>> readable text, then I have a utility hosted on at
>> http://home.apache.org/~aharui/TestResultCompare/TestResultCompare.html
>> that you can use to help you compare the results.  Paste the readable
>> results and hit the button, then scroll down the other TextAreas.  The
>> text will turn to bold where the first difference is found.  There is no
>> way to see all differences, just the first one so you have to make and
>> adjustment, re-run the test, re-compare the results.
>>
>> Hopefully that's enough info so you can figure it out.
>>
>> Thanks,
>> -Alex
>>
>>
>

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Alex Harui]

The Ant build doesn't run flexjs.dependent.tests automatically.  You have
to run ant with that target.  It could be my setup, but I think those
files I mentioned need to be updated for the new reflection data.

Thanks,
-Alex

On 9/28/16, 10:03 PM, "Greg Dove"  wrote:

>oh. I thought I had this sorted, I can run the ant and maven builds
>locally, and all the examples were building for me.
>
>I will check again.
>
>On Thu, Sep 29, 2016 at 6:00 PM, Alex Harui  wrote:
>
>> Hi Greg,
>>
>> The build failed for some strange reason.  Might be a threading issue
>> unrelated to your changes.  I pulled everything and was able to build.
>> I've restarted the CI build to see if the same error comes up again.
>>
>> I also ran "ant sdk.dependent.tests flexjs.dependent.tests" and there
>>were
>> a couple of failures in the compiler-ix tests.  There are files in
>> compiler-jx/src/test/resources/flexjs that need updating but it also
>>looks
>> like an extra new-line is being added after goog.inherits in some cases.
>> Let us know if you get the same results.
>>
>> Results are available in compiler-jx/target/junit-results.  If
>> TestFlexJSFile is reporting errors, there will be an xml file that ends
>> with TestFlexJSFIle.xml.  It will contain the string "> failure.  You will see an xml-escaped string with the error, in this
>>case,
>> comparing the expected vs actual results.  You can use an unescape tool
>> like http://www.freeformatter.com/xml-escape.html#ad-output to get
>> readable text, then I have a utility hosted on at
>> http://home.apache.org/~aharui/TestResultCompare/TestResultCompare.html
>> that you can use to help you compare the results.  Paste the readable
>> results and hit the button, then scroll down the other TextAreas.  The
>> text will turn to bold where the first difference is found.  There is no
>> way to see all differences, just the first one so you have to make and
>> adjustment, re-run the test, re-compare the results.
>>
>> Hopefully that's enough info so you can figure it out.
>>
>> Thanks,
>> -Alex
>>
>>

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Alex Harui]

On 9/28/16, 10:05 PM, "Greg Dove"  wrote:

>btw I added an extra case to the if chain in the css code in a recent
>commit. It was to cover an rgba variation in DatabindingExample_Flat iirc.
>But I don't think it processes the alpha part of the rgba anywhere... I
>added todo: comments for this, but I am not sure how important it might be
>

I saw the commit email.  Seems helpful.  I hope to get to more
sophisticated CSS processing someday where that might become important.

Thanks,
-Alex

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Greg Dove]

ok great, thanks. I have to step aside for an hour or so. I will check it
after that


On Thu, Sep 29, 2016 at 6:11 PM, Alex Harui  wrote:

> The Ant build doesn't run flexjs.dependent.tests automatically.  You have
> to run ant with that target.  It could be my setup, but I think those
> files I mentioned need to be updated for the new reflection data.
>
> Thanks,
> -Alex
>
> On 9/28/16, 10:03 PM, "Greg Dove"  wrote:
>
> >oh. I thought I had this sorted, I can run the ant and maven builds
> >locally, and all the examples were building for me.
> >
> >I will check again.
> >
> >On Thu, Sep 29, 2016 at 6:00 PM, Alex Harui  wrote:
> >
> >> Hi Greg,
> >>
> >> The build failed for some strange reason.  Might be a threading issue
> >> unrelated to your changes.  I pulled everything and was able to build.
> >> I've restarted the CI build to see if the same error comes up again.
> >>
> >> I also ran "ant sdk.dependent.tests flexjs.dependent.tests" and there
> >>were
> >> a couple of failures in the compiler-ix tests.  There are files in
> >> compiler-jx/src/test/resources/flexjs that need updating but it also
> >>looks
> >> like an extra new-line is being added after goog.inherits in some cases.
> >> Let us know if you get the same results.
> >>
> >> Results are available in compiler-jx/target/junit-results.  If
> >> TestFlexJSFile is reporting errors, there will be an xml file that ends
> >> with TestFlexJSFIle.xml.  It will contain the string " >> failure.  You will see an xml-escaped string with the error, in this
> >>case,
> >> comparing the expected vs actual results.  You can use an unescape tool
> >> like http://www.freeformatter.com/xml-escape.html#ad-output to get
> >> readable text, then I have a utility hosted on at
> >> http://home.apache.org/~aharui/TestResultCompare/TestResultCompare.html
> >> that you can use to help you compare the results.  Paste the readable
> >> results and hit the button, then scroll down the other TextAreas.  The
> >> text will turn to bold where the first difference is found.  There is no
> >> way to see all differences, just the first one so you have to make and
> >> adjustment, re-run the test, re-compare the results.
> >>
> >> Hopefully that's enough info so you can figure it out.
> >>
> >> Thanks,
> >> -Alex
> >>
> >>
>
>

Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Alex Harui]

On 9/28/16, 10:13 PM, "Greg Dove"  wrote:

>ok great, thanks. I have to step aside for an hour or so. I will check it
>after that

I don't think there's a big rush.  This is an opportunity to share where
some of the pieces are and how I deal with them.

Thanks for sticking with it,
-Alex

First time user

[rich...@o3i.com.au]

Hi

Apologies for the naivety of this question but I have successfully installed
the latest SDK (windows) and want to start using it in Flash builder 4.6. If
I try to create a new project I get the message 'Flash builder 4 only
supports Flex SDK 3.9 and higher.

Can someone tell me what I am missing?

Cheers

Richard




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/First-time-user-tp55436.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

AW: AW: AW: [FlexJS] Problem with some test cases (@export was changed to @expose)?

[Christofer Dutz]

Ok ... thanks for fixing ... ASF Jenkins' Maven builds are back to blue ... a 
day always starts good with all successful jobs ;-)


Chris


Von: Alex Harui 
Gesendet: Donnerstag, 29. September 2016 07:18:44
An: dev@flex.apache.org
Betreff: Re: AW: AW: [FlexJS] Problem with some test cases (@export was changed 
to @expose)?



On 9/28/16, 10:13 PM, "Greg Dove"  wrote:

>ok great, thanks. I have to step aside for an hour or so. I will check it
>after that

I don't think there's a big rush.  This is an opportunity to share where
some of the pieces are and how I deal with them.

Thanks for sticking with it,
-Alex

Two of my Flex talks got accepted for ApacheCon EU 2016 in Ceville

[Christofer Dutz]

Hi guys,


I just wanted to tell you that two of my talks got accepted for this years 
european ApacheCon Core.


- Apache FlexJS' Maven migration initiative - introducing the 
flexjs-maven-plugin

- Frontends for IoT Systems built with Apache Flex


... really happy about that :-)


Chris