You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Frank Wienberg <fr...@jangaroo.net> on 2013/01/19 22:08:08 UTC
[FalconJx] AMD-based JavaScript code implemented in Jangaroo
Hi folks,
I have been rather quiet for a while, but that's because I have been busy
implementing JavaScript code generation according to the Runtime prototype
I posted some weeks ago. However, I started off implementing this in the
Jangaroo compiler, not in Falcon. I am far quicker implementing this in the
context I know, it would have taken me much longer getting started with
Falcon first. So of course now I hope that you guys help me porting this
solution to FalconJx...
I'm about 80% finished implementing all the AS3 language features I started
documenting in the Flex Wiki and already have a demo of a large
application, namely the Open Flash Charts demo, recompiled with the new AMD
approach.
Background on the demo:
Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure
ActionScript 3 project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/Version%202%20Lug%20Wyrm%20Charmer/>,
and I only had to make very few changes to the original AS3 code to make
the JavaScript version generated by the Jangaroo compiler work in the
browser, without a Flash plugin. This has been working with Jangaroo 1 and
2, and now I got it to run with the new runtime format proposed for
FalconJx.
The demo comes in two flavors:
The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
where the whole application is a minified single JS file of about 380 kb
(unzipped, the original SWF has 320 kb, and that is zipped and of course
does not contain the Flash classes, because they come with the
FlashPlayer!):
*http://jangaron.net/ofc5/data-files/joo.html*
Or load the "debug"
version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
where the JS equivalent of every AS class is loaded as a single request,
simply by adding hash joo.debug to the URL:
*http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
This demonstrates the real benefit of the AMD approach: RequireJS is
capable of loading all needed scripts one by one (debug mode) as well as
optimize them into a single JS file for production. It can use Uglify,
Uglify2 or Google Closure for minification.
Loading every AS class as a single request is still astonishingly fast,
especially when using local deployment, which is what you usually do for
debugging. Note that the demo uses over 200 classes.
Have a look at the generated JavaScript, and you'll see that Jangaroo keeps
the original ActionScript code either as comment (if there is no JavaScript
counterpart, like for "package", "class", type annotations), or as
executable code in the exact line where the original AS code was. That
means if you want to debug say line 20 of AS class "Foo", you open script
"Foo.js" in the JavaScript debugger and find the code and set the
breakpoint in that same line: 20. This is a special Jangaroo feature which
we do not necessarily need to implement for FalconJx. However, I still
think it is a good feature, and since it does not slow down the optimized
version, why not implement it for FalconJx, too?
What I think we do need in any case is the ability to load AS classes by
single requests, as otherwise they are really hard to find when debugging
in the browser. And this is what you get for free when using RequireJS. In
Alex' prototype, the only way to achieve this behavior was to list all
needed single class scripts in the HTML (see FlexJS Wiki page). Of course,
such HTML could be generated, but I think RequireJS' approach is more
elegant.
Another thing you can see in the Open Flash Chart demo is how I implemented
static code execution. ActionScript executes all static code of the whole
"compilation unit" the first time its "primary declaration" (usually a
class) is accessed.
Consequently, not (only) an ActionScript class, but an ActionScript
"compilation unit" is put into a JavaScript AMD module definition. Thus,
the module's value is not the class itself, but a compilation unit
containing the class. I use the property "_" for the class or any other
primary declaration, which in AS3 can also be a function, variable or
constant. The static code of the compilation unit is *not* executed when it
is *loaded*, but when the "_" property is *accessed* for the first time.
(Because code has to be loaded asynchronously in the browser, we cannot
load the module when it is accessed synchronously, but have to load all
static dependencies in advance.) This is equivalent to the original AS3
behavior, and only introduces the minimal overhead of accessing Foo._
instead of just Foo.
If you want to play with the new Jangaroo compiler to see what JavaScript
output is generated for your ActionScript input, the simplest way is as
follows.
You need to have Java, Git and Maven installed and properly set up.
Clone the jangaroo-tools repository and switch to branch jangaroo-3:
> git clone git://github.com/CoreMedia/jangaroo-tools.git
> git checkout jangaroo-3
Then run the integration tests via Maven:
> cd jangaroo-tools
> mvn install -pl :jangaroo-compiler-itests -am
This should result in a BUILD SUCCESS.
The jangaroo-compiler-itests module is under
jangaroo/jangaroo-compiler-itests:
> cd jangaroo/jangaroo-compiler-itests
For the intergration tests, all *.as files under src/test/joo/ are compiled
to target/temp/joo/classes/, respecting their package sub-directory. So if
you add an *.as file under the src/test/joo/ directory, the corresponding
*.js file will appear under the target/temp/joo/classes/ directory after
the following Maven command:
> mvn test-compile
Note that you cannot use Flash API here (will result in compile error, as
classes are not found), only basic classes like String, Array, and built-in
functions like trace().
Another good news is that my employer signed the CCLA, and it has been
confirmed by Craig, so now I am all set to contribute Jangaroo code to
Apache Flex!
The code that generates the new JavaScript runtime format is in jangaroo-tools
on the "jangaroo-3"
branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
(see
above), especially class
JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java>(Michael
Sch. knows this already!) is interesting for porting code to
FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
I am also working on another demo, which is written in AS3 and MXML (!),
but instead of Flex components, uses "native" Ext JS JavaScript components
through an AS API. It does not use the Jangaroo Flash library
re-implementation (JooFlash), so this sounds similar to Alex' approach to
not use the display list to render MXML components. More update on this to
follow.
Would really be great if we could consolidate our solutions!
Can't wait for your feedback,
-Frank-
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> Falcon first. So of course now I hope that you guys help me porting this
> solution to FalconJx...
Frank,
I have created the preliminary implementation of an AMD emitter in FalconJx.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi Tom,
On Sat, Mar 2, 2013 at 6:11 PM, Tom Brazil <to...@systar.com> wrote:
> Rather amazing work. Good job.
>
thanks!
> However, what can be done about the massive difference in cpu utilization?
> The flash version used so little cpu that it wasn't noticeable, whereas
> the html5 version pegs a cpu at 40% minimum continuously, and on some
> charts 100% continuously - even when nothing is happening (non debug
> version too).
> Is that an artifact of this particular demo, an artifact of html5, or the
> way things would be for all applications using this approach?
>
I'd say it is an artifact of some parts of the JooFlash implementation.
I recently changed the rendering strategy to better match the one of
original Flash. JooFlash now also renders in a frame-based manner. When the
application code changes a property of some object on the display list,
this value is stored and a "dirty" flag is set. Then, on the next frame
render event, every sub-tree of the display list that has a "dirty" child
is re-rendered.
So for one, there are still some bugs where a "dirty" flag is set although
nothing changed (100% CPU even when nothing is happening), e.g. when the
application code sets a value to the old value (e.g. setFoo(true) when foo
is already true). So this causes unneeded re-rendering of the whole stage
all the time.
The other potential for performance improvement is to introduce redraw
areas like the Flash engine does. This would allow to start redrawing from
the top of the display list, but skip rendering of all display objects that
are completely located outside the redraw areas.
The third way to tweak performance is to play with the "cacheAsBitmap" flag
of display object containers. JooFlash uses a canvas for every DOC that has
this flag set. This can improve performance, if that subtree is not or
rarely changed, but may also decrease performance if for example some
object in this subtree is modified on every frame (e.g. rotated), because
this causes the whole subtree to be re-rendered all the time.
So to conclude, JooFlash is still in an early stage, and there is a high
performance improvement potential. I didn't even mention WebGL or the
like...
Greetings
-Frank-
RE: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Tom Brazil <to...@systar.com>.
Rather amazing work. Good job.
However, what can be done about the massive difference in cpu utilization?
The flash version used so little cpu that it wasn't noticeable, whereas the html5 version pegs a cpu at 40% minimum continuously, and on some charts 100% continuously - even when nothing is happening (non debug version too).
Is that an artifact of this particular demo, an artifact of html5, or the way things would be for all applications using this approach?
-----Original Message-----
From: Frank Wienberg [mailto:frank@jangaroo.net]
Sent: Saturday, January 19, 2013 9:08 PM
To: flex-dev@incubator.apache.org
Subject: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Hi folks,
I have been rather quiet for a while, but that's because I have been busy implementing JavaScript code generation according to the Runtime prototype I posted some weeks ago. However, I started off implementing this in the Jangaroo compiler, not in Falcon. I am far quicker implementing this in the context I know, it would have taken me much longer getting started with Falcon first. So of course now I hope that you guys help me porting this solution to FalconJx...
I'm about 80% finished implementing all the AS3 language features I started documenting in the Flex Wiki and already have a demo of a large application, namely the Open Flash Charts demo, recompiled with the new AMD approach.
Background on the demo:
Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure ActionScript 3 project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/Version%202%20Lug%20Wyrm%20Charmer/>,
and I only had to make very few changes to the original AS3 code to make the JavaScript version generated by the Jangaroo compiler work in the browser, without a Flash plugin. This has been working with Jangaroo 1 and 2, and now I got it to run with the new runtime format proposed for FalconJx.
The demo comes in two flavors:
The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
where the whole application is a minified single JS file of about 380 kb (unzipped, the original SWF has 320 kb, and that is zipped and of course does not contain the Flash classes, because they come with the
FlashPlayer!):
*http://jangaron.net/ofc5/data-files/joo.html*
Or load the "debug"
version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
where the JS equivalent of every AS class is loaded as a single request, simply by adding hash joo.debug to the URL:
*http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
This demonstrates the real benefit of the AMD approach: RequireJS is capable of loading all needed scripts one by one (debug mode) as well as optimize them into a single JS file for production. It can use Uglify,
Uglify2 or Google Closure for minification.
Loading every AS class as a single request is still astonishingly fast, especially when using local deployment, which is what you usually do for debugging. Note that the demo uses over 200 classes.
Have a look at the generated JavaScript, and you'll see that Jangaroo keeps the original ActionScript code either as comment (if there is no JavaScript counterpart, like for "package", "class", type annotations), or as executable code in the exact line where the original AS code was. That means if you want to debug say line 20 of AS class "Foo", you open script "Foo.js" in the JavaScript debugger and find the code and set the breakpoint in that same line: 20. This is a special Jangaroo feature which we do not necessarily need to implement for FalconJx. However, I still think it is a good feature, and since it does not slow down the optimized version, why not implement it for FalconJx, too?
What I think we do need in any case is the ability to load AS classes by single requests, as otherwise they are really hard to find when debugging in the browser. And this is what you get for free when using RequireJS. In Alex' prototype, the only way to achieve this behavior was to list all needed single class scripts in the HTML (see FlexJS Wiki page). Of course, such HTML could be generated, but I think RequireJS' approach is more elegant.
Another thing you can see in the Open Flash Chart demo is how I implemented static code execution. ActionScript executes all static code of the whole "compilation unit" the first time its "primary declaration" (usually a
class) is accessed.
Consequently, not (only) an ActionScript class, but an ActionScript "compilation unit" is put into a JavaScript AMD module definition. Thus, the module's value is not the class itself, but a compilation unit containing the class. I use the property "_" for the class or any other primary declaration, which in AS3 can also be a function, variable or constant. The static code of the compilation unit is *not* executed when it is *loaded*, but when the "_" property is *accessed* for the first time.
(Because code has to be loaded asynchronously in the browser, we cannot load the module when it is accessed synchronously, but have to load all static dependencies in advance.) This is equivalent to the original AS3 behavior, and only introduces the minimal overhead of accessing Foo._ instead of just Foo.
If you want to play with the new Jangaroo compiler to see what JavaScript output is generated for your ActionScript input, the simplest way is as follows.
You need to have Java, Git and Maven installed and properly set up.
Clone the jangaroo-tools repository and switch to branch jangaroo-3:
> git clone git://github.com/CoreMedia/jangaroo-tools.git
> git checkout jangaroo-3
Then run the integration tests via Maven:
> cd jangaroo-tools
> mvn install -pl :jangaroo-compiler-itests -am
This should result in a BUILD SUCCESS.
The jangaroo-compiler-itests module is under
jangaroo/jangaroo-compiler-itests:
> cd jangaroo/jangaroo-compiler-itests
For the intergration tests, all *.as files under src/test/joo/ are compiled to target/temp/joo/classes/, respecting their package sub-directory. So if you add an *.as file under the src/test/joo/ directory, the corresponding *.js file will appear under the target/temp/joo/classes/ directory after the following Maven command:
> mvn test-compile
Note that you cannot use Flash API here (will result in compile error, as classes are not found), only basic classes like String, Array, and built-in functions like trace().
Another good news is that my employer signed the CCLA, and it has been confirmed by Craig, so now I am all set to contribute Jangaroo code to Apache Flex!
The code that generates the new JavaScript runtime format is in jangaroo-tools on the "jangaroo-3"
branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
(see
above), especially class
JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java>(Michael
Sch. knows this already!) is interesting for porting code to FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
I am also working on another demo, which is written in AS3 and MXML (!), but instead of Flex components, uses "native" Ext JS JavaScript components through an AS API. It does not use the Jangaroo Flash library re-implementation (JooFlash), so this sounds similar to Alex' approach to not use the display list to render MXML components. More update on this to follow.
Would really be great if we could consolidate our solutions!
Can't wait for your feedback,
-Frank-
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Jan 21, 2013 at 9:06 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> Yeah, thanks that makes the build process clear,
>
> What about the app development, debug from code to browser develop cycle?
>
> Like how do you envision the code being debugged, like how there is a
> Run/Debug and with breakpoints. This happens in the browser separate of the
> IDE? I have IntelliJ Ultimate, that is why I am asking about that in
> particular.
>
>
Yes, usually we debug directly in the browser.
See http://www.jangaroo.net/tutorial/debugging/
Works like this:
1. spot the class and line you want to debug in IDEA, where you can
easily naviagte & serach
2. switch to browser, enter JS debug tool
3. most JS debug tools allow typing the script file name to find it (IE
only takes the first character :-(). So type the class name (which is
exactly the script name). E.g. in Firebug, you click on "Script" tab, then
on second combo-box (first combo should be set to "static"), then start
typing.
4. Then use the JS debugger's "goto line" command. In Firebug, this is
#<line-number> in the script search box, in Chrome, this is Ctrl-G. Enter
the source code line, and the code in the generated JS will look strikingly
familiar :-)
5. Set breakpoint
6. When breakpoint is hit, the stack trace as well as the local
variables show readable names. Only private members have a $n suffix.
So this works really well once you got used to it.
Of course, what you'd really want would be to set the breakpoint directly
in the IDE. IDEA can remote-debug JavaScript in the browser, and you can
even easily map URLs to local files. So I tried to map the JavaScript URLs
to local *.as files. Didn't work, because you can only change the path, not
the file name (extension!), and IDEA's Flex support already "stole" the
breakpoints in AS code. So I hacked both IDEA's Flex support and the
JavaScript debugger and got it to run! I could set a breakpoint in AS code,
connect to the application running in the browser (IDEA supports only
Firefox and Chrome), and the breakpoint was hit and I could debug in IDEA!
However, I didn't publish the patched plugins, because I found them too
hard to maintain (create new patched version for every IDEA version...).
It was just a proof of concept that it would be very easy for IDEA to
support AS-JS-debugging directly in the IDE. So I guess it will be right
there for Apache Flex JS!
Have fun
-Frank- J8)
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Yeah, thanks that makes the build process clear,
What about the app development, debug from code to browser develop cycle?
Like how do you envision the code being debugged, like how there is a
Run/Debug and with breakpoints. This happens in the browser separate
of the IDE? I have IntelliJ Ultimate, that is why I am asking about
that in particular.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Yeah, sounds great, we can start that way and get a quick lift-off, but in
> the long term, I would certainly also like contribute code to FalconJx.
> So as agreed above, I'll continue on "my" Wiki page.
>
> Concerning the tool chain / IDE, here is how we work with ActionScript /
> Jangaroo at CoreMedia:
>
> - Use Maven 3 for the build process: Jangaroo provides a Maven plugin to
> invoke the compiler and build library modules and complete applications
> - Use IntelliJ IDEA Ultimate (Community does not support AS) as IDE: We
> also wrote an IDEA plugin that plugs into IDEA's Maven import process, so
> when you import the Jangaroo Maven project, you can start right off. Our
> IDEA plugin also allows incremental compile and thus fast turn-around.
> - From Maven, you can easily fire up Jetty or Tomcat to serve and test
> the resulting web application.
> - We run unit tests through old FlexUnit 0.9, either in browser (using
> Selenium) or in PhantomJS.
>
> So besides PhantomJS, it is a pure Java solution, all you need installed is
> Maven and IDEA with Jangaroo plugin, and Maven takes care of downloading
> everything else (Jangaroo Maven plugin, Jangaroo compiler, Jangaroo
> libraries, ...). Because everything is deployed to Maven Central, you do
> not even need any special setup to use Jangaroo from Maven, and can start
> with very light-weight POMs.
> More about this in our "quickstart" example project:
> https://github.com/CoreMedia/jangaroo-quickstart
>
> With Apache Flex/FalconJx ready, I hope that IDEA will do all this out of
> the box. You would just choose a new "Flash build configuration". Where
> currently you have "target platforms" Web (FlashPlayer plugin), mobile and
> desktop (both AIR flavors), there should be a new target "Web
> (JavaScript/HTML5)" (or the like). Flexmojos should take over the role of
> the Jangaroo Maven plugin.
>
> Hope this helps,
> -Frank- J8)
>
>
> On Mon, Jan 21, 2013 at 3:14 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>>
>> Great!
>>
>> Here is my thought Frank, I see no reason for you to even have to write
>> the AMD part. It dosn't make sense from a standpoint of time, when I get
>> some other things out of the way, if I have a good spec it would take me
>> less than a week with tests.
>>
>> This will allow you to focus on other things.
>>
>> BTW I wanted to ask, how does this now from your view fit into the "tool
>> chain" IE IDEs, how do you "work".
>>
>> Use IntelliJ for example. I'm curious because I have a WebAudio project I
>> am going to be starting and I want to know how I would hook the compiler up
>> to it's build system. Ideas?
>>
>>
>> Mike
>>
>>
>> Quoting Frank Wienberg <fr...@jangaroo.net>:
>>
>> On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle
>>> <ap...@teotigraphix.com>**wrote:
>>>
>>> Frank,
>>>>
>>>> Let me be direct, do you want to start working on AMD output?
>>>>
>>>>
>>> Not necessarily right now. Still seems like a steep learning curve for me.
>>>
>>>
>>> IMO you should definitely finish up the Wiki stuff so it clear what needs
>>>> to be done with AMD output.
>>>>
>>>>
>>> I was straightly asking what helps you most, so if you say let's get the
>>> specification finished first, I'll continue with that ASAP!
>>>
>>> Cheers
>>> -Frank- J8)
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Frank Wienberg <fr...@jangaroo.net>.
Yeah, sounds great, we can start that way and get a quick lift-off, but in
the long term, I would certainly also like contribute code to FalconJx.
So as agreed above, I'll continue on "my" Wiki page.
Concerning the tool chain / IDE, here is how we work with ActionScript /
Jangaroo at CoreMedia:
- Use Maven 3 for the build process: Jangaroo provides a Maven plugin to
invoke the compiler and build library modules and complete applications
- Use IntelliJ IDEA Ultimate (Community does not support AS) as IDE: We
also wrote an IDEA plugin that plugs into IDEA's Maven import process, so
when you import the Jangaroo Maven project, you can start right off. Our
IDEA plugin also allows incremental compile and thus fast turn-around.
- From Maven, you can easily fire up Jetty or Tomcat to serve and test
the resulting web application.
- We run unit tests through old FlexUnit 0.9, either in browser (using
Selenium) or in PhantomJS.
So besides PhantomJS, it is a pure Java solution, all you need installed is
Maven and IDEA with Jangaroo plugin, and Maven takes care of downloading
everything else (Jangaroo Maven plugin, Jangaroo compiler, Jangaroo
libraries, ...). Because everything is deployed to Maven Central, you do
not even need any special setup to use Jangaroo from Maven, and can start
with very light-weight POMs.
More about this in our "quickstart" example project:
https://github.com/CoreMedia/jangaroo-quickstart
With Apache Flex/FalconJx ready, I hope that IDEA will do all this out of
the box. You would just choose a new "Flash build configuration". Where
currently you have "target platforms" Web (FlashPlayer plugin), mobile and
desktop (both AIR flavors), there should be a new target "Web
(JavaScript/HTML5)" (or the like). Flexmojos should take over the role of
the Jangaroo Maven plugin.
Hope this helps,
-Frank- J8)
On Mon, Jan 21, 2013 at 3:14 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
>
> Great!
>
> Here is my thought Frank, I see no reason for you to even have to write
> the AMD part. It dosn't make sense from a standpoint of time, when I get
> some other things out of the way, if I have a good spec it would take me
> less than a week with tests.
>
> This will allow you to focus on other things.
>
> BTW I wanted to ask, how does this now from your view fit into the "tool
> chain" IE IDEs, how do you "work".
>
> Use IntelliJ for example. I'm curious because I have a WebAudio project I
> am going to be starting and I want to know how I would hook the compiler up
> to it's build system. Ideas?
>
>
> Mike
>
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
> On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle
>> <ap...@teotigraphix.com>**wrote:
>>
>> Frank,
>>>
>>> Let me be direct, do you want to start working on AMD output?
>>>
>>>
>> Not necessarily right now. Still seems like a steep learning curve for me.
>>
>>
>> IMO you should definitely finish up the Wiki stuff so it clear what needs
>>> to be done with AMD output.
>>>
>>>
>> I was straightly asking what helps you most, so if you say let's get the
>> specification finished first, I'll continue with that ASAP!
>>
>> Cheers
>> -Frank- J8)
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Great!
Here is my thought Frank, I see no reason for you to even have to
write the AMD part. It dosn't make sense from a standpoint of time,
when I get some other things out of the way, if I have a good spec it
would take me less than a week with tests.
This will allow you to focus on other things.
BTW I wanted to ask, how does this now from your view fit into the
"tool chain" IE IDEs, how do you "work".
Use IntelliJ for example. I'm curious because I have a WebAudio
project I am going to be starting and I want to know how I would hook
the compiler up to it's build system. Ideas?
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> Frank,
>>
>> Let me be direct, do you want to start working on AMD output?
>>
>
> Not necessarily right now. Still seems like a steep learning curve for me.
>
>
>> IMO you should definitely finish up the Wiki stuff so it clear what needs
>> to be done with AMD output.
>>
>
> I was straightly asking what helps you most, so if you say let's get the
> specification finished first, I'll continue with that ASAP!
>
> Cheers
> -Frank- J8)
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> Frank,
>
> Let me be direct, do you want to start working on AMD output?
>
Not necessarily right now. Still seems like a steep learning curve for me.
> IMO you should definitely finish up the Wiki stuff so it clear what needs
> to be done with AMD output.
>
I was straightly asking what helps you most, so if you say let's get the
specification finished first, I'll continue with that ASAP!
Cheers
-Frank- J8)
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Frank,
Let me be direct, do you want to start working on AMD output?
IMO you should definitely finish up the Wiki stuff so it clear what
needs to be done with AMD output.
Your MXML interpretation is the way I would see it as well. It's
crystallized until invoked. That is what I meant by intention, it's
not a true class template until it has been deserialized by the
compiler.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Sun, Jan 20, 2013 at 11:28 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> I think what my plan is, is to tell you I'm not going to ignore you, I'm
>> focused on MXML just so I can get it into the flow. After I get it
>> committed I will try and see what is going on with the code you wrote.
>>
>
> Totally fine. While you are busy with MXML, I could spend my time getting
> started with FalconJx and/or finishing the AS->JS Wiki page.
>
> I am also pretty sure there are some others out there that may want to help
>> out on something but the documentation on what we are doing is a but
>> technical.
>>
>> Alex brought up a good point about the MXML and needing it soon, if I
>> don't do it right now before we get head long into the finite part of the
>> compiler, I'm going to end up resenting working on it. :)
>>
>> Actually, working on it today really gives me a sense of anticipation
>> because MXML is one thing we have in our favor that could end up being
>> something that can set this project apart and really allow for some
>> interesting types of innovation. Who knows, we will keep that for the
>> future.
>>
>
> Yes, MXML is something all languages-that-compile-to-JavaScript competitors
> (TypeScript, Dart, Haxe, ...) currently lack!
>
>
>>
>> Along those lines, for now I don't see MXML as really a "class" one to
>> one. It's more of and "intentional declaration of intent". Does that phrase
>> make sense to you?
>>
>
> I guess you're talking about what I'd call an "object descriptor", like
> ECMAScript 5 has the concept of "property descriptor" that is not the
> actual property, but a descriptor to create a property. A class is
> something quite similar to an object descriptor (because you have to
> instantiate it to get an actual object). If I understand your point
> correctly, MXML cannot create arbitrary classes (well, I guess it can
> through <mx:Script> elements, but that's kind of dirty), but limits itself
> to the declarative part, i.e. defining properties and instantiating and
> wiring other objects through their properties. Right?
> Another way to view MXML is as an "object serialization" format. Although
> MXML is not used to store objects, serialization also focuses on object
> properties, not their methods / behavior. Behavior is added (through
> classes) on deserialization.
>
> -Frank- J8)
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sun, Jan 20, 2013 at 11:28 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> I think what my plan is, is to tell you I'm not going to ignore you, I'm
> focused on MXML just so I can get it into the flow. After I get it
> committed I will try and see what is going on with the code you wrote.
>
Totally fine. While you are busy with MXML, I could spend my time getting
started with FalconJx and/or finishing the AS->JS Wiki page.
I am also pretty sure there are some others out there that may want to help
> out on something but the documentation on what we are doing is a but
> technical.
>
> Alex brought up a good point about the MXML and needing it soon, if I
> don't do it right now before we get head long into the finite part of the
> compiler, I'm going to end up resenting working on it. :)
>
> Actually, working on it today really gives me a sense of anticipation
> because MXML is one thing we have in our favor that could end up being
> something that can set this project apart and really allow for some
> interesting types of innovation. Who knows, we will keep that for the
> future.
>
Yes, MXML is something all languages-that-compile-to-JavaScript competitors
(TypeScript, Dart, Haxe, ...) currently lack!
>
> Along those lines, for now I don't see MXML as really a "class" one to
> one. It's more of and "intentional declaration of intent". Does that phrase
> make sense to you?
>
I guess you're talking about what I'd call an "object descriptor", like
ECMAScript 5 has the concept of "property descriptor" that is not the
actual property, but a descriptor to create a property. A class is
something quite similar to an object descriptor (because you have to
instantiate it to get an actual object). If I understand your point
correctly, MXML cannot create arbitrary classes (well, I guess it can
through <mx:Script> elements, but that's kind of dirty), but limits itself
to the declarative part, i.e. defining properties and instantiating and
wiring other objects through their properties. Right?
Another way to view MXML is as an "object serialization" format. Although
MXML is not used to store objects, serialization also focuses on object
properties, not their methods / behavior. Behavior is added (through
classes) on deserialization.
-Frank- J8)
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ok,
I read through everything. I'm a bit under the weather right now with
my head, my family laughs and says I should be relaxing, yeah spending
all day figuring out MXML emitter is my cold medicine. :)
I think what my plan is, is to tell you I'm not going to ignore you,
I'm focused on MXML just so I can get it into the flow. After I get it
committed I will try and see what is going on with the code you wrote.
I am also pretty sure there are some others out there that may want to
help out on something but the documentation on what we are doing is a
but technical.
Alex brought up a good point about the MXML and needing it soon, if I
don't do it right now before we get head long into the finite part of
the compiler, I'm going to end up resenting working on it. :)
Actually, working on it today really gives me a sense of anticipation
because MXML is one thing we have in our favor that could end up being
something that can set this project apart and really allow for some
interesting types of innovation. Who knows, we will keep that for the
future.
Along those lines, for now I don't see MXML as really a "class" one to
one. It's more of and "intentional declaration of intent". Does that
phrase make sense to you?
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi Michael, hi Erik,
>
> On Sun, Jan 20, 2013 at 12:16 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> As Erik has said, he made a stub for this already and we can start
>> writting it once I actually understand somethings.
>>
>> One thing I need to get clear, are you asking the output to be like
>> Jangaroo where it prints it out like AS source code "Semantically" with
>> line numbers etc? Or are you asking to get the output correct only.
>>
>> I know you have an an opinion about how things get debugged, so just
>> trying to get this clear from the beginning.
>>
>
> Again sorry for the long post, the answer in hidden somewhere in the
> "middle part":
>> This is a special Jangaroo feature which we do not necessarily need to
> implement for FalconJx.
>> However, I still think it is a good feature, and since it does not slow
> down the optimized version,
>> why not implement it for FalconJx, too?
>
> So no, it is not my primary goal that Flex / FalconJx supports this
> feature, I consider it nice-to-have.
> A must-have is that JS files can be loaded one-by-one in debug mode and
> linked into one or a few minified file(s) for production. This is not only
> for debugging, but also for fast development turn-around, as linking /
> minifying would otherwise be needed for each turn-around. And I still think
> this is best achieved using AMD / RequireJS.
>
> To keep Jangaroo's 1:1 line mapping, I introduce named functions and assign
> them to the right slot in the "Jangaroo part" at the end of the JS file.
> So what we would do for FalconJx (at least as the first iteration) is to
> "inline" the named function into the "Jangaroo part" class definition,
> resulting in what I suggested in the "as-js-runtime-prototype" git project.
> The reason I implemented this for Jangaroo 3 is that, given its code base,
> it was actually easier to keep the 1:1 line mapping.
> The whole point of my current work is to show that AMD-based JavaScript
> code generation is a) not only an idea expressed in a prototype, but an
> actual solution that can handle complex ActionScript applications like Open
> Flash Chart efficiently, and b) there is a migration path from Jangaroo 1 /
> 2 to AMD-based JS output, so that Jangaroo projects can be mirgrated to
> Apache Flex / Falcon Jx sometime in the future.
>
>
>> I don't know if "port" is the right word here. I think implement is more
>> like it. Since the AST and parser API is like black and white between
>> Jangaroo and the Falcon parsers, there is no way there is any translation
>> other then some patterns you might use on leaf expressions to do fancy
>> things to create the javascript. Trust me, I have looked and studied your
>> code. :)
>>
>
> You are totally right, "port" is the wrong word. We'll need to re-implement
> the solution for Falcon. Because of the detailed solution outline (my
> Jangaroo blog posts, as-js-runtime-prototype, my unfinished Wiki page), it
> took me just a couple of days with the code base I know very well, I am
> sure you two could get it re-implemented with FalconJx very quickly, too!
> And as said, I am now in a position where I could (with some community
> help) also start working on FalconJx code.
>
>
>>
>> The rest of this post is WAY over my head right now. You have to
>> understand Frank, you are on an implementation level of JavaScript and I am
>> working in the "engine" room right now that is dirty and loud. ;-)
>>
>
> Then I hope you got your noise protection on! Well, I thought it would help
> if you can try out things with a "reference implementation". If checking
> out and building the "jangaroo-3" branch sounds like a lot of work, let me
> tell you it isn't if you have git and Maven installed (detailed
> instructions in my original post). To make it even easier to use, I could
> deploy a Jangaroo 3 pre-release to Maven central, so that you could compile
> AS to JS without the need to build jangaroo-tools locally. Would that help?
> Or should I rather complete the "AS language features..." Wiki page?
> Whatever helps you more.
>
>
>>
>> Once I get MXML going and this compiler can create Alex's prototype
>> project just like FalconJS is, then I can step back take a deep breath and
>> focus on this stuff.
>>
>> Does that make sense?
>>
>>
> Perfectly!
>
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi Michael, hi Erik,
On Sun, Jan 20, 2013 at 12:16 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> As Erik has said, he made a stub for this already and we can start
> writting it once I actually understand somethings.
>
> One thing I need to get clear, are you asking the output to be like
> Jangaroo where it prints it out like AS source code "Semantically" with
> line numbers etc? Or are you asking to get the output correct only.
>
> I know you have an an opinion about how things get debugged, so just
> trying to get this clear from the beginning.
>
Again sorry for the long post, the answer in hidden somewhere in the
"middle part":
> This is a special Jangaroo feature which we do not necessarily need to
implement for FalconJx.
> However, I still think it is a good feature, and since it does not slow
down the optimized version,
> why not implement it for FalconJx, too?
So no, it is not my primary goal that Flex / FalconJx supports this
feature, I consider it nice-to-have.
A must-have is that JS files can be loaded one-by-one in debug mode and
linked into one or a few minified file(s) for production. This is not only
for debugging, but also for fast development turn-around, as linking /
minifying would otherwise be needed for each turn-around. And I still think
this is best achieved using AMD / RequireJS.
To keep Jangaroo's 1:1 line mapping, I introduce named functions and assign
them to the right slot in the "Jangaroo part" at the end of the JS file.
So what we would do for FalconJx (at least as the first iteration) is to
"inline" the named function into the "Jangaroo part" class definition,
resulting in what I suggested in the "as-js-runtime-prototype" git project.
The reason I implemented this for Jangaroo 3 is that, given its code base,
it was actually easier to keep the 1:1 line mapping.
The whole point of my current work is to show that AMD-based JavaScript
code generation is a) not only an idea expressed in a prototype, but an
actual solution that can handle complex ActionScript applications like Open
Flash Chart efficiently, and b) there is a migration path from Jangaroo 1 /
2 to AMD-based JS output, so that Jangaroo projects can be mirgrated to
Apache Flex / Falcon Jx sometime in the future.
> I don't know if "port" is the right word here. I think implement is more
> like it. Since the AST and parser API is like black and white between
> Jangaroo and the Falcon parsers, there is no way there is any translation
> other then some patterns you might use on leaf expressions to do fancy
> things to create the javascript. Trust me, I have looked and studied your
> code. :)
>
You are totally right, "port" is the wrong word. We'll need to re-implement
the solution for Falcon. Because of the detailed solution outline (my
Jangaroo blog posts, as-js-runtime-prototype, my unfinished Wiki page), it
took me just a couple of days with the code base I know very well, I am
sure you two could get it re-implemented with FalconJx very quickly, too!
And as said, I am now in a position where I could (with some community
help) also start working on FalconJx code.
>
> The rest of this post is WAY over my head right now. You have to
> understand Frank, you are on an implementation level of JavaScript and I am
> working in the "engine" room right now that is dirty and loud. ;-)
>
Then I hope you got your noise protection on! Well, I thought it would help
if you can try out things with a "reference implementation". If checking
out and building the "jangaroo-3" branch sounds like a lot of work, let me
tell you it isn't if you have git and Maven installed (detailed
instructions in my original post). To make it even easier to use, I could
deploy a Jangaroo 3 pre-release to Maven central, so that you could compile
AS to JS without the need to build jangaroo-tools locally. Would that help?
Or should I rather complete the "AS language features..." Wiki page?
Whatever helps you more.
>
> Once I get MXML going and this compiler can create Alex's prototype
> project just like FalconJS is, then I can step back take a deep breath and
> focus on this stuff.
>
> Does that make sense?
>
>
Perfectly!
-Frank-
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi folks,
>
> I have been rather quiet for a while, but that's because I have been busy
> implementing JavaScript code generation according to the Runtime prototype
> I posted some weeks ago. However, I started off implementing this in the
> Jangaroo compiler, not in Falcon. I am far quicker implementing this in the
> context I know, it would have taken me much longer getting started with
> Falcon first. So of course now I hope that you guys help me porting this
> solution to FalconJx...
As Erik has said, he made a stub for this already and we can start
writting it once I actually understand somethings.
One thing I need to get clear, are you asking the output to be like
Jangaroo where it prints it out like AS source code "Semantically"
with line numbers etc? Or are you asking to get the output correct only.
I know you have an an opinion about how things get debugged, so just
trying to get this clear from the beginning.
I don't know if "port" is the right word here. I think implement is
more like it. Since the AST and parser API is like black and white
between Jangaroo and the Falcon parsers, there is no way there is any
translation other then some patterns you might use on leaf expressions
to do fancy things to create the javascript. Trust me, I have looked
and studied your code. :)
The rest of this post is WAY over my head right now. You have to
understand Frank, you are on an implementation level of JavaScript and
I am working in the "engine" room right now that is dirty and loud. ;-)
Once I get MXML going and this compiler can create Alex's prototype
project just like FalconJS is, then I can step back take a deep breath
and focus on this stuff.
Does that make sense?
Mike
> I'm about 80% finished implementing all the AS3 language features I started
> documenting in the Flex Wiki and already have a demo of a large
> application, namely the Open Flash Charts demo, recompiled with the new AMD
> approach.
>
> Background on the demo:
> Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure
> ActionScript 3
> project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/Version%202%20Lug%20Wyrm%20Charmer/>,
> and I only had to make very few changes to the original AS3 code to make
> the JavaScript version generated by the Jangaroo compiler work in the
> browser, without a Flash plugin. This has been working with Jangaroo 1 and
> 2, and now I got it to run with the new runtime format proposed for
> FalconJx.
>
> The demo comes in two flavors:
> The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
> where the whole application is a minified single JS file of about 380 kb
> (unzipped, the original SWF has 320 kb, and that is zipped and of course
> does not contain the Flash classes, because they come with the
> FlashPlayer!):
> *http://jangaron.net/ofc5/data-files/joo.html*
> Or load the "debug"
> version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
> where the JS equivalent of every AS class is loaded as a single request,
> simply by adding hash joo.debug to the URL:
> *http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
>
> This demonstrates the real benefit of the AMD approach: RequireJS is
> capable of loading all needed scripts one by one (debug mode) as well as
> optimize them into a single JS file for production. It can use Uglify,
> Uglify2 or Google Closure for minification.
> Loading every AS class as a single request is still astonishingly fast,
> especially when using local deployment, which is what you usually do for
> debugging. Note that the demo uses over 200 classes.
>
> Have a look at the generated JavaScript, and you'll see that Jangaroo keeps
> the original ActionScript code either as comment (if there is no JavaScript
> counterpart, like for "package", "class", type annotations), or as
> executable code in the exact line where the original AS code was. That
> means if you want to debug say line 20 of AS class "Foo", you open script
> "Foo.js" in the JavaScript debugger and find the code and set the
> breakpoint in that same line: 20. This is a special Jangaroo feature which
> we do not necessarily need to implement for FalconJx. However, I still
> think it is a good feature, and since it does not slow down the optimized
> version, why not implement it for FalconJx, too?
>
> What I think we do need in any case is the ability to load AS classes by
> single requests, as otherwise they are really hard to find when debugging
> in the browser. And this is what you get for free when using RequireJS. In
> Alex' prototype, the only way to achieve this behavior was to list all
> needed single class scripts in the HTML (see FlexJS Wiki page). Of course,
> such HTML could be generated, but I think RequireJS' approach is more
> elegant.
>
> Another thing you can see in the Open Flash Chart demo is how I implemented
> static code execution. ActionScript executes all static code of the whole
> "compilation unit" the first time its "primary declaration" (usually a
> class) is accessed.
> Consequently, not (only) an ActionScript class, but an ActionScript
> "compilation unit" is put into a JavaScript AMD module definition. Thus,
> the module's value is not the class itself, but a compilation unit
> containing the class. I use the property "_" for the class or any other
> primary declaration, which in AS3 can also be a function, variable or
> constant. The static code of the compilation unit is *not* executed when it
> is *loaded*, but when the "_" property is *accessed* for the first time.
> (Because code has to be loaded asynchronously in the browser, we cannot
> load the module when it is accessed synchronously, but have to load all
> static dependencies in advance.) This is equivalent to the original AS3
> behavior, and only introduces the minimal overhead of accessing Foo._
> instead of just Foo.
>
> If you want to play with the new Jangaroo compiler to see what JavaScript
> output is generated for your ActionScript input, the simplest way is as
> follows.
>
> You need to have Java, Git and Maven installed and properly set up.
>
> Clone the jangaroo-tools repository and switch to branch jangaroo-3:
>
>> git clone git://github.com/CoreMedia/jangaroo-tools.git
>
>> git checkout jangaroo-3
>
> Then run the integration tests via Maven:
>
>> cd jangaroo-tools
>
>> mvn install -pl :jangaroo-compiler-itests -am
>
> This should result in a BUILD SUCCESS.
>
> The jangaroo-compiler-itests module is under
> jangaroo/jangaroo-compiler-itests:
>
>> cd jangaroo/jangaroo-compiler-itests
>
> For the intergration tests, all *.as files under src/test/joo/ are compiled
> to target/temp/joo/classes/, respecting their package sub-directory. So if
> you add an *.as file under the src/test/joo/ directory, the corresponding
> *.js file will appear under the target/temp/joo/classes/ directory after
> the following Maven command:
>
>> mvn test-compile
>
> Note that you cannot use Flash API here (will result in compile error, as
> classes are not found), only basic classes like String, Array, and built-in
> functions like trace().
>
> Another good news is that my employer signed the CCLA, and it has been
> confirmed by Craig, so now I am all set to contribute Jangaroo code to
> Apache Flex!
>
> The code that generates the new JavaScript runtime format is in
> jangaroo-tools
> on the "jangaroo-3"
> branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
> (see
> above), especially class
> JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java>(Michael
> Sch. knows this already!) is interesting for porting code to
> FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
>
> I am also working on another demo, which is written in AS3 and MXML (!),
> but instead of Flex components, uses "native" Ext JS JavaScript components
> through an AS API. It does not use the Jangaroo Flash library
> re-implementation (JooFlash), so this sounds similar to Alex' approach to
> not use the display list to render MXML components. More update on this to
> follow.
>
> Would really be great if we could consolidate our solutions!
>
> Can't wait for your feedback,
>
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Harbs <ha...@gmail.com>.
I think you missed part of his long message… ;-)
> Another good news is that my employer signed the CCLA, and it has been
> confirmed by Craig, so now I am all set to contribute Jangaroo code to
> Apache Flex!
On Jan 20, 2013, at 6:35 AM, Alex Harui wrote:
> Hi Frank,
>
> I won't be able to look at this for at least a couple of days.
>
> BTW, how's it going with the ICLA/CCLA? Or did I miss seeing the
> notification for it?
>
> -Alex
>
>
> On 1/19/13 1:08 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>
>> Hi folks,
>>
>> I have been rather quiet for a while, but that's because I have been busy
>> implementing JavaScript code generation according to the Runtime prototype
>> I posted some weeks ago. However, I started off implementing this in the
>> Jangaroo compiler, not in Falcon. I am far quicker implementing this in the
>> context I know, it would have taken me much longer getting started with
>> Falcon first. So of course now I hope that you guys help me porting this
>> solution to FalconJx...
>>
>> I'm about 80% finished implementing all the AS3 language features I started
>> documenting in the Flex Wiki and already have a demo of a large
>> application, namely the Open Flash Charts demo, recompiled with the new AMD
>> approach.
>>
>> Background on the demo:
>> Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure
>> ActionScript 3
>> project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/
>> Version%202%20Lug%20Wyrm%20Charmer/>,
>> and I only had to make very few changes to the original AS3 code to make
>> the JavaScript version generated by the Jangaroo compiler work in the
>> browser, without a Flash plugin. This has been working with Jangaroo 1 and
>> 2, and now I got it to run with the new runtime format proposed for
>> FalconJx.
>>
>> The demo comes in two flavors:
>> The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
>> where the whole application is a minified single JS file of about 380 kb
>> (unzipped, the original SWF has 320 kb, and that is zipped and of course
>> does not contain the Flash classes, because they come with the
>> FlashPlayer!):
>> *http://jangaron.net/ofc5/data-files/joo.html*
>> Or load the "debug"
>> version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
>> where the JS equivalent of every AS class is loaded as a single request,
>> simply by adding hash joo.debug to the URL:
>> *http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
>>
>> This demonstrates the real benefit of the AMD approach: RequireJS is
>> capable of loading all needed scripts one by one (debug mode) as well as
>> optimize them into a single JS file for production. It can use Uglify,
>> Uglify2 or Google Closure for minification.
>> Loading every AS class as a single request is still astonishingly fast,
>> especially when using local deployment, which is what you usually do for
>> debugging. Note that the demo uses over 200 classes.
>>
>> Have a look at the generated JavaScript, and you'll see that Jangaroo keeps
>> the original ActionScript code either as comment (if there is no JavaScript
>> counterpart, like for "package", "class", type annotations), or as
>> executable code in the exact line where the original AS code was. That
>> means if you want to debug say line 20 of AS class "Foo", you open script
>> "Foo.js" in the JavaScript debugger and find the code and set the
>> breakpoint in that same line: 20. This is a special Jangaroo feature which
>> we do not necessarily need to implement for FalconJx. However, I still
>> think it is a good feature, and since it does not slow down the optimized
>> version, why not implement it for FalconJx, too?
>>
>> What I think we do need in any case is the ability to load AS classes by
>> single requests, as otherwise they are really hard to find when debugging
>> in the browser. And this is what you get for free when using RequireJS. In
>> Alex' prototype, the only way to achieve this behavior was to list all
>> needed single class scripts in the HTML (see FlexJS Wiki page). Of course,
>> such HTML could be generated, but I think RequireJS' approach is more
>> elegant.
>>
>> Another thing you can see in the Open Flash Chart demo is how I implemented
>> static code execution. ActionScript executes all static code of the whole
>> "compilation unit" the first time its "primary declaration" (usually a
>> class) is accessed.
>> Consequently, not (only) an ActionScript class, but an ActionScript
>> "compilation unit" is put into a JavaScript AMD module definition. Thus,
>> the module's value is not the class itself, but a compilation unit
>> containing the class. I use the property "_" for the class or any other
>> primary declaration, which in AS3 can also be a function, variable or
>> constant. The static code of the compilation unit is *not* executed when it
>> is *loaded*, but when the "_" property is *accessed* for the first time.
>> (Because code has to be loaded asynchronously in the browser, we cannot
>> load the module when it is accessed synchronously, but have to load all
>> static dependencies in advance.) This is equivalent to the original AS3
>> behavior, and only introduces the minimal overhead of accessing Foo._
>> instead of just Foo.
>>
>> If you want to play with the new Jangaroo compiler to see what JavaScript
>> output is generated for your ActionScript input, the simplest way is as
>> follows.
>>
>> You need to have Java, Git and Maven installed and properly set up.
>>
>> Clone the jangaroo-tools repository and switch to branch jangaroo-3:
>>
>>> git clone git://github.com/CoreMedia/jangaroo-tools.git
>>
>>> git checkout jangaroo-3
>>
>> Then run the integration tests via Maven:
>>
>>> cd jangaroo-tools
>>
>>> mvn install -pl :jangaroo-compiler-itests -am
>>
>> This should result in a BUILD SUCCESS.
>>
>> The jangaroo-compiler-itests module is under
>> jangaroo/jangaroo-compiler-itests:
>>
>>> cd jangaroo/jangaroo-compiler-itests
>>
>> For the intergration tests, all *.as files under src/test/joo/ are compiled
>> to target/temp/joo/classes/, respecting their package sub-directory. So if
>> you add an *.as file under the src/test/joo/ directory, the corresponding
>> *.js file will appear under the target/temp/joo/classes/ directory after
>> the following Maven command:
>>
>>> mvn test-compile
>>
>> Note that you cannot use Flash API here (will result in compile error, as
>> classes are not found), only basic classes like String, Array, and built-in
>> functions like trace().
>>
>> Another good news is that my employer signed the CCLA, and it has been
>> confirmed by Craig, so now I am all set to contribute Jangaroo code to
>> Apache Flex!
>>
>> The code that generates the new JavaScript runtime format is in jangaroo-tools
>> on the "jangaroo-3"
>> branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
>> (see
>> above), especially class
>> JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/ja
>> ngaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerat
>> or.java>(Michael
>> Sch. knows this already!) is interesting for porting code to
>> FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
>>
>> I am also working on another demo, which is written in AS3 and MXML (!),
>> but instead of Flex components, uses "native" Ext JS JavaScript components
>> through an AS API. It does not use the Jangaroo Flash library
>> re-implementation (JooFlash), so this sounds similar to Alex' approach to
>> not use the display list to render MXML components. More update on this to
>> follow.
>>
>> Would really be great if we could consolidate our solutions!
>>
>> Can't wait for your feedback,
>>
>> -Frank-
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Posted by Alex Harui <ah...@adobe.com>.
Hi Frank,
I won't be able to look at this for at least a couple of days.
BTW, how's it going with the ICLA/CCLA? Or did I miss seeing the
notification for it?
-Alex
On 1/19/13 1:08 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> Hi folks,
>
> I have been rather quiet for a while, but that's because I have been busy
> implementing JavaScript code generation according to the Runtime prototype
> I posted some weeks ago. However, I started off implementing this in the
> Jangaroo compiler, not in Falcon. I am far quicker implementing this in the
> context I know, it would have taken me much longer getting started with
> Falcon first. So of course now I hope that you guys help me porting this
> solution to FalconJx...
>
> I'm about 80% finished implementing all the AS3 language features I started
> documenting in the Flex Wiki and already have a demo of a large
> application, namely the Open Flash Charts demo, recompiled with the new AMD
> approach.
>
> Background on the demo:
> Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure
> ActionScript 3
> project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/
> Version%202%20Lug%20Wyrm%20Charmer/>,
> and I only had to make very few changes to the original AS3 code to make
> the JavaScript version generated by the Jangaroo compiler work in the
> browser, without a Flash plugin. This has been working with Jangaroo 1 and
> 2, and now I got it to run with the new runtime format proposed for
> FalconJx.
>
> The demo comes in two flavors:
> The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
> where the whole application is a minified single JS file of about 380 kb
> (unzipped, the original SWF has 320 kb, and that is zipped and of course
> does not contain the Flash classes, because they come with the
> FlashPlayer!):
> *http://jangaron.net/ofc5/data-files/joo.html*
> Or load the "debug"
> version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
> where the JS equivalent of every AS class is loaded as a single request,
> simply by adding hash joo.debug to the URL:
> *http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
>
> This demonstrates the real benefit of the AMD approach: RequireJS is
> capable of loading all needed scripts one by one (debug mode) as well as
> optimize them into a single JS file for production. It can use Uglify,
> Uglify2 or Google Closure for minification.
> Loading every AS class as a single request is still astonishingly fast,
> especially when using local deployment, which is what you usually do for
> debugging. Note that the demo uses over 200 classes.
>
> Have a look at the generated JavaScript, and you'll see that Jangaroo keeps
> the original ActionScript code either as comment (if there is no JavaScript
> counterpart, like for "package", "class", type annotations), or as
> executable code in the exact line where the original AS code was. That
> means if you want to debug say line 20 of AS class "Foo", you open script
> "Foo.js" in the JavaScript debugger and find the code and set the
> breakpoint in that same line: 20. This is a special Jangaroo feature which
> we do not necessarily need to implement for FalconJx. However, I still
> think it is a good feature, and since it does not slow down the optimized
> version, why not implement it for FalconJx, too?
>
> What I think we do need in any case is the ability to load AS classes by
> single requests, as otherwise they are really hard to find when debugging
> in the browser. And this is what you get for free when using RequireJS. In
> Alex' prototype, the only way to achieve this behavior was to list all
> needed single class scripts in the HTML (see FlexJS Wiki page). Of course,
> such HTML could be generated, but I think RequireJS' approach is more
> elegant.
>
> Another thing you can see in the Open Flash Chart demo is how I implemented
> static code execution. ActionScript executes all static code of the whole
> "compilation unit" the first time its "primary declaration" (usually a
> class) is accessed.
> Consequently, not (only) an ActionScript class, but an ActionScript
> "compilation unit" is put into a JavaScript AMD module definition. Thus,
> the module's value is not the class itself, but a compilation unit
> containing the class. I use the property "_" for the class or any other
> primary declaration, which in AS3 can also be a function, variable or
> constant. The static code of the compilation unit is *not* executed when it
> is *loaded*, but when the "_" property is *accessed* for the first time.
> (Because code has to be loaded asynchronously in the browser, we cannot
> load the module when it is accessed synchronously, but have to load all
> static dependencies in advance.) This is equivalent to the original AS3
> behavior, and only introduces the minimal overhead of accessing Foo._
> instead of just Foo.
>
> If you want to play with the new Jangaroo compiler to see what JavaScript
> output is generated for your ActionScript input, the simplest way is as
> follows.
>
> You need to have Java, Git and Maven installed and properly set up.
>
> Clone the jangaroo-tools repository and switch to branch jangaroo-3:
>
>> git clone git://github.com/CoreMedia/jangaroo-tools.git
>
>> git checkout jangaroo-3
>
> Then run the integration tests via Maven:
>
>> cd jangaroo-tools
>
>> mvn install -pl :jangaroo-compiler-itests -am
>
> This should result in a BUILD SUCCESS.
>
> The jangaroo-compiler-itests module is under
> jangaroo/jangaroo-compiler-itests:
>
>> cd jangaroo/jangaroo-compiler-itests
>
> For the intergration tests, all *.as files under src/test/joo/ are compiled
> to target/temp/joo/classes/, respecting their package sub-directory. So if
> you add an *.as file under the src/test/joo/ directory, the corresponding
> *.js file will appear under the target/temp/joo/classes/ directory after
> the following Maven command:
>
>> mvn test-compile
>
> Note that you cannot use Flash API here (will result in compile error, as
> classes are not found), only basic classes like String, Array, and built-in
> functions like trace().
>
> Another good news is that my employer signed the CCLA, and it has been
> confirmed by Craig, so now I am all set to contribute Jangaroo code to
> Apache Flex!
>
> The code that generates the new JavaScript runtime format is in jangaroo-tools
> on the "jangaroo-3"
> branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
> (see
> above), especially class
> JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/ja
> ngaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerat
> or.java>(Michael
> Sch. knows this already!) is interesting for porting code to
> FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
>
> I am also working on another demo, which is written in AS3 and MXML (!),
> but instead of Flex components, uses "native" Ext JS JavaScript components
> through an AS API. It does not use the Jangaroo Flash library
> re-implementation (JooFlash), so this sounds similar to Alex' approach to
> not use the display list to render MXML components. More update on this to
> follow.
>
> Would really be great if we could consolidate our solutions!
>
> Can't wait for your feedback,
>
> -Frank-
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui