You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <ap...@teotigraphix.com> on 2013/02/06 00:08:06 UTC
[FalconJx] AMD source production update
Hi,
I'm currently working on Frank's version of the AMD emitter. Now that
he has got his source code updated in the GIT project, I had some
things to go off of.
Currently I have the following being produced for his class A. There
are a lot of edge cases and other things to be ironed out but, it
looks like the heavy lifting was done back when this framework was
written. ;-)
I'm happy with the success of simplicity outputting multiple
JavaScript targets. Who knows, we could see another target eventually,
we can have options.
I have about 1/3 more to go to get this output looking verbatim of
that in his Jangaroo production.
define(["exports", "AS3"], function($exports, AS3) {
"use strict";
AS3.compilationUnit($exports, function($primaryDeclaration){
function A(msg) {
this.msg = msg;
}
$primaryDeclaration(AS3.class_({
package_: "com.acme",
class_: "A",
members: {
constructor: A,
_msg$1:{
value:0,
writable:true
},
msg:{
get: function msg$get() {
return String(this._msg$1);
},
set: function msg$set(value) {
this._msg$1 = parseInt(value, 10);
}
},
secret$1:function secret(n) {
return msg + n;
},
foo:function foo(x) {
return this.secret(A.bar(x));
},
baz:function baz() {
var tmp = this.secret;
return tmp("-bound");
}
}
}));
});
});
Looks like we will have two prototype emitters working decently by the
end of the week.
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD source production update
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi Mike,
I've been hacking away at CoreMedia's Hackathon today, so sorry for the
late response.
On Thu, Feb 7, 2013 at 1:17 PM, Michael Schmalle <ap...@teotigraphix.com>wrote:
> - What do you do with the !native stuff? I have those being tracked now
> based on an enum I made from your repo
>
> - Where is your 'toplevel' list that is being included right now? IE trace
> and what else?
>
These two questions are connected. I provide the compiler with an
ActionScript API of those built-in classes,
which can be found
here<https://github.com/CoreMedia/jangaroo-tools/tree/jangaroo-3/jangaroo/jangaroo-runtime/src/main/joo>
(general
classes/functions/objects) and
here<https://github.com/CoreMedia/jangaroo-libs/tree/jangaroo-3/jangaroo-browser/src/main/joo>(browser
classes/functions/objects).
All classes/functions/objects are annotated as [Native], which means that
the compiler should not generate
any JavaScript code for them, *but* it has an effect on what code is
generated from a "real" ActionScript class
that uses this [Native] class. So when an AS3 class references a class that
the compiler parses and notices
it is [Native], it generates a different require-reference to it, according
to the rules I gave in a previous mail in
this thread (or the other thread?).
The "native!" RequireJS plugin takes care of retrieving JavaScript global
objects, and, in case the
browser does not support them (mostly IE8), load a "polyfill" script. The
summary of how to map [Native]
annotations to require-references is:
- package bar [Native] class Foo -- "native!bar.Foo"
- package bar [Native(global="baz.Faz")] class Foo -- "native!baz.Faz"
- package bar [Native(amd)] class Foo -- "classes/bar/Foo"
- package bar [Native(amd="baz/Foo")] class Foo -- "baz/Foo"
- package bar [Native(amd="baz/Foo", global="baz.Faz")] class Foo --
"native!baz.Faz@baz/Foo"
In any case, the resulting variable must *not* be de-referenced like AS3
compilation units, so no (Foo._ || Foo._$get()).
The rules behind this are:
- if there is no "amd" and no "global" attribute, the JavaScript object
has the same fully qualified name as the ActionScript API and must be
provided by the environment.
- if there is a "global" parameter, use this as the fully qualified name
of the JavaScript object (alias).
- if there is an "amd" parameter and no "global" parameter, always load
the given AMD module when this ActionScript API is required (in this case,
[Native] just means "do not de-reference, its the class, not a compilation
unit!").
- if there is an "amd" parameter *and* a "global" parameter, try to
retrieve the global JavaScript object and only load the AMD module if the
JavaScript object is not defined. The module must take care of defining the
global JavaScript object, so the second try after loading the module
succeeds.
Thus the [Native] annotation can be used to declare ActionScript API for
- built-in global JavaScript objects
- JavaScript objects that are present in some environments but may have
to be "polyfilled" by loading a script
- global JavaScript objects defined by some JavaScript library
If you think naming the attribute "script" instead of "amd", let me know. I
just thought that we could
The idea of the "native!" RequireJS plugin is that it is the most
consequent way to avoid references to global,
namespaced JavaScript objects throughout the code, which allows short local
variable names (just "TextField"
instead of "Ext.form.TextField") which can even be further shortened by the
JavaScript minifier (in contrast to
global names, which would need certain annotations like those GCC uses).
Also it makes lookup a tiny bit
faster, because the JS engine needs to go up one scope less.
>
> - Why is static bar in class A named 'bar' but static nowPlusOne in class
> B is name 'nowPlusOne#static', what is the difference?
>
>
This is just a glitch I did when inlining the functions from the Jangaroo
output. The member functions do not need
a name at all for the code to work. The only purpose is that stack traces
look much nicer when functions have
names, but some debuggers are even so intelligent to find out the name of
the property the function has been
assigned to.
In Jangaroo, I postfixed static member variables (not their property
names!) with "$static", because in AS3,
there can actually be a non-static and a static member of the same name in
the same class, and I wanted to
avoid this name clash. Since we inline those member variables in FalconJx,
you do not have to care about
that problem.
> - Can you point me to where you document this 'this.barfoo = (A._ ||
> A._$get()).bar(3);'
> - specifically the '(A._ || A._$get())'
>
It's on the Wiki page: Compilation Units | Implementation Solution:
Non-ES5 Browser Issues
Since for the time being, we still target Internet Explorer 8 (or even 7),
we need a solution that also works without get properties, so we need a
more sophisticated solution for the _ property.
In order not to always need to perform a function call (which results in a
runtime penalty and is distracting during debugging), we try to read the
field first and only call the function in case the property is not yet
defined. Following the general pattern of naming explicit get functions
(see below), the factory function for IE8 would be called _$get, resulting
in the following expression to access a class from potentially
not-yet-initialized compilation unit: (OtherClass_._ || OtherClass_._$get())
>
>
> As far as the unit testing, don't have an answer at the moment.
>
As you say, first things first! :-)
Greetings
-Frank-
Re: [FalconJx] AMD source production update
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Frank,
couple things I don't understand
- What do you do with the !native stuff? I have those being tracked
now based on an enum I made from your repo
- Where is your 'toplevel' list that is being included right now? IE
trace and what else?
- Why is static bar in class A named 'bar' but static nowPlusOne in
class B is name 'nowPlusOne#static', what is the difference?
- Can you point me to where you document this 'this.barfoo = (A._ ||
A._$get()).bar(3);'
- specifically the '(A._ || A._$get())'
As far as the unit testing, don't have an answer at the moment.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Sure, I didn't mean to push, always mind the DoD! :-)
>
> Another goal to get something a bit more complex working could be FlexUnit.
> For Jangaroo, we use an older
> version<https://github.com/CoreMedia/jangaroo-libs/tree/jangaroo-3/joounit>(I
> think it is called 0.9) that works without test annotations and uses
> only very few Flash/Flex APIs.
> FlexUnit has over 60 self-tests, so if we could get it to run and see those
> tests green (like it is the case with the code produced by Jangaroo 3),
> we'd get even more confidence/proof that this actually works.
>
> Just an idea...
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD source production update
Posted by Frank Wienberg <fr...@jangaroo.net>.
Sure, I didn't mean to push, always mind the DoD! :-)
Another goal to get something a bit more complex working could be FlexUnit.
For Jangaroo, we use an older
version<https://github.com/CoreMedia/jangaroo-libs/tree/jangaroo-3/joounit>(I
think it is called 0.9) that works without test annotations and uses
only very few Flash/Flex APIs.
FlexUnit has over 60 self-tests, so if we could get it to run and see those
tests green (like it is the case with the code produced by Jangaroo 3),
we'd get even more confidence/proof that this actually works.
Just an idea...
-Frank-
Re: [FalconJx] AMD source production update
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Yeah inheritance is going to be fine, I will work on that next, first
things first.
I'm just allotting certain amounts of time each day for certain
projects I am working on.
You will see that code tomorrow.
I have to refactor the 1000 lines of code or so before I move forward,
there was a lot I needed to do with expression queries, so I have to
get that code out into static utilities.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Wed, Feb 6, 2013 at 5:06 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>>
>> Quoting Frank Wienberg <fr...@jangaroo.net>:
>>
>> Wow. FalconJx FTW!
>>>
>>> But this is a good start.
>>>>
>>>
>>> Definitely so!
>>>
>>> The *only* thing I noticed (besides the missing static "trace" line of
>>> code
>>>
>>> you already mentioned) is that "staticMembers" slipped into the "members"
>>> level, while it should be a sibling of "members" (I mean on the same level
>>> as "members"). I guess that is really simple to fix?
>>>
>>
>>
>> Right, it will take me about 1 minute. :) Just missed a pop at the end of
>> the members loop.
>
>
> :-)
>
>
>>
>>
>>
>> Did I already mention that once we get [Native] and the other primary
>>> declarations (functions, variables) to work, we could re-compile
>>> jangaroo-browser, jooflash and eventually OpenFlashChart with FalconJx and
>>> re-create the OpenFlashChart demo? That would really make a nice demo for
>>> the Flex demo page they currently discuss in this other thread!
>>>
>>
>>
>> Yeah, I was planning on that. The emitter I assume is not just going to
>> collect dust is it?
>>
>>
> *choke* *choke* No way! I'll set up all necessary code for OFC on Github
> soon.
>
> Btw, what about class B? Already everything fine with inheritance?
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD source production update
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Wed, Feb 6, 2013 at 5:06 PM, Michael Schmalle <ap...@teotigraphix.com>wrote:
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
> Wow. FalconJx FTW!
>>
>> But this is a good start.
>>>
>>
>> Definitely so!
>>
>> The *only* thing I noticed (besides the missing static "trace" line of
>> code
>>
>> you already mentioned) is that "staticMembers" slipped into the "members"
>> level, while it should be a sibling of "members" (I mean on the same level
>> as "members"). I guess that is really simple to fix?
>>
>
>
> Right, it will take me about 1 minute. :) Just missed a pop at the end of
> the members loop.
:-)
>
>
>
> Did I already mention that once we get [Native] and the other primary
>> declarations (functions, variables) to work, we could re-compile
>> jangaroo-browser, jooflash and eventually OpenFlashChart with FalconJx and
>> re-create the OpenFlashChart demo? That would really make a nice demo for
>> the Flex demo page they currently discuss in this other thread!
>>
>
>
> Yeah, I was planning on that. The emitter I assume is not just going to
> collect dust is it?
>
>
*choke* *choke* No way! I'll set up all necessary code for OFC on Github
soon.
Btw, what about class B? Already everything fine with inheritance?
Re: [FalconJx] AMD source production update
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Wow. FalconJx FTW!
>
>> But this is a good start.
>
> Definitely so!
>
> The *only* thing I noticed (besides the missing static "trace" line of code
> you already mentioned) is that "staticMembers" slipped into the "members"
> level, while it should be a sibling of "members" (I mean on the same level
> as "members"). I guess that is really simple to fix?
Right, it will take me about 1 minute. :) Just missed a pop at the end
of the members loop.
> Did I already mention that once we get [Native] and the other primary
> declarations (functions, variables) to work, we could re-compile
> jangaroo-browser, jooflash and eventually OpenFlashChart with FalconJx and
> re-create the OpenFlashChart demo? That would really make a nice demo for
> the Flex demo page they currently discuss in this other thread!
Yeah, I was planning on that. The emitter I assume is not just going
to collect dust is it?
> Greetings,
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD source production update
Posted by Frank Wienberg <fr...@jangaroo.net>.
Wow. FalconJx FTW!
> But this is a good start.
Definitely so!
The *only* thing I noticed (besides the missing static "trace" line of code
you already mentioned) is that "staticMembers" slipped into the "members"
level, while it should be a sibling of "members" (I mean on the same level
as "members"). I guess that is really simple to fix?
Did I already mention that once we get [Native] and the other primary
declarations (functions, variables) to work, we could re-compile
jangaroo-browser, jooflash and eventually OpenFlashChart with FalconJx and
re-create the OpenFlashChart demo? That would really make a nice demo for
the Flex demo page they currently discuss in this other thread!
Greetings,
-Frank-
Re: [FalconJx] AMD source production update
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hi,
Well Frank, after much headache and a little research, I managed to
get the prototype of 'AS3.bind()' replacement in this production.
Basically, I have now verbatim your class A, which basically means we
are rolling for classes! Obviously interfaces will be very simple.
The only thing that is not in this production is native references
which I can get, I made an enum of your classes you use. And I have to
run through the nodes in the Type scope to get that static trace
statement which I know I can do.
So those are the two thing I know need to be finished, please look
through this code and see if you notice anything wrong with it.
Mike
PS you know we then have the little things like for, catch, stuff I
can abstract into the base JSEmitter. But this is a good start.
define(["exports", "runtime/AS3", "classes/com/acme/I"],
function($exports, AS3, I) {
"use strict";
AS3.compilationUnit($exports, function($primaryDeclaration){
function A(msg) {
this.msg = msg;
}
$primaryDeclaration(AS3.class_({
package_: "com.acme",
class_: "A",
implements_: [
I
],
members: {
constructor: A,
_msg$1:{
value:0,
writable:true
},
msg: {
get: function msg$get() {
return String(this._msg$1);
},
set: function msg$set(value) {
this._msg$1 = parseInt(value, 10);
}
},
secret$1: function secret(n) {
return this.msg + n;
},
foo: function foo(x) {
return this.secret$1(A.bar(x));
},
baz: function baz() {
var tmp = AS3.bind(this, "secret$1");
return tmp("-bound");
},
staticMembers: {
bar: function bar(x) {
return x + 1;
}
}
}
}));
});
});
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Mike, this is really amazing! Or "just art", as you called it in a tweet.
> It you continue at this pace, we'll have the Open Flash Chart demo up and
> running in FalconJx by the end of next week!
> Excited,
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD source production update
Posted by Frank Wienberg <fr...@jangaroo.net>.
Mike, this is really amazing! Or "just art", as you called it in a tweet.
It you continue at this pace, we'll have the Open Flash Chart demo up and
running in FalconJx by the end of next week!
Excited,
-Frank-