Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
On Mon, Jan 21, 2013 at 11:02 PM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, I spent some time going through your new framework. First off, I think it deserves to be called something else. The JS in ASJS implies that it is a JS specific implementation of the framework. In reality it is not. Well, I called that to show that it is a parallel framework. That we build both AS and JS beads. But I don't care to much about what we end up calling it. Well, I do care. There are 2 naming conventions I think are working well right now: the intended use of a framework decides the first: ASJS stands for Actionscript to JavaScript, exactly what the frameworks and tools in there do. There is a brand new framework in there that has nothing to do with JS [1]. In fact, Alex has envisioned this new framework in a way that it does not know where it is going to be run on. My proposal is to have a directory structure that clearly separates the concerns. The second is the approach taken when going from AS to JS: first there is FlexJS, Alex's set of bottom up, start from scratch frameworks (one for AS and one for JS), and then there is VanillaSDK, my attempt at a top down, use the Flex SDK and write a complimentary JS framework approach. ASJS is also the home of the Publisher I'm writing, which will take either framework (FlexJS and VanillaSDK) and use it and it's dependencies to build an AS/MXML project into a HTML/JS project, again AS - JS. I don't mind renaming/rebranding things, especially is something is gained by doing so (even if it's only better marketing), but we should take care not to end up with a too generic naming convention just trying to fit too many projects under one roof. I agree with everything you are saying. But please hear me out. This is what I am proposing: Instead of it being: http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/ http://svn.apache.org/viewvc/flex/*asjs* /branches/develop/frameworks/js/FlexJS/ http://svn.apache.org/viewvc/flex/*asjs* /branches/develop/frameworks/js/VanillaSDK/ etc. lets make it (replace *AlexFlex *with whatever codename you want to): http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/ http://svn.apache.org/viewvc/flex/*AlexFlex* /branches/develop/frameworks/js/FlexJS/ http://svn.apache.org/viewvc/flex/*AlexFlex* /branches/develop/frameworks/js/VanillaSDK/ etc. This way, I can go in and add something like: http://svn.apache.org/viewvc/flex/*AlexFlex* /branches/develop/frameworks/as/src/org/apache/flex/stage3d/ alongside http://svn.apache.org/viewvc/flex/*AlexFlex* /branches/develop/frameworks/as/src/org/apache/flex/html/ Do you see where I am going with this? My goal (if a bit naive) is to tag along with this new framework and explore how best we can start rendering stuff using the GPU. Having a source tree with the term asjs and working on Flash player specific stuff - that can never be replicated in JS or HTML5 sounds like a bad idea to me. Hence the request. If you have an alternative to what I am trying to achieve, I am all ears. Thanks, Om EdB [1] http://svn.apache.org/viewvc/flex/asjs/branches/develop/frameworks/as/
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Om, I see your point. Here's mine: Alex's new framework has an AS and a JS part. Currently projects build using his AS part are compiled with FalconJS to run in the browser using his JS framework. Alex has named his framework combo FlexJS. I think that name (FlexJS) should be revisited as that framework clearly has more uses than enabling JS output. You are 'only' interested in the AS part of FlexJS. My suggestion would be that you and Alex move the AS framework out of the asjs tree into it's own root *AlexFlex*. This leaves only JS frameworks (with the JS part of FlexJS chief among them) in 'asjs/../frameworks/js', so these JS frameworks could move up one level. The new situation should look something like this (hoping it isn't wrapped to pieces by the various email clients): root | - asjs | - branches | - develop | - examples | - frameworks | - *FlexJS* (the JS part) | - VanillaSDK | - publisher - *AlexFlex* | - branches | - develop | - frameworks | - *FlexJS* (the AS part) | - *OM_GPU_MAGIC* That way, everything that has to do with AS - JS cross compilation can stay in 'asjs' (which is a fitting name), and anything that has to do with Alex's new AS framework goes into the new location. Makes sense? EdB http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/ http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/FlexJS/ http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/VanillaSDK/ etc. lets make it (replace *AlexFlex *with whatever codename you want to): http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/ http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/FlexJS/ http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/VanillaSDK/ etc. This way, I can go in and add something like: http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/stage3d/ alongside http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/html/ -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
I was going to recommend trying a WebGL for GPU rendering. However, while most browsers support it. Microsoft has not yet jumped on board. It does use the HTML5 Canvas to render on. I didn't even remember it existed really until I read an article about a game from Mozilla demo studio called BananaBread. It was a 3D first person shooter game compiled to JS+WebGL. The part that caught my eye was the Compiled into JS+WebGL. https://developer.mozilla.org/en-US/demos/detail/bananabread Are there any other well adopted standards similar to WebGL? -Mark -Original Message- From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of Om Sent: Monday, January 21, 2013 20:22 To: dev@flex.apache.org Subject: Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be) On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui aha...@adobe.com wrote: Changing subject because GPU rendering usually gets a lot of replies. In this new framework, I am trying to separate everything into little chunks I call beads. The visual components are supposed to have a minimum of three beads, one each for MVC, and the V is essentially the Skin. I spent some time going through your new framework. First off, I think it deserves to be called something else. The JS in ASJS implies that it is a JS specific implementation of the framework. In reality it is not. Second, it deserves its own wiki page. The reason is: I see this as a clean way to start implementing a new Flex framework. The effort that you, Michael.S and Erik have undertaken to make it work in HTML/JS can work in parallel with a Starling/GPU based View for the same new Flex framework. Components don't assume they are on the Flash display list. Instead of calling addChild, you call child.addToParent. This makes a lot of sense. Except that Starling's APIs tries to mimic the current Flash Player's display list paradigm. I need to spend some time trying to figure out how I can tie these things up. Any thoughts? So, yes, you could write new view beads that create their visuals using starling. I suppose we could rewire addToParent to do what you want. This is the part that excites me most. I will start writing an implementation of your framework with a Starling based view. I might have to a new implementation of Application.as. Do you mind if I pollute the asjs directory with my code, or would you prefer that I do it on my whiteboard? I didn't explicitly design the new framework for starling. I think that is a good thing. The more clearer the separation there is between the rest of the framework and the render specific stuff, the better for everyone. I still need convincing that it truly makes a difference for the vast majority of business applications. I still think your Flex apps are busy running AS code or suffering from having too many display objects per component which I do want to tackle in this new framework. My take on this is: I have worked on so many data intensive applications where performance goes for a toss when the framework is trying to draw too many things on the screen. Utilizing the GPU (especially on mobile) would definitely make a difference. For legacy hardware, things would fallback to to a software engine anyways, so what is the harm in trying this out? I did consider that the new framework would favor bitmaps over vectors, at least in the early versions. I'm not planning support on the JS side for vector graphics right away, so you are reduced to using bitmaps for many more things, which I think most folks do in HTML/JS and which GPUs seem to like more. Again, this is a good thing. In my experiments with Flex on mobile devices, rastering displayobjects and removing them off the display yielded so much better performance. Imagine if everything we had this kind of support in the framework itself. The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js folder. The latest ASJS framework is in asjs/branches/develop/framework, and the example that uses it is in asjs/branches/develop/examples/FlexJSTest_again. As I said earlier, it would be fantastic if you could split the new framework into separate directory and not throw it in along with ASJS. Does that make sense? Thanks, Om On 1/18/13 11:04 AM, Om bigosma...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui aha...@adobe.com wrote: That's why I've chosen a new parallel framework: I've already got a prototype up and running, and I would not be able to do that with the current Flex SDK. Hopefully the patterns I am using the new framework are extensible enough to allow it to grow up to match the old Flex SDK over time. This sounds very interesting to me. I have been playing around with Starling and Stage3D to see how best to render Flex via the GPU. I've come to the conclusion that this would entail rewriting a lot of of existing Flex
RE: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Well Firefox, Chrome, Safari(disabled by default), Opera, few mobile ones support it. IE only supports it atm with a plugin. However it is pretty much a deal breaker to design the end state twice. But if you want an easy to read does my browser support WebGL type page.. try this. Yay/nay lol. http://www.doesmybrowsersupportwebgl.com/ -Mark -Original Message- From: Kevin Newman [mailto:capta...@unfocus.com] Sent: Tuesday, January 22, 2013 10:37 To: dev@flex.apache.org Subject: Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be) WebGL isn't supported by IE (and various flavors of WebKit and maybe not Opera either), so you'd have to do two implementations, one in WebGL, and a fallback in Canvas (which in IE is GPU accelerated). Kevin N. On 1/22/13 7:26 AM, Kessler CTR Mark J wrote: I was going to recommend trying a WebGL for GPU rendering. However, while most browsers support it. Microsoft has not yet jumped on board. It does use the HTML5 Canvas to render on. I didn't even remember it existed really until I read an article about a game from Mozilla demo studio called BananaBread. It was a 3D first person shooter game compiled to JS+WebGL. The part that caught my eye was the Compiled into JS+WebGL. https://developer.mozilla.org/en-US/demos/detail/bananabread Are there any other well adopted standards similar to WebGL? -Mark
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
On Tue, Jan 22, 2013 at 2:40 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, I see your point. Here's mine: Alex's new framework has an AS and a JS part. Currently projects build using his AS part are compiled with FalconJS to run in the browser using his JS framework. Alex has named his framework combo FlexJS. I think that name (FlexJS) should be revisited as that framework clearly has more uses than enabling JS output. You are 'only' interested in the AS part of FlexJS. My suggestion would be that you and Alex move the AS framework out of the asjs tree into it's own root *AlexFlex*. This leaves only JS frameworks (with the JS part of FlexJS chief among them) in 'asjs/../frameworks/js', so these JS frameworks could move up one level. The new situation should look something like this (hoping it isn't wrapped to pieces by the various email clients): root | - asjs | - branches | - develop | - examples | - frameworks | - *FlexJS* (the JS part) | - VanillaSDK | - publisher - *AlexFlex* | - branches | - develop | - frameworks | - *FlexJS* (the AS part) | - *OM_GPU_MAGIC* That way, everything that has to do with AS - JS cross compilation can stay in 'asjs' (which is a fitting name), and anything that has to do with Alex's new AS framework goes into the new location. Makes sense? EdB http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/ http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/FlexJS/ http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/VanillaSDK/ etc. lets make it (replace *AlexFlex *with whatever codename you want to): http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/ http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/FlexJS/ http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/VanillaSDK/ etc. This way, I can go in and add something like: http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/stage3d/ alongside http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/html/ -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
On 1/21/13 5:21 PM, Om bigosma...@gmail.com wrote: On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui aha...@adobe.com wrote: Changing subject because GPU rendering usually gets a lot of replies. In this new framework, I am trying to separate everything into little chunks I call beads. The visual components are supposed to have a minimum of three beads, one each for MVC, and the V is essentially the Skin. I spent some time going through your new framework. First off, I think it deserves to be called something else. The JS in ASJS implies that it is a JS specific implementation of the framework. In reality it is not. Well, I called that to show that it is a parallel framework. That we build both AS and JS beads. But I don't care to much about what we end up calling it. Second, it deserves its own wiki page. Well, I think there is one: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype The reason is: I see this as a clean way to start implementing a new Flex framework. The effort that you, Michael.S and Erik have undertaken to make it work in HTML/JS can work in parallel with a Starling/GPU based View for the same new Flex framework. Components don't assume they are on the Flash display list. Instead of calling addChild, you call child.addToParent. This makes a lot of sense. Except that Starling's APIs tries to mimic the current Flash Player's display list paradigm. I need to spend some time trying to figure out how I can tie these things up. Any thoughts? Did you see the thread today where someone else proposed an alternative to Starling? Starling may not be the best way to get at stage3D/gpu. Any emulation of the display list is likely to cost more cycles than one tuned to the platform. Do we really need a display list at all? If not, then don't use one. So, yes, you could write new view beads that create their visuals using starling. I suppose we could rewire addToParent to do what you want. This is the part that excites me most. I will start writing an implementation of your framework with a Starling based view. I might have to a new implementation of Application.as. In my view of the world, there will be many packages with different flavors of Applications, components and beads. Do you mind if I pollute the asjs directory with my code, or would you prefer that I do it on my whiteboard? I think you can do it directly in the asjs directory if you organize the packages in a reasonable way. I didn't explicitly design the new framework for starling. I think that is a good thing. The more clearer the separation there is between the rest of the framework and the render specific stuff, the better for everyone. I still need convincing that it truly makes a difference for the vast majority of business applications. I still think your Flex apps are busy running AS code or suffering from having too many display objects per component which I do want to tackle in this new framework. My take on this is: I have worked on so many data intensive applications where performance goes for a toss when the framework is trying to draw too many things on the screen. OK, but did you put in the profiler? Did [render] actually show up or is other code running instead? Utilizing the GPU (especially on mobile) would definitely make a difference. Again, do you have empirical evidence? It makes sense for sprite sheets in a game, but I don't understand what kind of visualization you are doing in your business apps that is similar. For legacy hardware, things would fallback to to a software engine anyways, so what is the harm in trying this out? No harm, if this is your itch, you are welcome to scratch it, but I am all about expectation management. So if it were me I would use profiler data to set expectations. One of my goals of the new framework is to try to apply simple principles of just-in-time and on-demand so the SDK doesn't waste cycles for just-in-case stuff like it does now. That alone might give you the performance boost you are looking for. The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js folder. The latest ASJS framework is in asjs/branches/develop/framework, and the example that uses it is in asjs/branches/develop/examples/FlexJSTest_again. As I said earlier, it would be fantastic if you could split the new framework into separate directory and not throw it in along with ASJS. Does that make sense? Well, you can argue for a different name for the folder, but its ability to have a parallel JS framework is highly important and one of the major design/implementation constraints, so I like the idea there is an as folder next to the js folder in SVN. If your work turns out to be just alternative skins, that can be managed in a separate package or folder. For now, I think you should just start sticking in code and see what we end up with
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Hi, I spent some time going through your new framework. First off, I think it deserves to be called something else. The JS in ASJS implies that it is a JS specific implementation of the framework. In reality it is not. Well, I called that to show that it is a parallel framework. That we build both AS and JS beads. But I don't care to much about what we end up calling it. Well, I do care. There are 2 naming conventions I think are working well right now: the intended use of a framework decides the first: ASJS stands for Actionscript to JavaScript, exactly what the frameworks and tools in there do. The second is the approach taken when going from AS to JS: first there is FlexJS, Alex's set of bottom up, start from scratch frameworks (one for AS and one for JS), and then there is VanillaSDK, my attempt at a top down, use the Flex SDK and write a complimentary JS framework approach. ASJS is also the home of the Publisher I'm writing, which will take either framework (FlexJS and VanillaSDK) and use it and it's dependencies to build an AS/MXML project into a HTML/JS project, again AS - JS. I don't mind renaming/rebranding things, especially is something is gained by doing so (even if it's only better marketing), but we should take care not to end up with a too generic naming convention just trying to fit too many projects under one roof. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] where I'm going to be
After some time off, I just became aware of this discussion, and it has already become quite longish, so please forgive me if I missed or misunderstood some arguments. That said, my understanding of MXML is that it is just another (for some use cases more convenient) syntax to write an ActionScript class. From MXML, you can use any other AS class that has a no-arg constructor and properties, and from AS, MXML components can be referenced like normal classes, too. When using a component library, you do not even know whether the components were written in AS or MXML. An MXML component can inherit from an AS class and vice versa. I find this mix-and-match approach very charming. And if that is the correct semantics, I don't see any reason to not generate JavaScript code from the (temporary) AS class generated from MXML. Now in this thread, I read that you should not generate an ActionScript class / JavaScript from MXML, but instead a data structure that gets instantiated into a component (later). That sounds like a similar approach to Ext JS, where they use object literals with xtypes as component descriptors, which can then be instantiated into real components as needed. Sounds good, too, and indeed has some advantages (lazy components), but how does that go together with the old approach of MXML? Or is my understanding wrong? How would you use an MXML component from AS3 code if it is not a class? Can you still mix and match? Hoping someone can shed light on all of this, *-Frank-*
Re: [FalconJx] where I'm going to be
And to be completely honest here, so you have the proper expectations; I usually before starting something like the MXML task, turn up psychedelic trance music really loud, stare at the screen for a couple hours, write some code, refactor the code. Stare at it again for about 1 day, look through the falcon compiler source code and api for another 4 hours. Return to my original code, with the trance music still playing and finally start writing implementations. ;-) That's how I do it and why I love not working for a company! SideNote; My point is, inside I feel there is an answer to every question in the world. The answer for MXML is waiting patiently to be found. When the time comes to find it, it will be sitting in front of us found. That is why I said, for now I am finishing AS3, because the MXML solution already exists, except in the future, not right now. ;-) heheh Mike Quoting Michael Schmalle apa...@teotigraphix.com: Quoting Erik de Bruin e...@ixsoftware.nl: Mike, I'm not trying to get you to do stuff, certainly not 'out of order'. First things first, and we'll have our hands full on AS - JS, to be sure. Just thinking out loud: at some point I saw a video where an Adobe guy explained one of the early FalconJS prototypes (Pete?) and he worked around MXML by using intermediary MXML - AS output and stuff that through his compiler, instead of working directly on MXML. At some point (after all else is said and done), might that be an option? Are you talking about producing a Class for the MXML file, then parsing the class? MXML WILL get done. I spent 2 hours last night looking at all the HACKING Alex had to do, to get it working. Mike EdB On Fri, Jan 18, 2013 at 12:49 PM, Michael Schmalle apa...@teotigraphix.com wrote: Erik, MXML comes after ActionScript. Sorry but I have to do things in order. This is where projects go wrong, where people start cutting corners and skipping things they should finish. 10 years experience with this stuff and various architectures tells me finish the foundation before we do anything else that is external to the core cross compiler. Remember, MXML is not ActionScript and the first order of business is an AS3-JS cross compiler, MXML is Flex specific. I have a flaming blog post on deck about this project. As far as doing things with AST IE MXML AST, I can manage anything here I just need to finish something before I completely focus on MXML. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Mike, how does that relate to MXML (if at all...)? wrt. MXML, will you (someone) be able to take what Alex did for FalconJS and put that in FalconJx, or does it not work like that? I'm trying to get a feeling for where we are in relation to the two other Falcons and MXML seems to be a big thing for both of them... Thanks, EdB On Fri, Jan 18, 2013 at 12:19 PM, Michael Schmalle apa...@teotigraphix.com wrote: Hey all, Since the project is really taking shape thanks to our great cooperation, I am going to focus on the nemesis I have left and that is finishing of the ActionScript emitter. This project blew up fast with Erik contributing, I didn't get a chance to fully finish the ActionScript impl. Yes, I might have plans down the road to make a read/write AS DOM and having a fully functional AS3 emitter is essential. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- 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] where I'm going to be
Understood, thanks and good luck guys! I will monitor your work but first I need to learn about AS and MXML in more detail, where can I start? Because I thought MXML was just actionscript classes where a compiler would parse the MXML and generate the appropriate AS class.
Re: [FalconJx] where I'm going to be
No, the Falcon compiler turns MXML AST into straight ABC instructions. This is why Alex had to do majic with the MXMLClassDirectiveProccessor. So right now, there is no working translation of MXML into a Class file. Also this has been brought up between Alex and Gordon that doing a straight conversion is not a good plan. There needs to be an intermediate model that can hold the MXML data structure AFTER the AST. (I guess) This would mean using the model to traverse and emit, not the AST. Again, I am a very opinionated person and when I start to think about MXML and how to translate it, I will come up with what I think works using whatever means that requires, whether it's traversing the AST or creating and intermediate model. We will see. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Didn't the 'old' compiler (pre-Falcon) translate MXML into intermediate AS and offer the option to safe those intermediate files? I think that the presentation guy used these intermediate files (classes, I'm sure) instead of the actual MXML to get his prototype to work. I'm however not sure if Falcon has a similar option (save AS translation of MXML), so that might not be a option anymore. Just thinking out loud, while working on getting some more ToDo's out of the way :-) EdB On Fri, Jan 18, 2013 at 12:59 PM, Michael Schmalle apa...@teotigraphix.com wrote: Quoting Erik de Bruin e...@ixsoftware.nl: Mike, I'm not trying to get you to do stuff, certainly not 'out of order'. First things first, and we'll have our hands full on AS - JS, to be sure. Just thinking out loud: at some point I saw a video where an Adobe guy explained one of the early FalconJS prototypes (Pete?) and he worked around MXML by using intermediary MXML - AS output and stuff that through his compiler, instead of working directly on MXML. At some point (after all else is said and done), might that be an option? Are you talking about producing a Class for the MXML file, then parsing the class? MXML WILL get done. I spent 2 hours last night looking at all the HACKING Alex had to do, to get it working. Mike EdB On Fri, Jan 18, 2013 at 12:49 PM, Michael Schmalle apa...@teotigraphix.com wrote: Erik, MXML comes after ActionScript. Sorry but I have to do things in order. This is where projects go wrong, where people start cutting corners and skipping things they should finish. 10 years experience with this stuff and various architectures tells me finish the foundation before we do anything else that is external to the core cross compiler. Remember, MXML is not ActionScript and the first order of business is an AS3-JS cross compiler, MXML is Flex specific. I have a flaming blog post on deck about this project. As far as doing things with AST IE MXML AST, I can manage anything here I just need to finish something before I completely focus on MXML. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Mike, how does that relate to MXML (if at all...)? wrt. MXML, will you (someone) be able to take what Alex did for FalconJS and put that in FalconJx, or does it not work like that? I'm trying to get a feeling for where we are in relation to the two other Falcons and MXML seems to be a big thing for both of them... Thanks, EdB On Fri, Jan 18, 2013 at 12:19 PM, Michael Schmalle apa...@teotigraphix.com wrote: Hey all, Since the project is really taking shape thanks to our great cooperation, I am going to focus on the nemesis I have left and that is finishing of the ActionScript emitter. This project blew up fast with Erik contributing, I didn't get a chance to fully finish the ActionScript impl. Yes, I might have plans down the road to make a read/write AS DOM and having a fully functional AS3 emitter is essential. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] where I'm going to be
Yes, you right Carol, this information is very helpful and even more that, a good introduction/overview of how it works, what's the AST, ..., would be also welcomed I guess. -Fred -Message d'origine- From: Carol Frampton Sent: Friday, January 18, 2013 3:30 PM To: dev@flex.apache.org Subject: Re: [FalconJx] where I'm going to be This would be good info to post somewhere on the website since I'm sure Frederic isn't the only one wondering. Carol On 1/18/13 6 :41AM, Erik de Bruin e...@ixsoftware.nl wrote: Frederic, There are currently two JS cross compilation projects happening: FalconJS and FalconJx. FalconJS is a project started by Alex Harui. It is currently the most complete implementation and has (limited?) MXML parsing. The FalconJS compiler will take an MXML and AS project and output a valid HTML/JS application. FalconJS does depend on a custom AS framework (i.e. won't work with the Flex SDK) and corresponding JS framework. This framework goes by the name of FlexJS. Read more about it on the Wiki: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype FalconJx is the 'alternative' project from Michael Schmalle. It uses an alternative approach to AS3 compilation (don't ask for details, I have no clue about the innards of that code). One of it's main selling points (from my humble point of view) is that it has a very flexible architecture for outputting different flavours of JS. The status of this project is that we are working on getting complete AS3 language feature coverage in place. This means that we are working towards ~100% translation of AS into JS. I'm using the Google Closure Tools to augment standard JS to try and match the original AS language features. This is coming along nicely, but I'm sure the devil will be in the details. Read more on the 'goog' way here: https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27 +Way FalconJx future: once we have AS (and hopefully MXML, at some point) translating into JS and have functional tests in place, the challenge will become to come up with both AS and JS framework to actually allow for application development. I'm silly enough to still cling to the idea that we'll be able to use (most of) the Flex SDK and create a compatible JS library... but I'm sure others will declare me insane for just dreaming about that :-) Have fun, EdB On Fri, Jan 18, 2013 at 12:24 PM, Fréderic Cox coxfrede...@gmail.com wrote: I'm following your work with great interest, but I'm afraid as a regular AS3 developer with no background in compilers this is a bit too technical for me. I was wondering if you could explain in a non-technical way what the status of the project is at this moment. Questions I have: - I have an AS3 project, what can I do with FalconJx? Will it run in the browser already? - I have a Flex project with MXML, can it run in the browser with FalconJx instead of Flash Player? - Is it technically possible to write in AS3/MXML and without Flash run the content in the browser, how does it reflect to the pages paradigm (history) and the DOM? Thanks for your hard work, just trying to understand where we are at at this moment Fréderic Cox On 18/01/13 12:19, Michael Schmalle apa...@teotigraphix.com wrote: Hey all, Since the project is really taking shape thanks to our great cooperation, I am going to focus on the nemesis I have left and that is finishing of the ActionScript emitter. This project blew up fast with Erik contributing, I didn't get a chance to fully finish the ActionScript impl. Yes, I might have plans down the road to make a read/write AS DOM and having a fully functional AS3 emitter is essential. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] where I'm going to be
Hi Carol, The problem with this project is exactly what you are talking about. Alex worked on a full cross compile of logic and views. The project I started only cares about AS3 - JS conversion at the moment. So up until recently it was hard to describe the difference because FalconJx was created due to my in ability to learn the crazy code that exists in FalconJS. I'll let Erik put that up on the wiki somewhere since he is way more eloquent than I am. Mike Quoting Carol Frampton cfram...@adobe.com: This would be good info to post somewhere on the website since I'm sure Frederic isn't the only one wondering. Carol On 1/18/13 6 :41AM, Erik de Bruin e...@ixsoftware.nl wrote: Frederic, There are currently two JS cross compilation projects happening: FalconJS and FalconJx. FalconJS is a project started by Alex Harui. It is currently the most complete implementation and has (limited?) MXML parsing. The FalconJS compiler will take an MXML and AS project and output a valid HTML/JS application. FalconJS does depend on a custom AS framework (i.e. won't work with the Flex SDK) and corresponding JS framework. This framework goes by the name of FlexJS. Read more about it on the Wiki: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype FalconJx is the 'alternative' project from Michael Schmalle. It uses an alternative approach to AS3 compilation (don't ask for details, I have no clue about the innards of that code). One of it's main selling points (from my humble point of view) is that it has a very flexible architecture for outputting different flavours of JS. The status of this project is that we are working on getting complete AS3 language feature coverage in place. This means that we are working towards ~100% translation of AS into JS. I'm using the Google Closure Tools to augment standard JS to try and match the original AS language features. This is coming along nicely, but I'm sure the devil will be in the details. Read more on the 'goog' way here: https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27 +Way FalconJx future: once we have AS (and hopefully MXML, at some point) translating into JS and have functional tests in place, the challenge will become to come up with both AS and JS framework to actually allow for application development. I'm silly enough to still cling to the idea that we'll be able to use (most of) the Flex SDK and create a compatible JS library... but I'm sure others will declare me insane for just dreaming about that :-) Have fun, EdB On Fri, Jan 18, 2013 at 12:24 PM, Fréderic Cox coxfrede...@gmail.com wrote: I'm following your work with great interest, but I'm afraid as a regular AS3 developer with no background in compilers this is a bit too technical for me. I was wondering if you could explain in a non-technical way what the status of the project is at this moment. Questions I have: - I have an AS3 project, what can I do with FalconJx? Will it run in the browser already? - I have a Flex project with MXML, can it run in the browser with FalconJx instead of Flash Player? - Is it technically possible to write in AS3/MXML and without Flash run the content in the browser, how does it reflect to the pages paradigm (history) and the DOM? Thanks for your hard work, just trying to understand where we are at at this moment Fréderic Cox On 18/01/13 12:19, Michael Schmalle apa...@teotigraphix.com wrote: Hey all, Since the project is really taking shape thanks to our great cooperation, I am going to focus on the nemesis I have left and that is finishing of the ActionScript emitter. This project blew up fast with Erik contributing, I didn't get a chance to fully finish the ActionScript impl. Yes, I might have plans down the road to make a read/write AS DOM and having a fully functional AS3 emitter is essential. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] where I'm going to be
Mike, Q: How does it work? A: Basically we are utilizing the fantastic AST IASNode structure, traversing the nodes and visiting them individually with an emitter. The difference here is the AST walker is a hand written implementation that can easily be maintained and optimized per individual specs. I've been lost right after the word Basically, as many people who never did anything regarding compilers but compiling, there are some words that hurts :) that's the reason why I said introduction/overview meaning something more basic that could help to understand what is written on the wiki page. -Fred -Message d'origine- From: Michael Schmalle Sent: Friday, January 18, 2013 3:38 PM To: dev@flex.apache.org Subject: Re: [FalconJx] where I'm going to be I outlined some of this a while ago; https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype Mike Quoting Frédéric THOMAS webdoubl...@hotmail.com: Yes, you right Carol, this information is very helpful and even more that, a good introduction/overview of how it works, what's the AST, ..., would be also welcomed I guess. -Fred -Message d'origine- From: Carol Frampton Sent: Friday, January 18, 2013 3:30 PM To: dev@flex.apache.org Subject: Re: [FalconJx] where I'm going to be This would be good info to post somewhere on the website since I'm sure Frederic isn't the only one wondering. Carol On 1/18/13 6 :41AM, Erik de Bruin e...@ixsoftware.nl wrote: Frederic, There are currently two JS cross compilation projects happening: FalconJS and FalconJx. FalconJS is a project started by Alex Harui. It is currently the most complete implementation and has (limited?) MXML parsing. The FalconJS compiler will take an MXML and AS project and output a valid HTML/JS application. FalconJS does depend on a custom AS framework (i.e. won't work with the Flex SDK) and corresponding JS framework. This framework goes by the name of FlexJS. Read more about it on the Wiki: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype FalconJx is the 'alternative' project from Michael Schmalle. It uses an alternative approach to AS3 compilation (don't ask for details, I have no clue about the innards of that code). One of it's main selling points (from my humble point of view) is that it has a very flexible architecture for outputting different flavours of JS. The status of this project is that we are working on getting complete AS3 language feature coverage in place. This means that we are working towards ~100% translation of AS into JS. I'm using the Google Closure Tools to augment standard JS to try and match the original AS language features. This is coming along nicely, but I'm sure the devil will be in the details. Read more on the 'goog' way here: https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27 +Way FalconJx future: once we have AS (and hopefully MXML, at some point) translating into JS and have functional tests in place, the challenge will become to come up with both AS and JS framework to actually allow for application development. I'm silly enough to still cling to the idea that we'll be able to use (most of) the Flex SDK and create a compatible JS library... but I'm sure others will declare me insane for just dreaming about that :-) Have fun, EdB On Fri, Jan 18, 2013 at 12:24 PM, Fréderic Cox coxfrede...@gmail.com wrote: I'm following your work with great interest, but I'm afraid as a regular AS3 developer with no background in compilers this is a bit too technical for me. I was wondering if you could explain in a non-technical way what the status of the project is at this moment. Questions I have: - I have an AS3 project, what can I do with FalconJx? Will it run in the browser already? - I have a Flex project with MXML, can it run in the browser with FalconJx instead of Flash Player? - Is it technically possible to write in AS3/MXML and without Flash run the content in the browser, how does it reflect to the pages paradigm (history) and the DOM? Thanks for your hard work, just trying to understand where we are at at this moment Fréderic Cox On 18/01/13 12:19, Michael Schmalle apa...@teotigraphix.com wrote: Hey all, Since the project is really taking shape thanks to our great cooperation, I am going to focus on the nemesis I have left and that is finishing of the ActionScript emitter. This project blew up fast with Erik contributing, I didn't get a chance to fully finish the ActionScript impl. Yes, I might have plans down the road to make a read/write AS DOM and having a fully functional AS3 emitter is essential. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] where I'm going to be
Yeah, When I wrote that I was basically brainstorming and talking to myself. Since it's in the trunk now, it does require a more laymans explanation which I will work on. Really, here is the Overview. FalconJx is being designed to be able to compile ActionScript3 source code business logic to JavaScript business logic. At the moment, there are no plans for the majic bullet compile to SWF and Browser with the same view code. When I say business logic, I mean, no views, no ui components, no flash display list to javascript DOM conversations. Just business logic. My main intention is not to bloat the project's definition with over expectations like what happened in the definition of FalconJS. I just want to be able to write OOP type strict code in AS3 and compile it to JavaScript at the moment. Mike Quoting Frédéric THOMAS webdoubl...@hotmail.com: Mike, Q: How does it work? A: Basically we are utilizing the fantastic AST IASNode structure, traversing the nodes and visiting them individually with an emitter. The difference here is the AST walker is a hand written implementation that can easily be maintained and optimized per individual specs. I've been lost right after the word Basically, as many people who never did anything regarding compilers but compiling, there are some words that hurts :) that's the reason why I said introduction/overview meaning something more basic that could help to understand what is written on the wiki page. -Fred -Message d'origine- From: Michael Schmalle Sent: Friday, January 18, 2013 3:38 PM To: dev@flex.apache.org Subject: Re: [FalconJx] where I'm going to be I outlined some of this a while ago; https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype Mike Quoting Frédéric THOMAS webdoubl...@hotmail.com: Yes, you right Carol, this information is very helpful and even more that, a good introduction/overview of how it works, what's the AST, ..., would be also welcomed I guess. -Fred -Message d'origine- From: Carol Frampton Sent: Friday, January 18, 2013 3:30 PM To: dev@flex.apache.org Subject: Re: [FalconJx] where I'm going to be This would be good info to post somewhere on the website since I'm sure Frederic isn't the only one wondering. Carol On 1/18/13 6 :41AM, Erik de Bruin e...@ixsoftware.nl wrote: Frederic, There are currently two JS cross compilation projects happening: FalconJS and FalconJx. FalconJS is a project started by Alex Harui. It is currently the most complete implementation and has (limited?) MXML parsing. The FalconJS compiler will take an MXML and AS project and output a valid HTML/JS application. FalconJS does depend on a custom AS framework (i.e. won't work with the Flex SDK) and corresponding JS framework. This framework goes by the name of FlexJS. Read more about it on the Wiki: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype FalconJx is the 'alternative' project from Michael Schmalle. It uses an alternative approach to AS3 compilation (don't ask for details, I have no clue about the innards of that code). One of it's main selling points (from my humble point of view) is that it has a very flexible architecture for outputting different flavours of JS. The status of this project is that we are working on getting complete AS3 language feature coverage in place. This means that we are working towards ~100% translation of AS into JS. I'm using the Google Closure Tools to augment standard JS to try and match the original AS language features. This is coming along nicely, but I'm sure the devil will be in the details. Read more on the 'goog' way here: https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27 +Way FalconJx future: once we have AS (and hopefully MXML, at some point) translating into JS and have functional tests in place, the challenge will become to come up with both AS and JS framework to actually allow for application development. I'm silly enough to still cling to the idea that we'll be able to use (most of) the Flex SDK and create a compatible JS library... but I'm sure others will declare me insane for just dreaming about that :-) Have fun, EdB On Fri, Jan 18, 2013 at 12:24 PM, Fréderic Cox coxfrede...@gmail.com wrote: I'm following your work with great interest, but I'm afraid as a regular AS3 developer with no background in compilers this is a bit too technical for me. I was wondering if you could explain in a non-technical way what the status of the project is at this moment. Questions I have: - I have an AS3 project, what can I do with FalconJx? Will it run in the browser already? - I have a Flex project with MXML, can it run in the browser with FalconJx instead of Flash Player? - Is it technically possible to write in AS3/MXML and without Flash run the content in the browser, how does it reflect to the pages paradigm (history) and the DOM? Thanks for your hard work, just
Re: [FalconJx] where I'm going to be
When I say business logic, I mean, no views, no ui components, no flash display list to javascript DOM conversations. Just business logic. And that's where I come in. Once I'm done with helping out Mike getting the business logic up and running, I plan on starting work on the JS framework that will take care of the display stuff... EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] where I'm going to be
Great Erik! We are on the same page then, this is even better that I thought. :) Thanks for writing that. Mike Quoting Erik de Bruin e...@ixsoftware.nl: When I say business logic, I mean, no views, no ui components, no flash display list to javascript DOM conversations. Just business logic. And that's where I come in. Once I'm done with helping out Mike getting the business logic up and running, I plan on starting work on the JS framework that will take care of the display stuff... EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
RE: [FalconJx] where I'm going to be
Didn't the 'old' compiler (pre-Falcon) translate MXML into intermediate AS and offer the option to safe those intermediate files? I think that the presentation guy used these intermediate files (classes, I'm sure) instead of the actual MXML to get his prototype to work. I'm however not sure if Falcon has a similar option (save AS translation of MXML), so that might not be a option anymore. No, what they were actually doing is using the existing mxmlc with the -keep option to translate MXML to AS. Then they would take all of generated AS, including it in a project with the other ActionScript and try to give it a go with FalconJs. There are some other details too on SVG, etc. but that's the gist. Mike
Re: [FalconJx] where I'm going to be
Quoting Frédéric THOMAS webdoubl...@hotmail.com:
Mike,
Yes, that's a clear introduction of what it aims to and it was
important to clarify that.
Ok good.
On the wiki page, l would like to understand little bit more, even
if maybe, not sure, I can figure out what is a javascript target,
AST walker, JavaScript emitter and node switch strategy, it would be
nice if it would be explained.
Yes, I know that all sounds alien. I am positive I can make it sound
logical and understandable also.
The parser
---
AST stands for Abstract Syntax Tree avery complicated way of saying
Objects that have parents and children. When an .as file is parsed by
Falcon, the parser creates blocks of things it recognizes from the
string tokens feed to it as it's running through the source file. A
token is a String defined my the AS3 language spec IE class, if,
{, foo etc.
As the parser accepts these tokens from the stream, it recognizes
patterns like public is a namespace if it happens just before the
class token. So as the parser runs through these rules and finds
matches, it creates IASNode instance such as IClassNode, IIdentifier
node etc.
Each node in the tree represents a part of the ActionScript file. If
you actually look at an .as you can see how it's very nature is
heiracle, that is the AST tree and the IASNode subclasses represent
that tree.
We can also call this tree a DOM or Document Object Model. So when we
say AST we also mean ActionScript DOM because there is only one
semantic way that DOM will be constructed by the ASParser's grammar.
It's exactly what a Browser does with the HTML DOM, there are rules
and the only way the browser's parser will create an element in the
DOM is if you source code matches the rules.
The walker
-
Just as you would create a recursive function to traverse HTML with
JavaScript, we can do the same thing with the AS3 DOM (AST) which I
have done.
The only hard part about this is you have to be familiar with the
grammar or API of the DOM to make sure you recursively traverse it
in the correct order and get everything. That is why Erik and I have
over 500 unit tests, this is making sure we are producing the whole
language correctly.
So once the DOM is created, we call walke.visitFile(fileNode), which
the IFileNode is the root of the tree, just like window is the root of
the HTML DOM.
Visit file will then abstractly call visitPackage(), then
visitClass(), then visitMethod(), visitBlock(), visitIf(),
visitBinary() etc. The visit methods are called through the node
switch strategy class. This is kindof complicated but not really, it's
kindof a juggling act back and forth so the whole node handler
traversing calls the correct visit method based on the current node's
type, is it a function, expression etc.
You see, that when each of the nodes in the tree are visited
recursively, the String emitter is called to emit the javascript or
actionscript source code into the buffer.
The backend
The backend stuff is going to be refactored and I have some ideas
about the compiler setup but basically, the way the actual compiler is
setup and the design of FalconJx, it allows tremendous flexibility on
overriding things for different JavaScript output, the final string
that gets written to disk with the .js extension.
Like right now Erik has a Goog and AMD output that are separate
implementations but use the same core framework.
On a final note, this framework was first written by me to create
valid ActionScript. So what is actually happening is we are taking
advantage of the fact JavaScript is ECMA just like AS, so we are only
overriding the parts of the two languages that differ for source code
production.
In the end, FalconJx is actually an ActionScript emitter first, other
languages next.
Mike
-Fred.
-Message d'origine- From: Michael Schmalle
Sent: Friday, January 18, 2013 4:03 PM
To: dev@flex.apache.org
Subject: Re: [FalconJx] where I'm going to be
Yeah,
When I wrote that I was basically brainstorming and talking to myself.
Since it's in the trunk now, it does require a more laymans
explanation which I will work on.
Really, here is the Overview.
FalconJx is being designed to be able to compile ActionScript3 source
code business logic to JavaScript business logic. At the moment, there
are no plans for the majic bullet compile to SWF and Browser with
the same view code.
When I say business logic, I mean, no views, no ui components, no
flash display list to javascript DOM conversations. Just business logic.
My main intention is not to bloat the project's definition with over
expectations like what happened in the definition of FalconJS.
I just want to be able to write OOP type strict code in AS3 and
compile it to JavaScript at the moment.
Mike
Quoting Frédéric THOMAS webdoubl
Re: [FalconJx] where I'm going to be
Waou, that's just the golden needed missing informations, that has
absolutely to be reported on the wiki with the previous clarification,
thanks for you time Mike :)
-Fred
-Message d'origine-
From: Michael Schmalle
Sent: Friday, January 18, 2013 4:51 PM
To: dev@flex.apache.org
Subject: Re: [FalconJx] where I'm going to be
Quoting Frédéric THOMAS webdoubl...@hotmail.com:
Mike,
Yes, that's a clear introduction of what it aims to and it was important
to clarify that.
Ok good.
On the wiki page, l would like to understand little bit more, even if
maybe, not sure, I can figure out what is a javascript target, AST
walker, JavaScript emitter and node switch strategy, it would be nice if
it would be explained.
Yes, I know that all sounds alien. I am positive I can make it sound
logical and understandable also.
The parser
---
AST stands for Abstract Syntax Tree avery complicated way of saying
Objects that have parents and children. When an .as file is parsed by
Falcon, the parser creates blocks of things it recognizes from the
string tokens feed to it as it's running through the source file. A
token is a String defined my the AS3 language spec IE class, if,
{, foo etc.
As the parser accepts these tokens from the stream, it recognizes
patterns like public is a namespace if it happens just before the
class token. So as the parser runs through these rules and finds
matches, it creates IASNode instance such as IClassNode, IIdentifier
node etc.
Each node in the tree represents a part of the ActionScript file. If
you actually look at an .as you can see how it's very nature is
heiracle, that is the AST tree and the IASNode subclasses represent
that tree.
We can also call this tree a DOM or Document Object Model. So when we
say AST we also mean ActionScript DOM because there is only one
semantic way that DOM will be constructed by the ASParser's grammar.
It's exactly what a Browser does with the HTML DOM, there are rules
and the only way the browser's parser will create an element in the
DOM is if you source code matches the rules.
The walker
-
Just as you would create a recursive function to traverse HTML with
JavaScript, we can do the same thing with the AS3 DOM (AST) which I
have done.
The only hard part about this is you have to be familiar with the
grammar or API of the DOM to make sure you recursively traverse it
in the correct order and get everything. That is why Erik and I have
over 500 unit tests, this is making sure we are producing the whole
language correctly.
So once the DOM is created, we call walke.visitFile(fileNode), which
the IFileNode is the root of the tree, just like window is the root of
the HTML DOM.
Visit file will then abstractly call visitPackage(), then
visitClass(), then visitMethod(), visitBlock(), visitIf(),
visitBinary() etc. The visit methods are called through the node
switch strategy class. This is kindof complicated but not really, it's
kindof a juggling act back and forth so the whole node handler
traversing calls the correct visit method based on the current node's
type, is it a function, expression etc.
You see, that when each of the nodes in the tree are visited
recursively, the String emitter is called to emit the javascript or
actionscript source code into the buffer.
The backend
The backend stuff is going to be refactored and I have some ideas
about the compiler setup but basically, the way the actual compiler is
setup and the design of FalconJx, it allows tremendous flexibility on
overriding things for different JavaScript output, the final string
that gets written to disk with the .js extension.
Like right now Erik has a Goog and AMD output that are separate
implementations but use the same core framework.
On a final note, this framework was first written by me to create
valid ActionScript. So what is actually happening is we are taking
advantage of the fact JavaScript is ECMA just like AS, so we are only
overriding the parts of the two languages that differ for source code
production.
In the end, FalconJx is actually an ActionScript emitter first, other
languages next.
Mike
-Fred.
-Message d'origine- From: Michael Schmalle
Sent: Friday, January 18, 2013 4:03 PM
To: dev@flex.apache.org
Subject: Re: [FalconJx] where I'm going to be
Yeah,
When I wrote that I was basically brainstorming and talking to myself.
Since it's in the trunk now, it does require a more laymans
explanation which I will work on.
Really, here is the Overview.
FalconJx is being designed to be able to compile ActionScript3 source
code business logic to JavaScript business logic. At the moment, there
are no plans for the majic bullet compile to SWF and Browser with
the same view code.
When I say business logic, I mean, no views, no ui components, no
flash display list to javascript DOM conversations. Just business logic.
My main intention is not to bloat the project's
Re: [FalconJx] where I'm going to be
On 1/18/13 8:11 AM, Fréderic Cox coxfrede...@gmail.com wrote: That is interesting stuff! And more understandable now :-) (not fully yet ;-)) Thanks for your time and effort. I'm very pleased to see Erik has plans for the views handling from MXML to HTML DOM. That is an interesting part of the project too :-) The FalconJS compiler in compiler.js, plus the FlexJSTest_again example and the framework in the asjs develop branch already take MXML and result in an HTML DOM. All I have working right now is a button and a label, but I plan to work on finishing prototypes for the classics (TextInput, TextArea, CheckBox, List, Combobox) soon. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [FalconJx] where I'm going to be
On 1/18/13 4:21 AM, Michael Schmalle apa...@teotigraphix.com wrote: No, the Falcon compiler turns MXML AST into straight ABC instructions. This is why Alex had to do majic with the MXMLClassDirectiveProccessor. So right now, there is no working translation of MXML into a Class file. Also this has been brought up between Alex and Gordon that doing a straight conversion is not a good plan. There needs to be an intermediate model that can hold the MXML data structure AFTER the AST. (I guess) I don't think that there needs to be an intermediate model. The main reason for going from MXML to ABC was speed. One of the things Falcon will not support is a true -keep-generated-actionscript option. That's one of the reasons I am trying to alter MXML output so it generates more data and less code so your need to see the output as AS is greatly reduced. This would mean using the model to traverse and emit, not the AST. Again, I am a very opinionated person and when I start to think about MXML and how to translate it, I will come up with what I think works using whatever means that requires, whether it's traversing the AST or creating and intermediate model. I may be missing something, but I think the MXMLClassDirectiveProcessor is walking the AST not some intermediate model. What it does is a bit tricky because it is trying to flatten the tree into the data array and use the same APIs (of passing around Contexts). I haven't looked at your walker recently, but it might be simpler to implement in the walker/visitor pattern. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [FalconJx] where I'm going to be
On 1/18/13 3:49 AM, Michael Schmalle apa...@teotigraphix.com wrote: Erik, MXML comes after ActionScript. Sorry but I have to do things in order. This is where projects go wrong, where people start cutting corners and skipping things they should finish. 10 years experience with this stuff and various architectures tells me finish the foundation before we do anything else that is external to the core cross compiler. Fair enough, and you can do whatever you want in whatever order, but to me, finishing all of AS is not just the foundation, it is a fully grown tree. That's why I've taken the approach of doing just enough AS and MXML to get the demo to run. Why spend time now on AS constructs not used by the framework? Sure there's a chance some later construct will expose a flaw in the current implementation, but the implementation has to show flexibility/extensibility in case we want to extend AS in the future. I'd rather get enough stuff running so others can play with it and get excited about helping out, and most folks can help in the AS/MXML department, not in the Java/AST/compiler area. Anyway, I'm finishing up some mustella stuff for mobile, but after that I'm going to add more UI widgets and a lightweight HTTPService to the ASJS framework so I can code up simple form-type apps in MXML that run without Flash. Then I might be able to help out on the MXML for FalconJX depending on whether I get other folks to join in coding the framework. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [FalconJx] where I'm going to be
Quoting Alex Harui aha...@adobe.com: On 1/18/13 4:21 AM, Michael Schmalle apa...@teotigraphix.com wrote: No, the Falcon compiler turns MXML AST into straight ABC instructions. This is why Alex had to do majic with the MXMLClassDirectiveProccessor. So right now, there is no working translation of MXML into a Class file. Also this has been brought up between Alex and Gordon that doing a straight conversion is not a good plan. There needs to be an intermediate model that can hold the MXML data structure AFTER the AST. (I guess) I don't think that there needs to be an intermediate model. The main reason for going from MXML to ABC was speed. One of the things Falcon will not support is a true -keep-generated-actionscript option. That's one of the reasons I am trying to alter MXML output so it generates more data and less code so your need to see the output as AS is greatly reduced. Either do I, the way I see it is we traverse the MXML AST. I just have to look at what you have done to know what state needs to be saved as we are walking the MXML AST. If you look at the MXMLFileNode, it has everything wee need and the MXMLTreeBuilder does all the work as far as I can see. I think I was getting confused as to what you and Gordon were talking about. This would mean using the model to traverse and emit, not the AST. Again, I am a very opinionated person and when I start to think about MXML and how to translate it, I will come up with what I think works using whatever means that requires, whether it's traversing the AST or creating and intermediate model. I may be missing something, but I think the MXMLClassDirectiveProcessor is walking the AST not some intermediate model. What it does is a bit tricky because it is trying to flatten the tree into the data array and use the same APIs (of passing around Contexts). I haven't looked at your walker recently, but it might be simpler to implement in the walker/visitor pattern. I am almost certain the walker/visitor will work just fine, this is prompting me to test a prototype. It's bugging me not knowing the full story, I have to setup a test and see what you did and mimic it, then we will have the exact answer. Looks like I know what I am doing for the next 5 hours today, I said I wouldn't but its bothering me to much. :) Mike - Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] where I'm going to be
On 1/18/13 3:41 AM, Erik de Bruin e...@ixsoftware.nl wrote: Frederic, There are currently two JS cross compilation projects happening: FalconJS and FalconJx. FalconJS is a project started by Alex Harui. FTR, it was started by another Adobe engineer. I am just shepherding its donation to Apache and making enough of it run to suit my purposes while waiting for FalconJX. FalconJx future: once we have AS (and hopefully MXML, at some point) translating into JS and have functional tests in place, the challenge will become to come up with both AS and JS framework to actually allow for application development. I'm silly enough to still cling to the idea that we'll be able to use (most of) the Flex SDK and create a compatible JS library... but I'm sure others will declare me insane for just dreaming about that :-) I don't have a problem with shooting for support of existing code, I just think it will take a long time to get there. As I've said before, this is a critical year for Flex. We need to release alpha versions of this new direction early and often: every day that goes by more folks are choosing other JS frameworks. We have to show folks that this ASJS strategy can help them right away and get them to try it. Bonus points if those folks who start adopting it are key Adobe customers. That's why I've chosen a new parallel framework: I've already got a prototype up and running, and I would not be able to do that with the current Flex SDK. Hopefully the patterns I am using the new framework are extensible enough to allow it to grow up to match the old Flex SDK over time. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [FalconJx] where I'm going to be
Quoting Alex Harui aha...@adobe.com: On 1/18/13 3:49 AM, Michael Schmalle apa...@teotigraphix.com wrote: Erik, MXML comes after ActionScript. Sorry but I have to do things in order. This is where projects go wrong, where people start cutting corners and skipping things they should finish. 10 years experience with this stuff and various architectures tells me finish the foundation before we do anything else that is external to the core cross compiler. Fair enough, and you can do whatever you want in whatever order, but to me, finishing all of AS is not just the foundation, it is a fully grown tree. That's why I've taken the approach of doing just enough AS and MXML to get the demo to run. Why spend time now on AS constructs not used by the framework? Sure there's a chance some later construct will expose a flaw in the current implementation, but the implementation has to show flexibility/extensibility in case we want to extend AS in the future. I'd rather get enough stuff running so others can play with it and get excited about helping out, and most folks can help in the AS/MXML department, not in the Java/AST/compiler area. See my last reply, I concede, I agree that actually FalconJx con do enough right now that it warrants my attention in MXML. If my calculations are correct, this will be no harder than what I just did with the AS traversal, maybe even easier since I'm not dealing with statements and expressions. So, to reiterate, I hear what you are saying loud and clear, I will work on the MXML to produce what you did so there is the possibility for things to play with that would stimulate community involvement and help shape the future of whatever is going to be. Mike Anyway, I'm finishing up some mustella stuff for mobile, but after that I'm going to add more UI widgets and a lightweight HTTPService to the ASJS framework so I can code up simple form-type apps in MXML that run without Flash. Then I might be able to help out on the MXML for FalconJX depending on whether I get other folks to join in coding the framework. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
RE: [FalconJx] where I'm going to be
Quoting Gordon Smith gosm...@adobe.com: There needs to be an intermediate model that can hold the MXML data structure AFTER the AST. (I guess) I don't see why you would need to transform the MXML AST into yet another model. There are already two models for MXML and they should be sufficient. The syntactic model produced from the MXML tokens is MXMLData. Like any XML DOM, it simply represents the nesting of the tags, their attributes, and the text inside, without attributing any meaning to anything. The semantic model for MXML is the MXML AST, which has determined what every tag, attribute, and piece of text means. For example, it has understood that when you write s:Button label=OK color=red click=doit()/ you are creating an instance of spark.components.Button, setting the label property to OK, setting the color style to 0xFF, and adding an event handler to handler the click event. The MXML tree captures every piece of semantic information that was in the MXML file. - Gordon Gordon, this conversation is getting really diluted but I agree entirely that the model existing is great and will work. I misunderstood something you said a while back in a conversation with Alex. I thought you said MXML shouldn't be used to create javascript. Maybe you meant using it to mimic views or something? Can you elaborate, do you remember. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
RE: [FalconJx] where I'm going to be
I thought you said MXML shouldn't be used to create javascript. I don't have a clear recollection. I was probably recommending that MXML be converted into a data structure or a bytestream that would get interpreted by a small bit of JavaScript (or any other language). This is what Alex has been recommending, rather than turning MXML into JavaScript source code. (It's conceptually similar to the old approach of generating UIComponentDescriptors in early version of Flex, which could then be instantiated into actualy component instances.) But if you prefer to turn MXML into JavaScirpt source code, it should be straightforward to do that. The MXMLClassDirectiveProcessor is a simple recursive descent through the MXML AST. The main complexity is that it can't simply generate a continuous stream of code in tree order. For example, an attribute value that is a databinding expression has to generate all sorts of extra stuff like Watcher instances in other places. - Gordon -Original Message- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Friday, January 18, 2013 10:27 AM To: dev@flex.apache.org Subject: RE: [FalconJx] where I'm going to be Quoting Gordon Smith gosm...@adobe.com: There needs to be an intermediate model that can hold the MXML data structure AFTER the AST. (I guess) I don't see why you would need to transform the MXML AST into yet another model. There are already two models for MXML and they should be sufficient. The syntactic model produced from the MXML tokens is MXMLData. Like any XML DOM, it simply represents the nesting of the tags, their attributes, and the text inside, without attributing any meaning to anything. The semantic model for MXML is the MXML AST, which has determined what every tag, attribute, and piece of text means. For example, it has understood that when you write s:Button label=OK color=red click=doit()/ you are creating an instance of spark.components.Button, setting the label property to OK, setting the color style to 0xFF, and adding an event handler to handler the click event. The MXML tree captures every piece of semantic information that was in the MXML file. - Gordon Gordon, this conversation is getting really diluted but I agree entirely that the model existing is great and will work. I misunderstood something you said a while back in a conversation with Alex. I thought you said MXML shouldn't be used to create javascript. Maybe you meant using it to mimic views or something? Can you elaborate, do you remember. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
RE: [FalconJx] where I'm going to be
Quoting Gordon Smith gosm...@adobe.com: I thought you said MXML shouldn't be used to create javascript. I don't have a clear recollection. I was probably recommending that MXML be converted into a data structure or a bytestream that would get interpreted by a small bit of JavaScript (or any other language). This is what Alex has been recommending, rather than turning MXML into JavaScript source code. (It's conceptually similar to the old approach of generating UIComponentDescriptors in early version of Flex, which could then be instantiated into actualy component instances.) But if you prefer to turn MXML into JavaScirpt source code, it should be straightforward to do that. The MXMLClassDirectiveProcessor is a simple recursive descent through the MXML AST. The main complexity is that it can't simply generate a continuous stream of code in tree order. For example, an attribute value that is a databinding expression has to generate all sorts of extra stuff like Watcher instances in other places. - Gordon Ok I think I see where things went wrong in my head, thanks for the clarifications. What Alex is doing right now is basically what you said, he is making javascript but as descriptors and that is what I was thinking as well. So I guess everything is straight in my head, I was correct in you saying there is really no value in converting MXML to a javascript class based on the MXML itself. It worth creating descriptors that get initialized which I what Alex is currently doing with his implementation. This is what I will copy for now using the walker/visitor pattern I have been using. Thanks again Gordon, let me reiterate, it has been a pleasure using your compiler framework. :) -- 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
ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Changing subject because GPU rendering usually gets a lot of replies. In this new framework, I am trying to separate everything into little chunks I call beads. The visual components are supposed to have a minimum of three beads, one each for MVC, and the V is essentially the Skin. Components don't assume they are on the Flash display list. Instead of calling addChild, you call child.addToParent. So, yes, you could write new view beads that create their visuals using starling. I suppose we could rewire addToParent to do what you want. I didn't explicitly design the new framework for starling. I still need convincing that it truly makes a difference for the vast majority of business applications. I still think your Flex apps are busy running AS code or suffering from having too many display objects per component which I do want to tackle in this new framework. Early versions of this new framework are probably not going to support 3D effects and 3D rendering so I think I have time before I have to really deal with it. I did consider that the new framework would favor bitmaps over vectors, at least in the early versions. I'm not planning support on the JS side for vector graphics right away, so you are reduced to using bitmaps for many more things, which I think most folks do in HTML/JS and which GPUs seem to like more. The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js folder. The latest ASJS framework is in asjs/branches/develop/framework, and the example that uses it is in asjs/branches/develop/examples/FlexJSTest_again. On 1/18/13 11:04 AM, Om bigosma...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui aha...@adobe.com wrote: That's why I've chosen a new parallel framework: I've already got a prototype up and running, and I would not be able to do that with the current Flex SDK. Hopefully the patterns I am using the new framework are extensible enough to allow it to grow up to match the old Flex SDK over time. This sounds very interesting to me. I have been playing around with Starling and Stage3D to see how best to render Flex via the GPU. I've come to the conclusion that this would entail rewriting a lot of of existing Flex code. In your new framework, do you think it would be possible to switch from DisplayObject based rendering to GPU based rendering as needed? Did you consider this option when designing your new framework? Any chance we could see your prototype any time soon? Thanks, Om -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
