You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/11/28 08:34:46 UTC
FalconJS "Demo" checked in
Hi,
I finally got permission to check in a demo that uses FalconJS into my
whiteboard at [1].
I started a writeup on it on the wiki that I will try to complete tomorrow
at [2].
[1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
[2] https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
Thanks,
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
I take a quick look over it and seems very promising, hope to come back
later with some more time and dig it a bit more.
As Joan points, it would be great to know how to setup the project to play
with it.
Many thanks!
Carlos
2012/11/28 Joan Llenas Masó <jo...@garnetworks.com>
> I like the approach (I just read the wiki, didn't look at the JS vs AS
> implementation parts). It has a lot of sense.
> I think that Goals vs Non Goals are a key part, specially this statement:
> "we
> will encapsulate the best implementation possible under a given API
> contract
> ".
> Specially if we want to support the spark skinning model and other Flex
> architectural gems throughout all rendering targets.
>
> What's needed to run the sample project you provide?
> What's next? :-)
>
> Cheers!
>
>
> --
> Joan Llenas Masó
> CEO/CTO Garnet Works SL
> T. 93 848 57 27
> --
> @joangarnet (es)
> @joanllenas (en)
> http://joan.garnet.io
> http://www.garnetworks.com
>
>
>
>
> On Wed, Nov 28, 2012 at 8:34 AM, Alex Harui <ah...@adobe.com> wrote:
>
> > Hi,
> >
> > I finally got permission to check in a demo that uses FalconJS into my
> > whiteboard at [1].
> >
> > I started a writeup on it on the wiki that I will try to complete
> tomorrow
> > at [2].
> >
> > [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
> > [2]
> > https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
> >
> > Thanks,
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
No need to hold off. There isn't a ton of files being re-org'd.
On 11/30/12 8:19 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Excellent. I'll hold off from moving until I've grokked your Wiki
> entry and everything is working again, but it's good to know we won't
> be in each other's way.
>
> EdB
>
>
> On Fri, Nov 30, 2012 at 5:15 PM, Alex Harui <ah...@adobe.com> wrote:
>> I think you can just work in the develop branch. I'm going to be in the
>> falcon folders for a while anyway (I think).
>>
>>
>> On 11/30/12 8:05 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> I've branched the root into my whiteboard.
>>>
>>> I'm currently doing a major reorganisation of the JS framework (files,
>>> not code) and the general setup of the project. I've also started work
>>> on the 'publisher', that will take the AS, compile it to JS, add the
>>> JS framework to it and create the 'index.html'. There are empty dirs
>>> waiting for the unit tests and there is an examples directory in both
>>> the 'source' and 'published' directories. Please take a look and
>>> decide if this is something that would make sense to implement in de
>>> 'develop' branch.
>>>
>>> Thanks,
>>>
>>> EdB
>>>
>>>
>>> On Fri, Nov 30, 2012 at 8:02 AM, Alex Harui <ah...@adobe.com> wrote:
>>>> I branched my whiteboard into the root. I decided to call it "asjs"
>>>> because
>>>> we are developing parallel as and js frameworks. There is a develop branch
>>>> in there where we should be making our commits.
>>>>
>>>> -Alex
>>>>
>>>>
>>>> On 11/28/12 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>>>> Are we ready to put the framework.js in the FalconJS develop branch so
>>>>>>> we can all work on it?
>>>>>> IMO, framework.js shouldn't be in the FalconJS branch. It is as
>>>>>> independent
>>>>>> of FalconJS as any of the AS code is independent of Falcon.
>>>>>>
>>>>>> I would refactor framework.js into separate js files so we don't step on
>>>>>> each others toes and put it somewhere else in SVN and start adding to it
>>>>>> and
>>>>>> the .AS files. We could start by having folks just work in my whiteboard
>>>>>> or
>>>>>> we can create a new whiteboard folder not under my name if that makes
>>>>>> folks
>>>>>> more comfortable. I was going to branch what I have checked in for
>>>>>> further
>>>>>> modifications so what I checked in stays running.
>>>>>
>>>>> Might I suggest a 'as2js' in the root of the repo, with branches, tags
>>>>> and trunk. In trunk (and/or branches/develop?) I would have an 'as'
>>>>> and a 'js' folder, and within each of those a 'src' and 'srcTest'...
>>>>> But that's just of the top of my head, so I'm open to suggestions ;-)
>>>>>
>>>>>> Are you planning to use FlexUnit to test the AS side? What will you use
>>>>>> for
>>>>>> the JS side?
>>>>>
>>>>> FlexUnit seems to make sense for the AS. I use Jasmine [1] for
>>>>> JavaScript, so that would have my preference...
>>>>>
>>>>>>> Question: I expect that we'll need to figure out a way to put the
>>>>>>> framework components through the Closure Compiler upon "publish",
>>>>>>> correct?
>>>>>> Yes, there is a missing step where we generate an index.html and collect
>>>>>> all
>>>>>> of the required JS files and minify them. I'm hand-assembling stuff
>>>>>> right
>>>>>> now.
>>>>>
>>>>> Don't let Om hear it, or he'll start another AIR project :-) I'll give
>>>>> this some thought once we've set the rest up.
>>>>>
>>>>>>> Another question: for your prototype you modified/bypassed parts of
>>>>>>> the SDK, it looks like. Does this mean that you envision 2 versions of
>>>>>>> the SDK, one for Flash Player deployment and one for web native
>>>>>>> deployment?
>>>>>> I'm not sure what you mean here. For this new effort, I am not using
>>>>>> Apache
>>>>>> Flex 4.8 at all and have no plans to. This is a next-generation and a
>>>>>> full
>>>>>> rewrite with different goals. What it has in common with Flex is MXML
>>>>>> and
>>>>>> AS3 and many but not all APIs. The idea is that for every component you
>>>>>> write in AS, you have to create its equivalent in JS. You might be able
>>>>>> to
>>>>>> get FalconJS to help you create parts of the JS equivalent, but the parts
>>>>>> that touch the visuals pretty much have to be written differently.
>>>>>
>>>>> This was the missing link in my understanding. We're writing a new
>>>>> SDK, fresh components on both sides of the FalconJS compiler.
>>>>>
>>>>>>> I'll stop here and catch my breath ;-) I like what I'm seeing so far
>>>>>>> and certainly see the possibilities going forward. I do not share your
>>>>>>> caution about creating components that are more than basic
>>>>>>> implementations of available HTML controls. But we'll cross that
>>>>>>> bridge once we have a "working" version of the JS framework hooked up
>>>>>>> to the FalconJS compiler :-) First things first, right?
>>>>>> Definitely. My only "caution" about creating more than basic controls is
>>>>>> how long it will take to create them. My goal is to get the basic
>>>>>> unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
>>>>>> Label) running ASAP so folks can actually play with it. If you have the
>>>>>> time/energy to do fancier stuff you are more than welcome to get going on
>>>>>> it.
>>>>>
>>>>> Sure, first things first though, set up this sub-project, ok?
>>>>>
>>>>> EdB
>>>>>
>>>>> 1:
>>>>> http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applicatio
>>>>> ns
>>>>> -w
>>>>> ith-jasmine.html
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>
>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Excellent. I'll hold off from moving until I've grokked your Wiki
entry and everything is working again, but it's good to know we won't
be in each other's way.
EdB
On Fri, Nov 30, 2012 at 5:15 PM, Alex Harui <ah...@adobe.com> wrote:
> I think you can just work in the develop branch. I'm going to be in the
> falcon folders for a while anyway (I think).
>
>
> On 11/30/12 8:05 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> I've branched the root into my whiteboard.
>>
>> I'm currently doing a major reorganisation of the JS framework (files,
>> not code) and the general setup of the project. I've also started work
>> on the 'publisher', that will take the AS, compile it to JS, add the
>> JS framework to it and create the 'index.html'. There are empty dirs
>> waiting for the unit tests and there is an examples directory in both
>> the 'source' and 'published' directories. Please take a look and
>> decide if this is something that would make sense to implement in de
>> 'develop' branch.
>>
>> Thanks,
>>
>> EdB
>>
>>
>> On Fri, Nov 30, 2012 at 8:02 AM, Alex Harui <ah...@adobe.com> wrote:
>>> I branched my whiteboard into the root. I decided to call it "asjs" because
>>> we are developing parallel as and js frameworks. There is a develop branch
>>> in there where we should be making our commits.
>>>
>>> -Alex
>>>
>>>
>>> On 11/28/12 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>>>> Are we ready to put the framework.js in the FalconJS develop branch so
>>>>>> we can all work on it?
>>>>> IMO, framework.js shouldn't be in the FalconJS branch. It is as
>>>>> independent
>>>>> of FalconJS as any of the AS code is independent of Falcon.
>>>>>
>>>>> I would refactor framework.js into separate js files so we don't step on
>>>>> each others toes and put it somewhere else in SVN and start adding to it
>>>>> and
>>>>> the .AS files. We could start by having folks just work in my whiteboard
>>>>> or
>>>>> we can create a new whiteboard folder not under my name if that makes folks
>>>>> more comfortable. I was going to branch what I have checked in for further
>>>>> modifications so what I checked in stays running.
>>>>
>>>> Might I suggest a 'as2js' in the root of the repo, with branches, tags
>>>> and trunk. In trunk (and/or branches/develop?) I would have an 'as'
>>>> and a 'js' folder, and within each of those a 'src' and 'srcTest'...
>>>> But that's just of the top of my head, so I'm open to suggestions ;-)
>>>>
>>>>> Are you planning to use FlexUnit to test the AS side? What will you use
>>>>> for
>>>>> the JS side?
>>>>
>>>> FlexUnit seems to make sense for the AS. I use Jasmine [1] for
>>>> JavaScript, so that would have my preference...
>>>>
>>>>>> Question: I expect that we'll need to figure out a way to put the
>>>>>> framework components through the Closure Compiler upon "publish",
>>>>>> correct?
>>>>> Yes, there is a missing step where we generate an index.html and collect
>>>>> all
>>>>> of the required JS files and minify them. I'm hand-assembling stuff right
>>>>> now.
>>>>
>>>> Don't let Om hear it, or he'll start another AIR project :-) I'll give
>>>> this some thought once we've set the rest up.
>>>>
>>>>>> Another question: for your prototype you modified/bypassed parts of
>>>>>> the SDK, it looks like. Does this mean that you envision 2 versions of
>>>>>> the SDK, one for Flash Player deployment and one for web native
>>>>>> deployment?
>>>>> I'm not sure what you mean here. For this new effort, I am not using
>>>>> Apache
>>>>> Flex 4.8 at all and have no plans to. This is a next-generation and a full
>>>>> rewrite with different goals. What it has in common with Flex is MXML and
>>>>> AS3 and many but not all APIs. The idea is that for every component you
>>>>> write in AS, you have to create its equivalent in JS. You might be able to
>>>>> get FalconJS to help you create parts of the JS equivalent, but the parts
>>>>> that touch the visuals pretty much have to be written differently.
>>>>
>>>> This was the missing link in my understanding. We're writing a new
>>>> SDK, fresh components on both sides of the FalconJS compiler.
>>>>
>>>>>> I'll stop here and catch my breath ;-) I like what I'm seeing so far
>>>>>> and certainly see the possibilities going forward. I do not share your
>>>>>> caution about creating components that are more than basic
>>>>>> implementations of available HTML controls. But we'll cross that
>>>>>> bridge once we have a "working" version of the JS framework hooked up
>>>>>> to the FalconJS compiler :-) First things first, right?
>>>>> Definitely. My only "caution" about creating more than basic controls is
>>>>> how long it will take to create them. My goal is to get the basic
>>>>> unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
>>>>> Label) running ASAP so folks can actually play with it. If you have the
>>>>> time/energy to do fancier stuff you are more than welcome to get going on
>>>>> it.
>>>>
>>>> Sure, first things first though, set up this sub-project, ok?
>>>>
>>>> EdB
>>>>
>>>> 1:
>>>> http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications
>>>> -w
>>>> ith-jasmine.html
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
I think you can just work in the develop branch. I'm going to be in the
falcon folders for a while anyway (I think).
On 11/30/12 8:05 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> I've branched the root into my whiteboard.
>
> I'm currently doing a major reorganisation of the JS framework (files,
> not code) and the general setup of the project. I've also started work
> on the 'publisher', that will take the AS, compile it to JS, add the
> JS framework to it and create the 'index.html'. There are empty dirs
> waiting for the unit tests and there is an examples directory in both
> the 'source' and 'published' directories. Please take a look and
> decide if this is something that would make sense to implement in de
> 'develop' branch.
>
> Thanks,
>
> EdB
>
>
> On Fri, Nov 30, 2012 at 8:02 AM, Alex Harui <ah...@adobe.com> wrote:
>> I branched my whiteboard into the root. I decided to call it "asjs" because
>> we are developing parallel as and js frameworks. There is a develop branch
>> in there where we should be making our commits.
>>
>> -Alex
>>
>>
>> On 11/28/12 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>>>> Are we ready to put the framework.js in the FalconJS develop branch so
>>>>> we can all work on it?
>>>> IMO, framework.js shouldn't be in the FalconJS branch. It is as
>>>> independent
>>>> of FalconJS as any of the AS code is independent of Falcon.
>>>>
>>>> I would refactor framework.js into separate js files so we don't step on
>>>> each others toes and put it somewhere else in SVN and start adding to it
>>>> and
>>>> the .AS files. We could start by having folks just work in my whiteboard
>>>> or
>>>> we can create a new whiteboard folder not under my name if that makes folks
>>>> more comfortable. I was going to branch what I have checked in for further
>>>> modifications so what I checked in stays running.
>>>
>>> Might I suggest a 'as2js' in the root of the repo, with branches, tags
>>> and trunk. In trunk (and/or branches/develop?) I would have an 'as'
>>> and a 'js' folder, and within each of those a 'src' and 'srcTest'...
>>> But that's just of the top of my head, so I'm open to suggestions ;-)
>>>
>>>> Are you planning to use FlexUnit to test the AS side? What will you use
>>>> for
>>>> the JS side?
>>>
>>> FlexUnit seems to make sense for the AS. I use Jasmine [1] for
>>> JavaScript, so that would have my preference...
>>>
>>>>> Question: I expect that we'll need to figure out a way to put the
>>>>> framework components through the Closure Compiler upon "publish",
>>>>> correct?
>>>> Yes, there is a missing step where we generate an index.html and collect
>>>> all
>>>> of the required JS files and minify them. I'm hand-assembling stuff right
>>>> now.
>>>
>>> Don't let Om hear it, or he'll start another AIR project :-) I'll give
>>> this some thought once we've set the rest up.
>>>
>>>>> Another question: for your prototype you modified/bypassed parts of
>>>>> the SDK, it looks like. Does this mean that you envision 2 versions of
>>>>> the SDK, one for Flash Player deployment and one for web native
>>>>> deployment?
>>>> I'm not sure what you mean here. For this new effort, I am not using
>>>> Apache
>>>> Flex 4.8 at all and have no plans to. This is a next-generation and a full
>>>> rewrite with different goals. What it has in common with Flex is MXML and
>>>> AS3 and many but not all APIs. The idea is that for every component you
>>>> write in AS, you have to create its equivalent in JS. You might be able to
>>>> get FalconJS to help you create parts of the JS equivalent, but the parts
>>>> that touch the visuals pretty much have to be written differently.
>>>
>>> This was the missing link in my understanding. We're writing a new
>>> SDK, fresh components on both sides of the FalconJS compiler.
>>>
>>>>> I'll stop here and catch my breath ;-) I like what I'm seeing so far
>>>>> and certainly see the possibilities going forward. I do not share your
>>>>> caution about creating components that are more than basic
>>>>> implementations of available HTML controls. But we'll cross that
>>>>> bridge once we have a "working" version of the JS framework hooked up
>>>>> to the FalconJS compiler :-) First things first, right?
>>>> Definitely. My only "caution" about creating more than basic controls is
>>>> how long it will take to create them. My goal is to get the basic
>>>> unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
>>>> Label) running ASAP so folks can actually play with it. If you have the
>>>> time/energy to do fancier stuff you are more than welcome to get going on
>>>> it.
>>>
>>> Sure, first things first though, set up this sub-project, ok?
>>>
>>> EdB
>>>
>>> 1:
>>> http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications
>>> -w
>>> ith-jasmine.html
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I've branched the root into my whiteboard.
I'm currently doing a major reorganisation of the JS framework (files,
not code) and the general setup of the project. I've also started work
on the 'publisher', that will take the AS, compile it to JS, add the
JS framework to it and create the 'index.html'. There are empty dirs
waiting for the unit tests and there is an examples directory in both
the 'source' and 'published' directories. Please take a look and
decide if this is something that would make sense to implement in de
'develop' branch.
Thanks,
EdB
On Fri, Nov 30, 2012 at 8:02 AM, Alex Harui <ah...@adobe.com> wrote:
> I branched my whiteboard into the root. I decided to call it "asjs" because
> we are developing parallel as and js frameworks. There is a develop branch
> in there where we should be making our commits.
>
> -Alex
>
>
> On 11/28/12 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>>> Are we ready to put the framework.js in the FalconJS develop branch so
>>>> we can all work on it?
>>> IMO, framework.js shouldn't be in the FalconJS branch. It is as independent
>>> of FalconJS as any of the AS code is independent of Falcon.
>>>
>>> I would refactor framework.js into separate js files so we don't step on
>>> each others toes and put it somewhere else in SVN and start adding to it and
>>> the .AS files. We could start by having folks just work in my whiteboard or
>>> we can create a new whiteboard folder not under my name if that makes folks
>>> more comfortable. I was going to branch what I have checked in for further
>>> modifications so what I checked in stays running.
>>
>> Might I suggest a 'as2js' in the root of the repo, with branches, tags
>> and trunk. In trunk (and/or branches/develop?) I would have an 'as'
>> and a 'js' folder, and within each of those a 'src' and 'srcTest'...
>> But that's just of the top of my head, so I'm open to suggestions ;-)
>>
>>> Are you planning to use FlexUnit to test the AS side? What will you use for
>>> the JS side?
>>
>> FlexUnit seems to make sense for the AS. I use Jasmine [1] for
>> JavaScript, so that would have my preference...
>>
>>>> Question: I expect that we'll need to figure out a way to put the
>>>> framework components through the Closure Compiler upon "publish",
>>>> correct?
>>> Yes, there is a missing step where we generate an index.html and collect all
>>> of the required JS files and minify them. I'm hand-assembling stuff right
>>> now.
>>
>> Don't let Om hear it, or he'll start another AIR project :-) I'll give
>> this some thought once we've set the rest up.
>>
>>>> Another question: for your prototype you modified/bypassed parts of
>>>> the SDK, it looks like. Does this mean that you envision 2 versions of
>>>> the SDK, one for Flash Player deployment and one for web native
>>>> deployment?
>>> I'm not sure what you mean here. For this new effort, I am not using Apache
>>> Flex 4.8 at all and have no plans to. This is a next-generation and a full
>>> rewrite with different goals. What it has in common with Flex is MXML and
>>> AS3 and many but not all APIs. The idea is that for every component you
>>> write in AS, you have to create its equivalent in JS. You might be able to
>>> get FalconJS to help you create parts of the JS equivalent, but the parts
>>> that touch the visuals pretty much have to be written differently.
>>
>> This was the missing link in my understanding. We're writing a new
>> SDK, fresh components on both sides of the FalconJS compiler.
>>
>>>> I'll stop here and catch my breath ;-) I like what I'm seeing so far
>>>> and certainly see the possibilities going forward. I do not share your
>>>> caution about creating components that are more than basic
>>>> implementations of available HTML controls. But we'll cross that
>>>> bridge once we have a "working" version of the JS framework hooked up
>>>> to the FalconJS compiler :-) First things first, right?
>>> Definitely. My only "caution" about creating more than basic controls is
>>> how long it will take to create them. My goal is to get the basic
>>> unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
>>> Label) running ASAP so folks can actually play with it. If you have the
>>> time/energy to do fancier stuff you are more than welcome to get going on
>>> it.
>>
>> Sure, first things first though, set up this sub-project, ok?
>>
>> EdB
>>
>> 1:
>> http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-w
>> ith-jasmine.html
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
When I was thinking about how to make distinction between canvas and DOM
based display list output, I thought of letting developer choose on
compile time.
But I really like your solution with casheAsBitmap. On top of graphics
API I was planing to add another feature casheStyle("id") and what it
does it will store
css properties that you can reuse by graphics.getStyle("id") within
other sprites/shapes. It will minimise overbloatnes of custom style per div.
I guess for stuff like flex application html DOM will be more desirable
solution, but things like simulating Bitmap or interactive Charts,
Canvas still is must have.
I know there are some issues with transform on DOM elements but where is
a problem there is a solution.
What I can tell, you seems not to pay attention to that part yet, since
lots of matrix transformations are not implemented yet.
However, flex apps don't rotate/skew/scale too much :)
Dan
On 11/30/2012 10:40 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
>>> Primarily, I also map DOs to DOM elements!
>>>
>>> Greetings
>>> -Frank-
>> Just curious, but how does this mapping work? How many DOM objects are
>> being created and what does the drawing, SVG?
>>
>> Usually only one DOM object, but that can be different in each
> DisplayObject subclass.
> The actual drawing (flash.display.Graphics) is always done through a canvas
> (which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite
> consists of a <div> container with a <canvas> for rendering and more DOM
> elements for all contained child-DOs.
> Because in typical gaming scenarios, this approach led to a lot of canvases
> being created and turned out to be slow and memory-consuming, I implemented
> a mode where a complete DisplayList-subtree (well, the thing called
> DisplayList actually is a tree!) is rendered into a single canvas. This is
> the approach taken by DartFlash and works extremely well for games and
> animations where almost all DOs are graphics or simple text, but is not so
> good for interactive components like TextField, where you would have to
> emulate all the interactive behavior on a low-level basis (blinking cursor
> etc.).
> Since it seems none of the two solutions is always preferable, I now let
> the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
> activates canvas mode for that DL-subtree, but other parts of the DL can
> still use DOM-mode, so you can mix-and-match graphics and interactive parts
> of your UI.
> Note however that the DOM-mode supports less Flash features and has several
> known bugs concerning scaling and rotation (it is really tough to map these
> on CSS3 transforms and it turned out to be much easier when using canvas 2D
> API). It might even be that after the canvas-refactoring, DOM-mode work
> worse than before...
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Btw, since only the "cacheAsBitmap" feature and the Graphics implementation
use canvas, it is completely possible to implement SVG rendering as an
alternative. The "cacheAsBitmap" flag of a flash.display.Bitmap object
could be used as the switch whether to use canvas or SVG.
On Fri, Nov 30, 2012 at 11:40 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
>> > Primarily, I also map DOs to DOM elements!
>> >
>> > Greetings
>> > -Frank-
>> Just curious, but how does this mapping work? How many DOM objects are
>> being created and what does the drawing, SVG?
>>
>> Usually only one DOM object, but that can be different in each
> DisplayObject subclass.
> The actual drawing (flash.display.Graphics) is always done through a
> canvas (which is, of course, also a DOM element!). Thus, in DOM-mode, a
> Sprite consists of a <div> container with a <canvas> for rendering and more
> DOM elements for all contained child-DOs.
> Because in typical gaming scenarios, this approach led to a lot of
> canvases being created and turned out to be slow and memory-consuming, I
> implemented a mode where a complete DisplayList-subtree (well, the thing
> called DisplayList actually is a tree!) is rendered into a single canvas.
> This is the approach taken by DartFlash and works extremely well for games
> and animations where almost all DOs are graphics or simple text, but is not
> so good for interactive components like TextField, where you would have to
> emulate all the interactive behavior on a low-level basis (blinking cursor
> etc.).
> Since it seems none of the two solutions is always preferable, I now let
> the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
> activates canvas mode for that DL-subtree, but other parts of the DL can
> still use DOM-mode, so you can mix-and-match graphics and interactive parts
> of your UI.
> Note however that the DOM-mode supports less Flash features and has
> several known bugs concerning scaling and rotation (it is really tough to
> map these on CSS3 transforms and it turned out to be much easier when using
> canvas 2D API). It might even be that after the canvas-refactoring,
> DOM-mode work worse than before...
>
>
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
Ah ok. Makes sense to me.
We should certainly have support for vector drawing for those who need it.
I'm still going to build the interactive widgets using as much of the native
HTML/HTML5 controls as possible.
Thanks,
-Alex
On 11/30/12 2:40 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
>>> Primarily, I also map DOs to DOM elements!
>>>
>>> Greetings
>>> -Frank-
>> Just curious, but how does this mapping work? How many DOM objects are
>> being created and what does the drawing, SVG?
>>
>> Usually only one DOM object, but that can be different in each
> DisplayObject subclass.
> The actual drawing (flash.display.Graphics) is always done through a canvas
> (which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite
> consists of a <div> container with a <canvas> for rendering and more DOM
> elements for all contained child-DOs.
> Because in typical gaming scenarios, this approach led to a lot of canvases
> being created and turned out to be slow and memory-consuming, I implemented
> a mode where a complete DisplayList-subtree (well, the thing called
> DisplayList actually is a tree!) is rendered into a single canvas. This is
> the approach taken by DartFlash and works extremely well for games and
> animations where almost all DOs are graphics or simple text, but is not so
> good for interactive components like TextField, where you would have to
> emulate all the interactive behavior on a low-level basis (blinking cursor
> etc.).
> Since it seems none of the two solutions is always preferable, I now let
> the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
> activates canvas mode for that DL-subtree, but other parts of the DL can
> still use DOM-mode, so you can mix-and-match graphics and interactive parts
> of your UI.
> Note however that the DOM-mode supports less Flash features and has several
> known bugs concerning scaling and rotation (it is really tough to map these
> on CSS3 transforms and it turned out to be much easier when using canvas 2D
> API). It might even be that after the canvas-refactoring, DOM-mode work
> worse than before...
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>
> > Primarily, I also map DOs to DOM elements!
> >
> > Greetings
> > -Frank-
> Just curious, but how does this mapping work? How many DOM objects are
> being created and what does the drawing, SVG?
>
> Usually only one DOM object, but that can be different in each
DisplayObject subclass.
The actual drawing (flash.display.Graphics) is always done through a canvas
(which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite
consists of a <div> container with a <canvas> for rendering and more DOM
elements for all contained child-DOs.
Because in typical gaming scenarios, this approach led to a lot of canvases
being created and turned out to be slow and memory-consuming, I implemented
a mode where a complete DisplayList-subtree (well, the thing called
DisplayList actually is a tree!) is rendered into a single canvas. This is
the approach taken by DartFlash and works extremely well for games and
animations where almost all DOs are graphics or simple text, but is not so
good for interactive components like TextField, where you would have to
emulate all the interactive behavior on a low-level basis (blinking cursor
etc.).
Since it seems none of the two solutions is always preferable, I now let
the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
activates canvas mode for that DL-subtree, but other parts of the DL can
still use DOM-mode, so you can mix-and-match graphics and interactive parts
of your UI.
Note however that the DOM-mode supports less Flash features and has several
known bugs concerning scaling and rotation (it is really tough to map these
on CSS3 transforms and it turned out to be much easier when using canvas 2D
API). It might even be that after the canvas-refactoring, DOM-mode work
worse than before...
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
Interesting info on this, thanks!
There is also Mozilla Shumway (based on Gordon I believe), which
actually parses and runs SWFs without a need for a head of time AS3->JS
compile, and has a whole Flash API layer (I don't know how complete any
of it is).
How does Shumway compare with the way Jangaroo handles the display list?
Could parts of that project be useful for the SWF/SWC areas of the
FalconJS compiler?
Kevin N.
On 11/30/12 5:25 AM, Frank Wienberg wrote:
> Yes and no. I implemented single-canvas-mode on a branch, but when merging
> into the master, I re-activated the DOM mode.
> Single-canvas-mode is activated by setting cacheAsBitmap on the stage!
>
>
> On Thu, Nov 29, 2012 at 4:47 PM, Kevin Newman <Ca...@unfocus.com> wrote:
>
>> Oh, I thought Jangaroo switched to a single Canvas a while back. I may
>> have introduced that incorrect information. Sorry about that.
>>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Yes and no. I implemented single-canvas-mode on a branch, but when merging
into the master, I re-activated the DOM mode.
Single-canvas-mode is activated by setting cacheAsBitmap on the stage!
On Thu, Nov 29, 2012 at 4:47 PM, Kevin Newman <Ca...@unfocus.com> wrote:
> Oh, I thought Jangaroo switched to a single Canvas a while back. I may
> have introduced that incorrect information. Sorry about that.
>
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
Oh, I thought Jangaroo switched to a single Canvas a while back. I may
have introduced that incorrect information. Sorry about that.
Kevin N.
On 11/29/12 6:31 AM, Frank Wienberg wrote:
> Primarily, I also map DOs to DOM elements!
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Yes I do, I was doing research on this subject.
In fact my project is about something else, high performance application
framework on top of native platforms.
AS a bare bones to make a common ground for development. And trying to
add few new concepts into it.
http://www.bixbite.org/BixBitePresentation.swf (work in progress ;) )
But this little experiment that mimic display list was just to have a
go, prove of concept, In many cases is not even needed for me.
There is a difference between writing API for native platform and let
developers deal with it directly.
Rather than stay with AS3 and compile/interpret into target platform.
And I have to say jangaroo was on my research-in-development bookmarks
for a while as well.
You did big progress from what I remember.
Dan
On 11/29/2012 11:31 AM, Frank Wienberg wrote:
> Dan, are you aware of FlashJS <http://flashjs.com/>?
> Btw, JooFlash also uses canvas optionally, namely for Graphics and if you
> set DisplayObject#cacheAsBitmap to true.
> Primarily, I also map DOs to DOM elements!
>
> Greetings
> -Frank-
>
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> Dan, are you aware of FlashJS <http://flashjs.com/>?
> Btw, JooFlash also uses canvas optionally, namely for Graphics and if you
> set DisplayObject#cacheAsBitmap to true.
> Primarily, I also map DOs to DOM elements!
>
> Greetings
> -Frank-
Just curious, but how does this mapping work? How many DOM objects are
being created and what does the drawing, SVG?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Dan, are you aware of FlashJS <http://flashjs.com/>?
Btw, JooFlash also uses canvas optionally, namely for Graphics and if you
set DisplayObject#cacheAsBitmap to true.
Primarily, I also map DOs to DOM elements!
Greetings
-Frank-
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
One more idea/concept in regards of mimic flash display list.
This is copy paste from my code I am working on. Early prototype stage
but...
http://www.bixbite.org/html/dsp.html
var s,sc;
var max = 1000;
var stage = new Stage();
var time = getTimer();
for (var i = 0; i<max; i++) {
sc = new Sprite();
sc.graphics.beginFill(0x444444, 1);
sc.graphics.drawRect(0,0,50,50);
sc.x = Math.random()*1900;
sc.y = Math.random()*800;
stage.addChild(sc);
s = new Shape();
s.graphics.beginFill(0xFF0000, 1);
s.graphics.drawRect(-20,-20,40,40);
s.x = 25;
s.y = 25;
s.rotation = 45;
sc.addChild(s);
}
trace("TIME: " + (getTimer()-time));
I bet you could easily confuse it with Action Script. And yes it's a display-list-like 4kb API using DOM not canvas.
I don't even need compiler to translate my code, just getting rid of :Type.
Here is another example:
http://www.bixbite.org/html/dsp2.html
And that thing is using TweenLite port to JS to move stuff around.
Dan
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
What I am trying to understand in regards to this.
Is it, that AS3 -> AST needs to deal with those but AST->JS simply
ignore it?
AS3 -> AST -> JS
Type safe we don't care
as long output represents input? Abstract syntax tree is abstract by
definition right?
On 11/29/2012 8:26 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 8:45 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> Well, there is the JavaScript operator "instanceof", what's wrong with
>> that?
>>
> Nothing, but it only works when you actually use the
> prototype chain, not when you copy all members from
> the superclass to the subclass.
> Also, when using ActionScript, you will want to use "is"
> for interfaces, where "instanceof" does not work.
> Bernd Paradies points out in his
> blog<http://blogs.adobe.com/bparadie/2012/10/21/kicking-typescipts-tires/>that
> a real drawback
> of TypeScript is that there is no runtime type information
> about interfaces. The Jangaroo Compiler + Runtime
> implement the "is" and "as" operators to work with
> interfaces seamlessly and efficiently!
>
> Greetings,
> -Frank-
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 8:45 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Well, there is the JavaScript operator "instanceof", what's wrong with
> that?
>
Nothing, but it only works when you actually use the
prototype chain, not when you copy all members from
the superclass to the subclass.
Also, when using ActionScript, you will want to use "is"
for interfaces, where "instanceof" does not work.
Bernd Paradies points out in his
blog<http://blogs.adobe.com/bparadie/2012/10/21/kicking-typescipts-tires/>that
a real drawback
of TypeScript is that there is no runtime type information
about interfaces. The Jangaroo Compiler + Runtime
implement the "is" and "as" operators to work with
interfaces seamlessly and efficiently!
Greetings,
-Frank-
Re: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> That said, because we are cross compiling AS, does the classic route support
> as many features of AS, especially the reflection-oriented features? We
> want to try to compile business logic untouched and it might be using "is",
> "in", "instanceof", etc. Resig's blog seems to indicate that support for
> instanceOf was important and required all of that code.
Well, there is the JavaScript operator "instanceof", what's wrong with that?
Stuff like 'is', 'as' and 'in' we'll need to syntactically work
around, just like we do with class creation, constructors etc., no big
deal, the compiler should be able to take care of that.
As to classic vs. other routes, a final thought: while bare bones
performance might favour one over the other, we also have to take into
account that probably 99% of performance gain or loss will be due to
feature implementation, not the way we choose to implement a specific
language feature (inheritance, class creation etc.). Also, things like
easy of coding and maintenance are major factors.
Having said all that, I think the bottom line is that there is already
a lot of work done to make the current solution happen. I have looked
at it in dept yesterday and can't find any major fault, although some
of the design decisions might not have been my own. Then again, I
don't know all the considerations that went into it, nor am I familiar
with the limitations (if any) of the compiler. I am happy with take
the current solution forward instead of starting from scratch.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/29/2012 12:59 PM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> It's not that you can't use a framework and "vanilla" js...
>
> Yeah, we use this framework: http://vanilla-js.com/
> ;-)
>
Hehe, me too without even knowing ;)
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> It's not that you can't use a framework and "vanilla" js...
Yeah, we use this framework: http://vanilla-js.com/
;-)
Re: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Actually, the third argument of 'adobe.extend()' is what can probably
considered "the rest" of the output of the JSEmitter (yes, Mike, it
did make a little more sense). And that "the rest: is a "simple"
object literal, which can easily be parse (as the 'extend' method
does).
If you want to change stuff on the JS side, all you need to do is
replace the implementation of the 'adobe' object methods, leaving the
"API" (basically 'extend' and a few utility methods) untouched. I
don't suggest this as a permanent solution, but while better minds
than mine are working on getting the compiler under control it does
provide a method to experiment with the JS side of things.
EdB
On Thu, Nov 29, 2012 at 2:48 PM, Daniel Wasilewski <de...@gmail.com> wrote:
> On 11/29/2012 1:36 PM, Michael Schmalle wrote:
>>
>>
>>
>> Laymans; A SWF is created for all classes just like in MXMLC, there is a
>> visitor pattern that is used that traverses the internals of the ISWF. As
>> each of the elements in the SWF are traversed (classes, methods, members
>> etc) calls to the JSEmitter and other classes happens and the js is created
>> during the traversal.
>>
> And this is the place 'JSEmitter ' that has the JS grammar rules specified,
> but instead spiting out pure JS syntax it relies on little adobe.js that
> simplifies the process and grammar rules. Am I right? if so, How hard it
> would be to make it adobe.js independent, if too hard, adobe.js would be a
> subject to change/polishing up, we just need to know what fields JSEmiter is
> expecting to match.
>
>> JBurg is compiled to actually create the class and rules that does the
>> actual traversal logic through the SWF file.
>>
>> Does that make more sense?
>>
>> Mike
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/29/2012 1:36 PM, Michael Schmalle wrote:
>
>
> Laymans; A SWF is created for all classes just like in MXMLC, there is
> a visitor pattern that is used that traverses the internals of the
> ISWF. As each of the elements in the SWF are traversed (classes,
> methods, members etc) calls to the JSEmitter and other classes happens
> and the js is created during the traversal.
>
And this is the place 'JSEmitter ' that has the JS grammar rules
specified, but instead spiting out pure JS syntax it relies on little
adobe.js that simplifies the process and grammar rules. Am I right? if
so, How hard it would be to make it adobe.js independent, if too hard,
adobe.js would be a subject to change/polishing up, we just need to know
what fields JSEmiter is expecting to match.
> JBurg is compiled to actually create the class and rules that does the
> actual traversal logic through the SWF file.
>
> Does that make more sense?
>
> Mike
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> "The SWF file is then used to write out the js using a JBurg bottom up
> reducer/emitter." ;-)
Laymans; A SWF is created for all classes just like in MXMLC, there is
a visitor pattern that is used that traverses the internals of the
ISWF. As each of the elements in the SWF are traversed (classes,
methods, members etc) calls to the JSEmitter and other classes happens
and the js is created during the traversal.
JBurg is compiled to actually create the class and rules that does the
actual traversal logic through the SWF file.
Does that make more sense?
Mike
> That means so little to me, while it probably explains everything to
> someone with the proper background. I'll try to get some more
> background, so I may be of some use when the time comes to start
> hacking the JS output.
>
> EdB
>
>
> On Thu, Nov 29, 2012 at 2:22 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> Well you may have missed it since this thread is going forever but I did
>> write something [0]
>>
>> There was one concept I screwed up and that is in the end the loop and write
>> doesn't happen on the monolithic SWF, I think it's for external files that
>> were not linked into the main SWF.
>>
>> Basically, the compiler loads like MXMLC, using configuration files and args
>> passed to it.
>>
>> It the parses all files and then creates an SWF of those files with
>> dependencies.
>>
>> The SWF file is then used to write out the js using a JBurg bottom up
>> reducer/emitter. I am sure these were the classes you were looking at.
>>
>> The JSEmitter is something that probably could be hacked into but, I would
>> make sure you have a baseline before you do.
>>
>> The thing is, everytime I write about this framework I am learning more. It
>> seems to me the IBackend interface could be golden.
>>
>> If you look the Only time JSEmitter is created is in a call to;
>>
>> - JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
>>
>> This means we could swap out emitters at runtime! I still need to
>> investigate this further and don't take anything I say as gold right now,
>> I'm still learning myself.
>>
>> NOTE: The first thing I am going to experiement with is "how modular" the
>> IBackend really is and what it would enable us todo as far as creating
>> different implementations of emitters.
>>
>> Mike
>>
>>
>>
>>
>>
>>
>> - [0]
>> http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
>>
>>
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>> Mike,
>>>
>>> Can you explain a little bit (maybe in pseudo-code or whatever) about
>>> how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
>>> What I'm looking for is an idea of how the JS output is put together,
>>> if you will. Example: how easy (or difficult) is it to exchange one JS
>>> "class" creation method for another? Right now it's "Class =
>>> adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
>>> change that output to something like "function Class() { theClassBody
>>> }"?
>>>
>>> I did look at some of the Java classes that seemed relevant, but soon
>>> realised that without first having some idea of the concepts involved,
>>> "use the Force, read the source" wasn't going to be a useful way to
>>> spend my time ;-)
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
>>> <ap...@teotigraphix.com> wrote:
>>>>
>>>> It's not that you can't use a framework and "vanilla" js, it's that it
>>>> has
>>>> been shown that these candy frameworks that hide vanilla method calls to
>>>> the
>>>> DOM severely kill performance. ... For the sake of just entering a $()
>>>> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
>>>> alittle dev time saved, you kill the actual applications performance.
>>>>
>>>> I was just saying that using AS, you can already have a "framework" you
>>>> use
>>>> that is light, but the compiler would transcode it to the fastest
>>>> possible
>>>> js implementation, since it's now hands off.
>>>>
>>>> Mike
>>>>
>>>>
>>>> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>>>>
>>>>> Funniest site I've been to today. It's a good point, but it's prob
>>>>> pretty
>>>>> difficult to not use a framework at all.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>>>>> Mclean
>>>>> Sent: Wednesday, November 28, 2012 18:21
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: Re: [FalconJS] concepts
>>>>>
>>>>> Hi,
>>>>>
>>>>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>>>>> one:
>>>>>> http://jsperf.com/jqury-vs-plainjs
>>>>>
>>>>>
>>>>>
>>>>> Slightly off topic but amusing all the same:
>>>>> http://vanilla-js.com
>>>>>
>>>>> Reinforces the point that if you want pure performance don't use a
>>>>> framework and as we're generating the JS there's probably no need to use
>>>>> one, especially one as heavy as jQuery.
>>>>>
>>>>> Justin
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
"The SWF file is then used to write out the js using a JBurg bottom up
reducer/emitter." ;-)
That means so little to me, while it probably explains everything to
someone with the proper background. I'll try to get some more
background, so I may be of some use when the time comes to start
hacking the JS output.
EdB
On Thu, Nov 29, 2012 at 2:22 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Well you may have missed it since this thread is going forever but I did
> write something [0]
>
> There was one concept I screwed up and that is in the end the loop and write
> doesn't happen on the monolithic SWF, I think it's for external files that
> were not linked into the main SWF.
>
> Basically, the compiler loads like MXMLC, using configuration files and args
> passed to it.
>
> It the parses all files and then creates an SWF of those files with
> dependencies.
>
> The SWF file is then used to write out the js using a JBurg bottom up
> reducer/emitter. I am sure these were the classes you were looking at.
>
> The JSEmitter is something that probably could be hacked into but, I would
> make sure you have a baseline before you do.
>
> The thing is, everytime I write about this framework I am learning more. It
> seems to me the IBackend interface could be golden.
>
> If you look the Only time JSEmitter is created is in a call to;
>
> - JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
>
> This means we could swap out emitters at runtime! I still need to
> investigate this further and don't take anything I say as gold right now,
> I'm still learning myself.
>
> NOTE: The first thing I am going to experiement with is "how modular" the
> IBackend really is and what it would enable us todo as far as creating
> different implementations of emitters.
>
> Mike
>
>
>
>
>
>
> - [0]
> http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
>
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Mike,
>>
>> Can you explain a little bit (maybe in pseudo-code or whatever) about
>> how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
>> What I'm looking for is an idea of how the JS output is put together,
>> if you will. Example: how easy (or difficult) is it to exchange one JS
>> "class" creation method for another? Right now it's "Class =
>> adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
>> change that output to something like "function Class() { theClassBody
>> }"?
>>
>> I did look at some of the Java classes that seemed relevant, but soon
>> realised that without first having some idea of the concepts involved,
>> "use the Force, read the source" wasn't going to be a useful way to
>> spend my time ;-)
>>
>> EdB
>>
>>
>>
>> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>> It's not that you can't use a framework and "vanilla" js, it's that it
>>> has
>>> been shown that these candy frameworks that hide vanilla method calls to
>>> the
>>> DOM severely kill performance. ... For the sake of just entering a $()
>>> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
>>> alittle dev time saved, you kill the actual applications performance.
>>>
>>> I was just saying that using AS, you can already have a "framework" you
>>> use
>>> that is light, but the compiler would transcode it to the fastest
>>> possible
>>> js implementation, since it's now hands off.
>>>
>>> Mike
>>>
>>>
>>> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>>>
>>>> Funniest site I've been to today. It's a good point, but it's prob
>>>> pretty
>>>> difficult to not use a framework at all.
>>>>
>>>> -----Original Message-----
>>>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>>>> Mclean
>>>> Sent: Wednesday, November 28, 2012 18:21
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: Re: [FalconJS] concepts
>>>>
>>>> Hi,
>>>>
>>>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>>>> one:
>>>>> http://jsperf.com/jqury-vs-plainjs
>>>>
>>>>
>>>>
>>>> Slightly off topic but amusing all the same:
>>>> http://vanilla-js.com
>>>>
>>>> Reinforces the point that if you want pure performance don't use a
>>>> framework and as we're generating the JS there's probably no need to use
>>>> one, especially one as heavy as jQuery.
>>>>
>>>> Justin
>>>>
>>>>
>>>
>>> --
>>> 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
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Well you may have missed it since this thread is going forever but I
did write something [0]
There was one concept I screwed up and that is in the end the loop and
write doesn't happen on the monolithic SWF, I think it's for external
files that were not linked into the main SWF.
Basically, the compiler loads like MXMLC, using configuration files
and args passed to it.
It the parses all files and then creates an SWF of those files with
dependencies.
The SWF file is then used to write out the js using a JBurg bottom up
reducer/emitter. I am sure these were the classes you were looking at.
The JSEmitter is something that probably could be hacked into but, I
would make sure you have a baseline before you do.
The thing is, everytime I write about this framework I am learning
more. It seems to me the IBackend interface could be golden.
If you look the Only time JSEmitter is created is in a call to;
- JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
This means we could swap out emitters at runtime! I still need to
investigate this further and don't take anything I say as gold right
now, I'm still learning myself.
NOTE: The first thing I am going to experiement with is "how modular"
the IBackend really is and what it would enable us todo as far as
creating different implementations of emitters.
Mike
- [0]
http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Mike,
>
> Can you explain a little bit (maybe in pseudo-code or whatever) about
> how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
> What I'm looking for is an idea of how the JS output is put together,
> if you will. Example: how easy (or difficult) is it to exchange one JS
> "class" creation method for another? Right now it's "Class =
> adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
> change that output to something like "function Class() { theClassBody
> }"?
>
> I did look at some of the Java classes that seemed relevant, but soon
> realised that without first having some idea of the concepts involved,
> "use the Force, read the source" wasn't going to be a useful way to
> spend my time ;-)
>
> EdB
>
>
>
> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> It's not that you can't use a framework and "vanilla" js, it's that it has
>> been shown that these candy frameworks that hide vanilla method calls to the
>> DOM severely kill performance. ... For the sake of just entering a $()
>> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
>> alittle dev time saved, you kill the actual applications performance.
>>
>> I was just saying that using AS, you can already have a "framework" you use
>> that is light, but the compiler would transcode it to the fastest possible
>> js implementation, since it's now hands off.
>>
>> Mike
>>
>>
>> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>>
>>> Funniest site I've been to today. It's a good point, but it's prob pretty
>>> difficult to not use a framework at all.
>>>
>>> -----Original Message-----
>>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>>> Mclean
>>> Sent: Wednesday, November 28, 2012 18:21
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: [FalconJS] concepts
>>>
>>> Hi,
>>>
>>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>>> one:
>>>> http://jsperf.com/jqury-vs-plainjs
>>>
>>>
>>> Slightly off topic but amusing all the same:
>>> http://vanilla-js.com
>>>
>>> Reinforces the point that if you want pure performance don't use a
>>> framework and as we're generating the JS there's probably no need to use
>>> one, especially one as heavy as jQuery.
>>>
>>> Justin
>>>
>>>
>>
>> --
>> 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: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
Can you explain a little bit (maybe in pseudo-code or whatever) about
how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
What I'm looking for is an idea of how the JS output is put together,
if you will. Example: how easy (or difficult) is it to exchange one JS
"class" creation method for another? Right now it's "Class =
adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
change that output to something like "function Class() { theClassBody
}"?
I did look at some of the Java classes that seemed relevant, but soon
realised that without first having some idea of the concepts involved,
"use the Force, read the source" wasn't going to be a useful way to
spend my time ;-)
EdB
On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> It's not that you can't use a framework and "vanilla" js, it's that it has
> been shown that these candy frameworks that hide vanilla method calls to the
> DOM severely kill performance. ... For the sake of just entering a $()
> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
> alittle dev time saved, you kill the actual applications performance.
>
> I was just saying that using AS, you can already have a "framework" you use
> that is light, but the compiler would transcode it to the fastest possible
> js implementation, since it's now hands off.
>
> Mike
>
>
> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>
>> Funniest site I've been to today. It's a good point, but it's prob pretty
>> difficult to not use a framework at all.
>>
>> -----Original Message-----
>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>> Mclean
>> Sent: Wednesday, November 28, 2012 18:21
>> To: flex-dev@incubator.apache.org
>> Subject: Re: [FalconJS] concepts
>>
>> Hi,
>>
>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>> one:
>>> http://jsperf.com/jqury-vs-plainjs
>>
>>
>> Slightly off topic but amusing all the same:
>> http://vanilla-js.com
>>
>> Reinforces the point that if you want pure performance don't use a
>> framework and as we're generating the JS there's probably no need to use
>> one, especially one as heavy as jQuery.
>>
>> Justin
>>
>>
>
> --
> 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: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
It's not that you can't use a framework and "vanilla" js, it's that it
has been shown that these candy frameworks that hide vanilla method
calls to the DOM severely kill performance. ... For the sake of just
entering a $() dollar sign? That's a crazy tradeoff but thousands do
it everyday. For alittle dev time saved, you kill the actual
applications performance.
I was just saying that using AS, you can already have a "framework"
you use that is light, but the compiler would transcode it to the
fastest possible js implementation, since it's now hands off.
Mike
Quoting Kessler CTR Mark J <ma...@usmc.mil>:
> Funniest site I've been to today. It's a good point, but it's prob
> pretty difficult to not use a framework at all.
>
> -----Original Message-----
> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of
> Justin Mclean
> Sent: Wednesday, November 28, 2012 18:21
> To: flex-dev@incubator.apache.org
> Subject: Re: [FalconJS] concepts
>
> Hi,
>
>> And to eliminate the 'IF' from your conditional statement, just a quick one:
>> http://jsperf.com/jqury-vs-plainjs
>
> Slightly off topic but amusing all the same:
> http://vanilla-js.com
>
> Reinforces the point that if you want pure performance don't use a
> framework and as we're generating the JS there's probably no need to
> use one, especially one as heavy as jQuery.
>
> Justin
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FalconJS] concepts
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Funniest site I've been to today. It's a good point, but it's prob pretty difficult to not use a framework at all.
-----Original Message-----
From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin Mclean
Sent: Wednesday, November 28, 2012 18:21
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJS] concepts
Hi,
> And to eliminate the 'IF' from your conditional statement, just a quick one:
> http://jsperf.com/jqury-vs-plainjs
Slightly off topic but amusing all the same:
http://vanilla-js.com
Reinforces the point that if you want pure performance don't use a framework and as we're generating the JS there's probably no need to use one, especially one as heavy as jQuery.
Justin
Re: [FalconJS] concepts
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> And to eliminate the 'IF' from your conditional statement, just a quick one:
> http://jsperf.com/jqury-vs-plainjs
Slightly off topic but amusing all the same:
http://vanilla-js.com
Reinforces the point that if you want pure performance don't use a framework and as we're generating the JS there's probably no need to use one, especially one as heavy as jQuery.
Justin
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 1:35 AM, Daniel Wasilewski <de...@gmail.com>wrote:
> Man, what can I say, I love you :)
>
>
> On 11/29/2012 12:13 AM, Frank Wienberg wrote:
>
>> ...Open Flash Charts<http://jangaron.net/**ofc3/data-files/joo.html<http://jangaron.net/ofc3/data-files/joo.html>
>> >
>>
>
Thanks! :-)
Did you check out the animations, e.g. "pie-bug-green"? OFC uses a
tweening<https://code.google.com/p/tweener/>
library <https://code.google.com/p/tweener/>, completely written in AS3,
which again is using the (Joo)Flash API,
which again is drawing on an HTML5 canvas.
Despite of the many abstraction layers, it even works fast enough on an
iPad 2.
So why should we need jQuery animations?!
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Man, what can I say, I love you :)
On 11/29/2012 12:13 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 12:51 AM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> One question straight away after looking at your source code
>> implementation.
>>
>> Why did you have to implement custom display list for AS3 itself?
>>
> Do you mean JooFlash? Well, Adobe still did not open-source the Flash
> runtime, so we had to re-implement it. I wrote a tool that "screen-scraped"
> the whole FlashPlayer 11 API from the HTML ASDoc and reverse-engineers it
> into AS3 code -- of course API-only, and started to fill the gaps. As you
> can see, it suffices for several games, Box2D and Open Flash Charts, but
> not yet for Flex.
>
>
>> Was my assumption correct? That you were trying to bridge a gaps? If so,
>> how much effort it would be to do the same with mxml?
>>
>> Actually, I am currently working on MXML support for the Jangaroo
> compiler. Another case of redoing Adobe's work! ;-)
> But really, until now, we did not dare to dig into the Flex compiler code,
> and what I read in this mailing list is not very encouraging, too.
> Thus, so far, we kept our own compiler, which is much more light-weight and
> controllable (at least for us), but of course lacks some important features
> and is still not 100% compatible with mxmlc. However, we were able to take
> quite complex AS3 projects and recompile them without changing a single
> line of code, e.g. Open Flash
> Charts<http://jangaron.net/ofc3/data-files/joo.html>
> .
> More about this in my upcoming answer to Michael.
>
> -Frank-
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 12:51 AM, Daniel Wasilewski <de...@gmail.com>wrote:
> One question straight away after looking at your source code
> implementation.
>
> Why did you have to implement custom display list for AS3 itself?
>
Do you mean JooFlash? Well, Adobe still did not open-source the Flash
runtime, so we had to re-implement it. I wrote a tool that "screen-scraped"
the whole FlashPlayer 11 API from the HTML ASDoc and reverse-engineers it
into AS3 code -- of course API-only, and started to fill the gaps. As you
can see, it suffices for several games, Box2D and Open Flash Charts, but
not yet for Flex.
> Was my assumption correct? That you were trying to bridge a gaps? If so,
> how much effort it would be to do the same with mxml?
>
> Actually, I am currently working on MXML support for the Jangaroo
compiler. Another case of redoing Adobe's work! ;-)
But really, until now, we did not dare to dig into the Flex compiler code,
and what I read in this mailing list is not very encouraging, too.
Thus, so far, we kept our own compiler, which is much more light-weight and
controllable (at least for us), but of course lacks some important features
and is still not 100% compatible with mxmlc. However, we were able to take
quite complex AS3 projects and recompile them without changing a single
line of code, e.g. Open Flash
Charts<http://jangaron.net/ofc3/data-files/joo.html>
.
More about this in my upcoming answer to Michael.
-Frank-
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
One question straight away after looking at your source code implementation.
Why did you have to implement custom display list for AS3 itself?
Was my assumption correct? That you were trying to bridge a gaps? If so,
how much effort it would be to do the same with mxml?
Dan
On 11/28/2012 11:43 PM, Frank Wienberg wrote:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hi Frank,
I was just looking at your code today in GIT, all I can say is what a
great job coding that!!! Seriously I have always loved AS3 AST and
code generation I have some experience as well and I was actually
looking at your visitor/sink pattern today for ideas!
I have gone through your whole code generation framework today, I
would love to see if we could collaborate on something because you
have put so much work into it and obviously love ActionScript as well.
How do you think this project and your project could create some type
of symbiotic relationship without completely redoing each others
efforts?
Thanks for being so upfront, I think both project have the same goals.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
>
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
>
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
>
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Here we go! welcome on board :)
On 11/28/2012 11:43 PM, Frank Wienberg wrote:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Thanks for the pointer, Alex! I'll hand it on to Andreas Gawecki who is the
Jangaroo compiler guy.
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Right,
Yeah, comparing the old MXMLC compiler to Falcon MXMLC code base is
like going from a stone cave to a highrise building in terms of
engineering.
It uses JFlex to create the tokenizer so there is not lexer from antlr.
Anyway, others... I am not saying ditch work that has been done on
FalconJS and what it does, I'm going to experiment with Jangaroo and
there YEARS of development to see what I might come up with as far as
JS generation.
Besides in the end, there could always be "options". I want to be able
to work on coding something, this I can get right to work trying out
some ideas.
As with GCC, I haven't read enough about it but, sounds like I will
need to research it as well.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Thu, Nov 29, 2012 at 1:44 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> I bet if I had some time I could port some of your generation code using
>> the Falcon AST.
>
>
> Mike, that would be the way to go!
> I believe every word you say about the Falcon compiler, since my
> information about the Flex compiler is surely outdated. I guess they were
> not using ANTLR back then and the whole architecture has been cleaned up in
> the meantime.
> We wanted to have had a closer look recently, but honestly we did not know
> where to start.
> Sounds to me like in a common effort, it should be possible to join Falcon
> and Jangaroo's AST-based JS code generation! Wow!
>
> Concerning GCC, it is said to have the best compression factor in the
> market when using "advanced optimizations", which only work when providing
> the correct type hints, so we would have to generate these like Bernd
> proposed on his FalconJS blog. And GCC has some real cool features like it
> can output JavaScript source
> maps<http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/>,
> which again is the optimal way to support debugging generated JS code
> directly in the browser. However, for this feature, I would not run the
> generated JS code through GCC, but experimented with reusing their Java
> library for creating the source maps directly during code generation (this
> is on a branch called "source-maps" in the jangaroo-tools github project).
>
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 5:03 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> On Thu, Nov 29, 2012 at 1:44 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> I bet if I had some time I could port some of your generation code using
>> the Falcon AST.
>
>
> Mike, that would be the way to go!
> I believe every word you say about the Falcon compiler, since my
> information about the Flex compiler is surely outdated. I guess they were
> not using ANTLR back then and the whole architecture has been cleaned up in
> the meantime.
I'm not sure what Flex compiler source you looked at and when, but Falcon is
a complete rewrite. We tossed out the MXMLC code base that compiles every
Flex app to date. Falcon is still under development and yet to be released.
> We wanted to have had a closer look recently, but honestly we did not know
> where to start.
Start with the Falcon folder in Apache Flex SVN.
> Sounds to me like in a common effort, it should be possible to join Falcon
> and Jangaroo's AST-based JS code generation! Wow!
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 1:44 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> I bet if I had some time I could port some of your generation code using
> the Falcon AST.
Mike, that would be the way to go!
I believe every word you say about the Falcon compiler, since my
information about the Flex compiler is surely outdated. I guess they were
not using ANTLR back then and the whole architecture has been cleaned up in
the meantime.
We wanted to have had a closer look recently, but honestly we did not know
where to start.
Sounds to me like in a common effort, it should be possible to join Falcon
and Jangaroo's AST-based JS code generation! Wow!
Concerning GCC, it is said to have the best compression factor in the
market when using "advanced optimizations", which only work when providing
the correct type hints, so we would have to generate these like Bernd
proposed on his FalconJS blog. And GCC has some real cool features like it
can output JavaScript source
maps<http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/>,
which again is the optimal way to support debugging generated JS code
directly in the browser. However, for this feature, I would not run the
generated JS code through GCC, but experimented with reusing their Java
library for creating the source maps directly during code generation (this
is on a branch called "source-maps" in the jangaroo-tools github project).
-Frank-
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Totally agreed, Mike! We're facing a great opportunity, but also a big
> challenge.
> Adobe's code is, especially considering the lack of a language
> specification, the best you can get to parse ActionScript 3.
I have written an AS3.g (1600 lines) file with a rewrite tree, I know
how bad the language is. BTW, Falcon uses an antlr grammar for the
parser, did you know that?
However, when
> we (especially Andreas Gawecki, the original author of the Jangaroo
> compiler) looked at the Flex compiler code, we found it quite complex and
> wondered why no grammer / parser generator had been used. It all seems
> hand-coded. So we decided to stick with our compiler, at least for a while.
> Also, we did not want to emulate SWF / SWC, but rely on generated JS code +
> AS3 API stubs. All relevant tools can handle that very well: we use ASDoc
> and IntelliJ IDEA's ActionScript support successfully. We only had to
> create Jangaroo-specific build-tool support, namely a Maven plugin.
> So both compilers have their advantages, and we would like to unite them,
> but that seems like a long way to go.
I don't think so. The Falcon compiler has a two APIs, ast nodes(low
level) and definition nodes(high level). It is a very robust design.
> Can somebody explain why it is not easy or even not possible to use Falcon
> to create the AST and refactor the Jangaroo JSCodeGenerator from the
> Jangaroo-AST to the Falcon-AST to produce the JS output? I don't really get
> the SWF/JBurg part...
I think as far as AST we could do anything, I love the Falcon
compiler. I think the way JS is created AFTER the compile sucks.
I bet if I had some time I could port some of your generation code
using the Falcon AST.
Maybe there is a translation thing happening here, I didn't say that
it's not easy to create falcon AST, I said the processing step AFTER
AST creation is convoluted in my opinion. It's not accessible to the
average higher level dev.
JBurg is used to create a reducer and emitter for js source code.
> One thing that's good in FalconJS and missing in Jangaroo is to produce
> output that Google Closure Compiler can optimize well. I think it should
> not be too hard, but it seems to conflict with Jangaroo's goal to keep the
> output format as close as possible to the AS source code, and of course it
> has to be done.
I can't comment on this since I'm not to versed in JS.
Mike
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Totally agreed, Mike! We're facing a great opportunity, but also a big
challenge.
Adobe's code is, especially considering the lack of a language
specification, the best you can get to parse ActionScript 3. However, when
we (especially Andreas Gawecki, the original author of the Jangaroo
compiler) looked at the Flex compiler code, we found it quite complex and
wondered why no grammer / parser generator had been used. It all seems
hand-coded. So we decided to stick with our compiler, at least for a while.
Also, we did not want to emulate SWF / SWC, but rely on generated JS code +
AS3 API stubs. All relevant tools can handle that very well: we use ASDoc
and IntelliJ IDEA's ActionScript support successfully. We only had to
create Jangaroo-specific build-tool support, namely a Maven plugin.
So both compilers have their advantages, and we would like to unite them,
but that seems like a long way to go.
Can somebody explain why it is not easy or even not possible to use Falcon
to create the AST and refactor the Jangaroo JSCodeGenerator from the
Jangaroo-AST to the Falcon-AST to produce the JS output? I don't really get
the SWF/JBurg part...
One thing that's good in FalconJS and missing in Jangaroo is to produce
output that Google Closure Compiler can optimize well. I think it should
not be too hard, but it seems to conflict with Jangaroo's goal to keep the
output format as close as possible to the AS source code, and of course it
has to be done.
-Frank-
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I hate adding on to my own reply but I have on more comment on this.
As Dan and I were discussing and others as well, performance.
Obviously browser execution is top most priority but what about the
other performance not mentioned... the community contributions.
If you have something as complex as what FlaconJS is on the backend,
with 1 maybe two part time developers to push it forward only because
they are the only ones that understand it (JBurg, SWF). Then where
does this actually leav the performance of the project as a whole?
Dead locked in stale code as the months and years role by.
I'm usually not this passionate about something but, I think it would
be a serious mistake to count on FalconJS in it's current
implementation. I have years of experience in a different area then
the professional engineers, which just means maybe I have a unique
perspective here.
So bottom line is, I really think we need to think about whether the
current js generation of js or whatever other platform we do is
feasible to carry on into the future being maintained by developers
that may not have a computer science degree.
Long story short, by not choosing the correct implementation of the
cross compiler now, we could seriously be affecting the other
performance area of this project in the future, lets not neglect this
important area.
Go look at TypeScript's parser and emitters, they use the same visitor
pattern using straight AST!
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
> jangaroo/jooc/backend/JsCodeGenerator.java
>
> This is the exact pattern I was talking about implementing. I think
> it's so solid and you have done a great job at implementing it.
>
> As I have said in previous posts today, The way FalconJS digests
> it's AST is through SWF visitors. You are using straight AST from
> your parser.
>
> Folks, having Frank drop this line and the discussions going on at
> the moment, there are definitely a couple different paths that can
> be taken with producing javascript.
>
> If I have my way we would use an implementation like Franks, the
> problem with it as it stands in Apache is there is no infrastructure
> built like Frank has built, this is why the engineers used an SWF to
> represent that infrastructure.
>
> The problem with the current SWF/JBurg implementation is it VERY
> confusing for most developers. With Franks implementation I was able
> to understand what he was doing today within 20 minutes and could
> jump right in and start coding things. With the current FalconJS
> emitters there is no way that would happen.
>
> So, I would love to see if we could think about a common goal to
> energize both projects and see where one could help the other. I
> truly believe now by looking at the code BEFORE this post our
> projects have the exact same goal but can do different things.
>
> Mike
>
>
>
>
>
>
>
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> Hi folks,
>>
>> here is another "outsider" who would like to contribute to the JS runtime
>> format, if you are interested.
>> I am co-founder of the Open Source project Jangaroo, and as such have been
>> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
>> In response to Bernd Paradies blogging about FalconJS, I blogged about
>> "simulating ActionScript 3 language features" extensively:
>>
>> -
>>
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
>> -
>>
>> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
>> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
>> -
>>
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>>
>> All described solutions are actually implemented in the Jangaroo Runtime,
>> which takes care of the code translated from AS3 to JS by the Jangaroo
>> Compiler coming alive.
>> In principle, we follow the "classic route", with the exception of how we
>> simulate private members: see the first two blog posts.
>> At first look the Jangaroo Runtime may seem overly complex to you, but it
>> does many more things (class loading / dependency management; class
>> initialization = execute static code at the right time; allow keeping
>> generated JS code and source AS3 code as similar as possible; automatic
>> method binding / correct "this", etc.), and the concepts described in the
>> blob posts also work without these additional features.
>> The Jangaroo Compiler is written in Java and has a separate code generator
>> (well you obviously won't need the parser) which might be worth having a
>> look at:
>> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
>> If you dare to use Maven ;-), it is really easy to play around with our
>> code generation: Just set up your own projects within minutes, starting
>> from an example project like
>> https://github.com/fwienber/jooflash-app-template or
>> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>>
>> Greetings,
>> -Frank-
>>
>> Frank Wienberg
>> Software Architect & Jangaroo Evangelist
>>
>> *frank.wienberg@coremedia.com*
>>
>> * frank@jangaroo <fr...@jangaroo.net>.net*
>>
>> CoreMedia AG
>> content | context | conversion
>>
>> Ludwig-Erhard-Str. 18
>> 20459 Hamburg, Germany
>> www.coremedia.com
>>
>> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
>> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
>> Trade Register: Amtsgericht Hamburg, HR B 76277
>> --------------------------------------------------------
>>
>
> --
> 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: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 4:44 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> Dan,
>
> I am completely with you in ditching jQuery for FalconJS.
I'm not at all clear that the Jquery code path in the donation works. I'm
sure it did when Bernd did his demo, but I have not tested it in the
donation.
And I'm not particularly interested in using it either.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Dan,
I am completely with you in ditching jQuery for FalconJS. While we would
have to deal with some cross-browser issues ourselves, jQuery is mainly
tailored at providing convenience for JavaScript developers. That
convenience is not necessary for ActionScript/Flex developers, since many
features are already in the language, and others are in the libraries (e.g.
Flash DisplayList). For Jangaroo, we refrained from using any JavaScript
library, but only provide the basic browser APIs
(jangaroo-libs/jangaroo-browser) and, on top of these, I implemented a
large part of the Flash API, taking inspiration from Lightspark and
DartFlash. Well, one small library we do use is XMLHttpRequest, which is
rather a Polyfill than a library. Polyfills are okay. They just tame
browsers to behave like they should. But jQuery is much more than a
Polyfill!
-Frank-
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Yeah, sorry guys, it was quite late yesterday :)
On 11/29/2012 5:47 AM, Kevin Newman wrote:
> I believe that's Frank's blog. :)
>
> Kevin N.
>
>
> On 11/28/2012 7:28 PM, Daniel Wasilewski wrote:
>> But I know what the community is capable of, and seeing stuff like
>> jangaroo (I went trough Kevin's blog already, very good read) and
>> many initiatives I remember from the past, like make AS3 evaluators,
>> AST parsers etc. Flexibility of JS is vast, but the key to good
>> performance is one, stay native. Key for us is that we already have
>> an good structured environment. And Kevin, as the 1st comment on your
>> blog under
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
>
>
>
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
I believe that's Frank's blog. :)
Kevin N.
On 11/28/2012 7:28 PM, Daniel Wasilewski wrote:
> But I know what the community is capable of, and seeing stuff like
> jangaroo (I went trough Kevin's blog already, very good read) and many
> initiatives I remember from the past, like make AS3 evaluators, AST
> parsers etc. Flexibility of JS is vast, but the key to good
> performance is one, stay native. Key for us is that we already have an
> good structured environment. And Kevin, as the 1st comment on your
> blog under
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Well,
I'm not a compiler expert, have a basic undertaking of AST, parsing and
compiling it back to desire language.
In fact I didn't even grasp a Java side of FalconJS yet. But knowing the
Adobe way of doing things I wouldn't be surprised if somebody have it
worked out a better way.
Adobe itself stated many times, it is a concept, prototype, experiment.
I lost my attitude a bit by watching their presentation yesterday, when
the main developer presented so many layers involved in the entire
process. Including jQuery as support for animation and interactivity.
But I took a look at this as it was a cannon fodder for developers to
calm them down during a difficult PR time for them.
But I know what the community is capable of, and seeing stuff like
jangaroo (I went trough Kevin's blog already, very good read) and many
initiatives I remember from the past, like make AS3 evaluators, AST
parsers etc. Flexibility of JS is vast, but the key to good performance
is one, stay native. Key for us is that we already have an good
structured environment. And Kevin, as the 1st comment on your blog under
http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
We don't have to worry about violating fields of OOP so much, since we
are protected by language of the platform. But I see you guys have put a
lot of thinking and ideas in how to make the performance the best
possible. I am sure that ripping of the obstacles we can go even further.
Mike, if your assessment is correct and you see much bigger potential in
this. What can I say, the goal is the same, translate AS3 to JS. Does it
need to be falcon? This is what Adobe told/promised us, but...
Dan
On 11/29/2012 12:06 AM, Michael Schmalle wrote:
>
> jangaroo/jooc/backend/JsCodeGenerator.java
>
> This is the exact pattern I was talking about implementing. I think
> it's so solid and you have done a great job at implementing it.
>
> As I have said in previous posts today, The way FalconJS digests it's
> AST is through SWF visitors. You are using straight AST from your parser.
>
> Folks, having Frank drop this line and the discussions going on at the
> moment, there are definitely a couple different paths that can be
> taken with producing javascript.
>
> If I have my way we would use an implementation like Franks, the
> problem with it as it stands in Apache is there is no infrastructure
> built like Frank has built, this is why the engineers used an SWF to
> represent that infrastructure.
>
> The problem with the current SWF/JBurg implementation is it VERY
> confusing for most developers. With Franks implementation I was able
> to understand what he was doing today within 20 minutes and could jump
> right in and start coding things. With the current FalconJS emitters
> there is no way that would happen.
>
> So, I would love to see if we could think about a common goal to
> energize both projects and see where one could help the other. I truly
> believe now by looking at the code BEFORE this post our projects have
> the exact same goal but can do different things.
>
> Mike
>
>
>
>
>
>
>
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> Hi folks,
>>
>> here is another "outsider" who would like to contribute to the JS
>> runtime
>> format, if you are interested.
>> I am co-founder of the Open Source project Jangaroo, and as such have
>> been
>> dealing with JavaScript-to-ActionScript-3 compilation for several
>> years now.
>> In response to Bernd Paradies blogging about FalconJS, I blogged about
>> "simulating ActionScript 3 language features" extensively:
>>
>> -
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
>> -
>> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
>> -
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
>> -
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>>
>> All described solutions are actually implemented in the Jangaroo
>> Runtime,
>> which takes care of the code translated from AS3 to JS by the Jangaroo
>> Compiler coming alive.
>> In principle, we follow the "classic route", with the exception of
>> how we
>> simulate private members: see the first two blog posts.
>> At first look the Jangaroo Runtime may seem overly complex to you,
>> but it
>> does many more things (class loading / dependency management; class
>> initialization = execute static code at the right time; allow keeping
>> generated JS code and source AS3 code as similar as possible; automatic
>> method binding / correct "this", etc.), and the concepts described in
>> the
>> blob posts also work without these additional features.
>> The Jangaroo Compiler is written in Java and has a separate code
>> generator
>> (well you obviously won't need the parser) which might be worth having a
>> look at:
>> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
>>
>> If you dare to use Maven ;-), it is really easy to play around with our
>> code generation: Just set up your own projects within minutes, starting
>> from an example project like
>> https://github.com/fwienber/jooflash-app-template or
>> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>>
>> Greetings,
>> -Frank-
>>
>> Frank Wienberg
>> Software Architect & Jangaroo Evangelist
>>
>> *frank.wienberg@coremedia.com*
>>
>> * frank@jangaroo <fr...@jangaroo.net>.net*
>>
>> CoreMedia AG
>> content | context | conversion
>>
>> Ludwig-Erhard-Str. 18
>> 20459 Hamburg, Germany
>> www.coremedia.com
>>
>> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
>> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
>> Trade Register: Amtsgericht Hamburg, HR B 76277
>> --------------------------------------------------------
>>
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
jangaroo/jooc/backend/JsCodeGenerator.java
This is the exact pattern I was talking about implementing. I think
it's so solid and you have done a great job at implementing it.
As I have said in previous posts today, The way FalconJS digests it's
AST is through SWF visitors. You are using straight AST from your
parser.
Folks, having Frank drop this line and the discussions going on at the
moment, there are definitely a couple different paths that can be
taken with producing javascript.
If I have my way we would use an implementation like Franks, the
problem with it as it stands in Apache is there is no infrastructure
built like Frank has built, this is why the engineers used an SWF to
represent that infrastructure.
The problem with the current SWF/JBurg implementation is it VERY
confusing for most developers. With Franks implementation I was able
to understand what he was doing today within 20 minutes and could jump
right in and start coding things. With the current FalconJS emitters
there is no way that would happen.
So, I would love to see if we could think about a common goal to
energize both projects and see where one could help the other. I truly
believe now by looking at the code BEFORE this post our projects have
the exact same goal but can do different things.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
>
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
>
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
>
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi folks,
here is another "outsider" who would like to contribute to the JS runtime
format, if you are interested.
I am co-founder of the Open Source project Jangaroo, and as such have been
dealing with JavaScript-to-ActionScript-3 compilation for several years now.
In response to Bernd Paradies blogging about FalconJS, I blogged about
"simulating ActionScript 3 language features" extensively:
-
http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
-
http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
- http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
-
http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
All described solutions are actually implemented in the Jangaroo Runtime,
which takes care of the code translated from AS3 to JS by the Jangaroo
Compiler coming alive.
In principle, we follow the "classic route", with the exception of how we
simulate private members: see the first two blog posts.
At first look the Jangaroo Runtime may seem overly complex to you, but it
does many more things (class loading / dependency management; class
initialization = execute static code at the right time; allow keeping
generated JS code and source AS3 code as similar as possible; automatic
method binding / correct "this", etc.), and the concepts described in the
blob posts also work without these additional features.
The Jangaroo Compiler is written in Java and has a separate code generator
(well you obviously won't need the parser) which might be worth having a
look at:
https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
If you dare to use Maven ;-), it is really easy to play around with our
code generation: Just set up your own projects within minutes, starting
from an example project like
https://github.com/fwienber/jooflash-app-template or
https://github.com/CoreMedia/jangaroo-ext-as-examples .
Greetings,
-Frank-
Frank Wienberg
Software Architect & Jangaroo Evangelist
*frank.wienberg@coremedia.com*
* frank@jangaroo <fr...@jangaroo.net>.net*
CoreMedia AG
content | context | conversion
Ludwig-Erhard-Str. 18
20459 Hamburg, Germany
www.coremedia.com
Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
Trade Register: Amtsgericht Hamburg, HR B 76277
--------------------------------------------------------
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/28/2012 11:08 PM, Michael Schmalle wrote:
> That being said.
>
> I may be a complete idiot in thinking here but, why use a framework
> like jQuery if you have a framework in ActionScript.
>
> Now let me finish my thought, I know we arn't talking about using
> jQuery but we do have the compiler that can do "majic" when
> transcoding. So I agree that isn't it the best for us as a group to
> figure out the bare bones fasted possible javascript implementation
> and bend the compiler to service the needs of the performat code path?
>
I am trying hard to encourage people to answer positively on this
question :)
> The compiler is just a tool, it doesn't care how it compiles as to js.
>
> Pretty much what has been said in this thread is why I am still on
> this project. I don't even use ActionScript right now. But to think I
> could have a hand at helping an underdog take an implementation route
> that was not a "candy" route for gaining top followers is a great
> feeling. If this project gets started based on performance arguments
> it has a good chance at succeeding.
>
I do believe so. I am running my own project which is pretty much about
this, AS3 -> JS, but I would sacrifice it for the sake of seeing Flex
reborn on JS platform as a king of RIA again.
> Mike
>
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> Well,
>>
>> I feel like one, because only FalconJS subject activated me on this
>> list :)
>>
>> And to eliminate the 'IF' from your conditional statement, just a
>> quick one:
>>
>> http://jsperf.com/jqury-vs-plainjs
>>
>> Dan
>>
>> On 11/28/2012 10:26 PM, Michael Schmalle wrote:
>>> Hey,
>>>
>>> Your not an outsider, everything I have read of yours is golden. At
>>> least you are trying to explain this stuff to people who don't have
>>> a lot of js experience.
>>>
>>> If what you are saying about jQuery and performance is true then;
>>>
>>> "I do believe that it is possible to make a easy to develop
>>> environment and spit out efficient code on the other side.
>>> And not many ongoing development in this area has as much
>>> opportunity to get something done well as Apache has at the moment."
>>>
>>> I couldn't agree more. Sometimes being an infant has it's advantages
>>> in a new world because you don't have any bad habits yet!
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> Quoting Daniel Wasilewski <de...@gmail.com>:
>>>
>>>> I can spare my free time on this, Possibly not on Apache
>>>> contributor level because I am total noob when comes to it. I don't
>>>> even managed to set up my environment for flexSDK ;) But this is
>>>> because I've got AIR corrupted and some windows x86 redistributable
>>>> corupted libs blabla, the only reasonable solution is to go for
>>>> fresh Windows installation. Hell no...!! ;)
>>>>
>>>> I am not JS guru, but would like to get involved and do my best
>>>> even as outsider.
>>>> I was digging into JS for past year just to investigate the
>>>> possibilities. Mostly from performance point of view and mobile
>>>> development.
>>>>
>>>>
>>>> In regards to instanceof:
>>>>
>>>>
>>>> Here is something that haxe is using
>>>>
>>>> js.Boot.__instanceof = function(o,cl) {
>>>> try {
>>>> if(o instanceof cl) {
>>>> if(cl == Array) return o.__enum__ == null;
>>>> return true;
>>>> }
>>>> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
>>>> } catch( e ) {
>>>> if(cl == null) return false;
>>>> }
>>>> switch(cl) {
>>>> case Int:
>>>> return Math.ceil(o%2147483648.0) === o;
>>>> case Float:
>>>> return typeof(o) == "number";
>>>> case Bool:
>>>> return o === true || o === false;
>>>> case String:
>>>> return typeof(o) == "string";
>>>> case Dynamic:
>>>> return true;
>>>> default:
>>>> if(o == null) return false;
>>>> if(cl == Class && o.__name__ != null) return true; else null;
>>>> if(cl == Enum && o.__ename__ != null) return true; else null;
>>>> return o.__enum__ == cl;
>>>> }
>>>> }
>>>>
>>>>
>>>> having something like that implemented
>>>>
>>>> 'is' is as easy as:
>>>>
>>>> Std["is"] = function(v,t) {
>>>> return js.Boot.__instanceof(v,t);
>>>> }
>>>>
>>>> But obviously, it needs to live within rest of the sugar :).
>>>>
>>>> Are you able to provide the list of stuff/fields that compiler is
>>>> expecting to meet on the other side?
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>>>>
>>>>>
>>>>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> So, please tell me why not to go the classic route as a very
>>>>>> little overhaul
>>>>>> for the application that can be built on top of AS3/Flex?
>>>>>> This is bloody 3 classes with 4 methods in it, and we are not
>>>>>> talking here
>>>>>> about few % but tens.
>>>>>> It can only grow exponentially to the scale of your project.
>>>>> I don't know enough to have an reason not to go the classic
>>>>> route. But
>>>>> someone else will have to step up to do the work.
>>>>>
>>>>> That said, because we are cross compiling AS, does the classic
>>>>> route support
>>>>> as many features of AS, especially the reflection-oriented
>>>>> features? We
>>>>> want to try to compile business logic untouched and it might be
>>>>> using "is",
>>>>> "in", "instanceof", etc. Resig's blog seems to indicate that
>>>>> support for
>>>>> instanceOf was important and required all of that code.
>>>>>
>>>>>> Dan
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
That being said.
I may be a complete idiot in thinking here but, why use a framework
like jQuery if you have a framework in ActionScript.
Now let me finish my thought, I know we arn't talking about using
jQuery but we do have the compiler that can do "majic" when
transcoding. So I agree that isn't it the best for us as a group to
figure out the bare bones fasted possible javascript implementation
and bend the compiler to service the needs of the performat code path?
The compiler is just a tool, it doesn't care how it compiles as to js.
Pretty much what has been said in this thread is why I am still on
this project. I don't even use ActionScript right now. But to think I
could have a hand at helping an underdog take an implementation route
that was not a "candy" route for gaining top followers is a great
feeling. If this project gets started based on performance arguments
it has a good chance at succeeding.
Mike
Quoting Daniel Wasilewski <de...@gmail.com>:
> Well,
>
> I feel like one, because only FalconJS subject activated me on this list :)
>
> And to eliminate the 'IF' from your conditional statement, just a quick one:
>
> http://jsperf.com/jqury-vs-plainjs
>
> Dan
>
> On 11/28/2012 10:26 PM, Michael Schmalle wrote:
>> Hey,
>>
>> Your not an outsider, everything I have read of yours is golden. At
>> least you are trying to explain this stuff to people who don't have
>> a lot of js experience.
>>
>> If what you are saying about jQuery and performance is true then;
>>
>> "I do believe that it is possible to make a easy to develop
>> environment and spit out efficient code on the other side.
>> And not many ongoing development in this area has as much
>> opportunity to get something done well as Apache has at the moment."
>>
>> I couldn't agree more. Sometimes being an infant has it's
>> advantages in a new world because you don't have any bad habits yet!
>>
>>
>> Mike
>>
>>
>>
>>
>> Quoting Daniel Wasilewski <de...@gmail.com>:
>>
>>> I can spare my free time on this, Possibly not on Apache
>>> contributor level because I am total noob when comes to it. I
>>> don't even managed to set up my environment for flexSDK ;) But
>>> this is because I've got AIR corrupted and some windows x86
>>> redistributable corupted libs blabla, the only reasonable solution
>>> is to go for fresh Windows installation. Hell no...!! ;)
>>>
>>> I am not JS guru, but would like to get involved and do my best
>>> even as outsider.
>>> I was digging into JS for past year just to investigate the
>>> possibilities. Mostly from performance point of view and mobile
>>> development.
>>>
>>>
>>> In regards to instanceof:
>>>
>>>
>>> Here is something that haxe is using
>>>
>>> js.Boot.__instanceof = function(o,cl) {
>>> try {
>>> if(o instanceof cl) {
>>> if(cl == Array) return o.__enum__ == null;
>>> return true;
>>> }
>>> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
>>> } catch( e ) {
>>> if(cl == null) return false;
>>> }
>>> switch(cl) {
>>> case Int:
>>> return Math.ceil(o%2147483648.0) === o;
>>> case Float:
>>> return typeof(o) == "number";
>>> case Bool:
>>> return o === true || o === false;
>>> case String:
>>> return typeof(o) == "string";
>>> case Dynamic:
>>> return true;
>>> default:
>>> if(o == null) return false;
>>> if(cl == Class && o.__name__ != null) return true; else null;
>>> if(cl == Enum && o.__ename__ != null) return true; else null;
>>> return o.__enum__ == cl;
>>> }
>>> }
>>>
>>>
>>> having something like that implemented
>>>
>>> 'is' is as easy as:
>>>
>>> Std["is"] = function(v,t) {
>>> return js.Boot.__instanceof(v,t);
>>> }
>>>
>>> But obviously, it needs to live within rest of the sugar :).
>>>
>>> Are you able to provide the list of stuff/fields that compiler is
>>> expecting to meet on the other side?
>>>
>>> Dan
>>>
>>>
>>> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>>>
>>>>
>>>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>>>
>>>>> So, please tell me why not to go the classic route as a very
>>>>> little overhaul
>>>>> for the application that can be built on top of AS3/Flex?
>>>>> This is bloody 3 classes with 4 methods in it, and we are not
>>>>> talking here
>>>>> about few % but tens.
>>>>> It can only grow exponentially to the scale of your project.
>>>> I don't know enough to have an reason not to go the classic route. But
>>>> someone else will have to step up to do the work.
>>>>
>>>> That said, because we are cross compiling AS, does the classic
>>>> route support
>>>> as many features of AS, especially the reflection-oriented features? We
>>>> want to try to compile business logic untouched and it might be
>>>> using "is",
>>>> "in", "instanceof", etc. Resig's blog seems to indicate that support for
>>>> instanceOf was important and required all of that code.
>>>>
>>>>> Dan
>>>>
>>>
>>>
>>
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Well,
I feel like one, because only FalconJS subject activated me on this list :)
And to eliminate the 'IF' from your conditional statement, just a quick one:
http://jsperf.com/jqury-vs-plainjs
Dan
On 11/28/2012 10:26 PM, Michael Schmalle wrote:
> Hey,
>
> Your not an outsider, everything I have read of yours is golden. At
> least you are trying to explain this stuff to people who don't have a
> lot of js experience.
>
> If what you are saying about jQuery and performance is true then;
>
> "I do believe that it is possible to make a easy to develop
> environment and spit out efficient code on the other side.
> And not many ongoing development in this area has as much opportunity
> to get something done well as Apache has at the moment."
>
> I couldn't agree more. Sometimes being an infant has it's advantages
> in a new world because you don't have any bad habits yet!
>
>
> Mike
>
>
>
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> I can spare my free time on this, Possibly not on Apache contributor
>> level because I am total noob when comes to it. I don't even managed
>> to set up my environment for flexSDK ;) But this is because I've got
>> AIR corrupted and some windows x86 redistributable corupted libs
>> blabla, the only reasonable solution is to go for fresh Windows
>> installation. Hell no...!! ;)
>>
>> I am not JS guru, but would like to get involved and do my best even
>> as outsider.
>> I was digging into JS for past year just to investigate the
>> possibilities. Mostly from performance point of view and mobile
>> development.
>>
>>
>> In regards to instanceof:
>>
>>
>> Here is something that haxe is using
>>
>> js.Boot.__instanceof = function(o,cl) {
>> try {
>> if(o instanceof cl) {
>> if(cl == Array) return o.__enum__ == null;
>> return true;
>> }
>> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
>> } catch( e ) {
>> if(cl == null) return false;
>> }
>> switch(cl) {
>> case Int:
>> return Math.ceil(o%2147483648.0) === o;
>> case Float:
>> return typeof(o) == "number";
>> case Bool:
>> return o === true || o === false;
>> case String:
>> return typeof(o) == "string";
>> case Dynamic:
>> return true;
>> default:
>> if(o == null) return false;
>> if(cl == Class && o.__name__ != null) return true; else null;
>> if(cl == Enum && o.__ename__ != null) return true; else null;
>> return o.__enum__ == cl;
>> }
>> }
>>
>>
>> having something like that implemented
>>
>> 'is' is as easy as:
>>
>> Std["is"] = function(v,t) {
>> return js.Boot.__instanceof(v,t);
>> }
>>
>> But obviously, it needs to live within rest of the sugar :).
>>
>> Are you able to provide the list of stuff/fields that compiler is
>> expecting to meet on the other side?
>>
>> Dan
>>
>>
>> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>>
>>>
>>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>>
>>>> So, please tell me why not to go the classic route as a very little
>>>> overhaul
>>>> for the application that can be built on top of AS3/Flex?
>>>> This is bloody 3 classes with 4 methods in it, and we are not
>>>> talking here
>>>> about few % but tens.
>>>> It can only grow exponentially to the scale of your project.
>>> I don't know enough to have an reason not to go the classic route. But
>>> someone else will have to step up to do the work.
>>>
>>> That said, because we are cross compiling AS, does the classic route
>>> support
>>> as many features of AS, especially the reflection-oriented
>>> features? We
>>> want to try to compile business logic untouched and it might be
>>> using "is",
>>> "in", "instanceof", etc. Resig's blog seems to indicate that
>>> support for
>>> instanceOf was important and required all of that code.
>>>
>>>> Dan
>>>
>>
>>
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hey,
Your not an outsider, everything I have read of yours is golden. At
least you are trying to explain this stuff to people who don't have a
lot of js experience.
If what you are saying about jQuery and performance is true then;
"I do believe that it is possible to make a easy to develop
environment and spit out efficient code on the other side.
And not many ongoing development in this area has as much opportunity
to get something done well as Apache has at the moment."
I couldn't agree more. Sometimes being an infant has it's advantages
in a new world because you don't have any bad habits yet!
Mike
Quoting Daniel Wasilewski <de...@gmail.com>:
> I can spare my free time on this, Possibly not on Apache contributor
> level because I am total noob when comes to it. I don't even managed
> to set up my environment for flexSDK ;) But this is because I've got
> AIR corrupted and some windows x86 redistributable corupted libs
> blabla, the only reasonable solution is to go for fresh Windows
> installation. Hell no...!! ;)
>
> I am not JS guru, but would like to get involved and do my best even
> as outsider.
> I was digging into JS for past year just to investigate the
> possibilities. Mostly from performance point of view and mobile
> development.
>
>
> In regards to instanceof:
>
>
> Here is something that haxe is using
>
> js.Boot.__instanceof = function(o,cl) {
> try {
> if(o instanceof cl) {
> if(cl == Array) return o.__enum__ == null;
> return true;
> }
> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
> } catch( e ) {
> if(cl == null) return false;
> }
> switch(cl) {
> case Int:
> return Math.ceil(o%2147483648.0) === o;
> case Float:
> return typeof(o) == "number";
> case Bool:
> return o === true || o === false;
> case String:
> return typeof(o) == "string";
> case Dynamic:
> return true;
> default:
> if(o == null) return false;
> if(cl == Class && o.__name__ != null) return true; else null;
> if(cl == Enum && o.__ename__ != null) return true; else null;
> return o.__enum__ == cl;
> }
> }
>
>
> having something like that implemented
>
> 'is' is as easy as:
>
> Std["is"] = function(v,t) {
> return js.Boot.__instanceof(v,t);
> }
>
> But obviously, it needs to live within rest of the sugar :).
>
> Are you able to provide the list of stuff/fields that compiler is
> expecting to meet on the other side?
>
> Dan
>
>
> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>
>>
>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> So, please tell me why not to go the classic route as a very
>>> little overhaul
>>> for the application that can be built on top of AS3/Flex?
>>> This is bloody 3 classes with 4 methods in it, and we are not talking here
>>> about few % but tens.
>>> It can only grow exponentially to the scale of your project.
>> I don't know enough to have an reason not to go the classic route. But
>> someone else will have to step up to do the work.
>>
>> That said, because we are cross compiling AS, does the classic route support
>> as many features of AS, especially the reflection-oriented features? We
>> want to try to compile business logic untouched and it might be using "is",
>> "in", "instanceof", etc. Resig's blog seems to indicate that support for
>> instanceOf was important and required all of that code.
>>
>>> Dan
>>
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
I can spare my free time on this, Possibly not on Apache contributor
level because I am total noob when comes to it. I don't even managed to
set up my environment for flexSDK ;) But this is because I've got AIR
corrupted and some windows x86 redistributable corupted libs blabla, the
only reasonable solution is to go for fresh Windows installation. Hell
no...!! ;)
I am not JS guru, but would like to get involved and do my best even as
outsider.
I was digging into JS for past year just to investigate the
possibilities. Mostly from performance point of view and mobile development.
In regards to instanceof:
Here is something that haxe is using
js.Boot.__instanceof = function(o,cl) {
try {
if(o instanceof cl) {
if(cl == Array) return o.__enum__ == null;
return true;
}
if(js.Boot.__interfLoop(o.__class__,cl)) return true;
} catch( e ) {
if(cl == null) return false;
}
switch(cl) {
case Int:
return Math.ceil(o%2147483648.0) === o;
case Float:
return typeof(o) == "number";
case Bool:
return o === true || o === false;
case String:
return typeof(o) == "string";
case Dynamic:
return true;
default:
if(o == null) return false;
if(cl == Class && o.__name__ != null) return true; else null;
if(cl == Enum && o.__ename__ != null) return true; else null;
return o.__enum__ == cl;
}
}
having something like that implemented
'is' is as easy as:
Std["is"] = function(v,t) {
return js.Boot.__instanceof(v,t);
}
But obviously, it needs to live within rest of the sugar :).
Are you able to provide the list of stuff/fields that compiler is
expecting to meet on the other side?
Dan
On 11/28/2012 9:42 PM, Alex Harui wrote:
>
>
> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> So, please tell me why not to go the classic route as a very little overhaul
>> for the application that can be built on top of AS3/Flex?
>> This is bloody 3 classes with 4 methods in it, and we are not talking here
>> about few % but tens.
>> It can only grow exponentially to the scale of your project.
> I don't know enough to have an reason not to go the classic route. But
> someone else will have to step up to do the work.
>
> That said, because we are cross compiling AS, does the classic route support
> as many features of AS, especially the reflection-oriented features? We
> want to try to compile business logic untouched and it might be using "is",
> "in", "instanceof", etc. Resig's blog seems to indicate that support for
> instanceOf was important and required all of that code.
>
>> Dan
>
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
On 11/28/12 4:42 PM, Alex Harui wrote:
> I don't know enough to have an reason not to go the classic route. But
> someone else will have to step up to do the work.
Classic is the fastest for me (often by a lot) - at least in Firefox.
Maybe I'm missing some reason to go with the others?
> That said, because we are cross compiling AS, does the classic route support
> as many features of AS, especially the reflection-oriented features? We
> want to try to compile business logic untouched and it might be using "is",
> "in", "instanceof", etc. Resig's blog seems to indicate that support for
> instanceOf was important and required all of that code.
I don't think you need all that code, you can do this:
function BaseClass( yourVal ) {
this.someVal = yourVal;
}
BaseClass.prototype = {
myMethod: function() {
console.log( this.someVal );
}
};
function Extended( yourVal ) {
// super
BaseClass.apply( this, arguments );
this.someOtherVal = yourVal + " other";
}
Extended.prototype = Object.create( BaseClass.prototype ); // avoids
calling parent
Extended.prototype.myExtendedMethod = function() {
console.log( this.someOtherVal );
};
// override
Extended.prototype.myMethod = function() {
// super
BaseClass.prototype.myMethod.apply( this, arguments);
};
var ext = new Extended( "test" );
ext.myMethod(); // test
ext.myExtendedMethod(); // test other
ext instanceof BaseClass; // true
ext instanceof Extended; // true
Object.create is native in modern browsers, and has a simple polyfill
(for the relevant portions) for IE.
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create
Part of what John Resig was trying to do was to create editable and
writable classical inheritance from working within JS. FalconJS doesn't
have this constraint. We don't need to edit the generated Javascript
since the next AS3 compile would wipe out any changes anyway? Better to
make it fast (and besides, that's still readable, and you even could
edit it if you wanted).
Kevin N.
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
> So, please tell me why not to go the classic route as a very little overhaul
> for the application that can be built on top of AS3/Flex?
> This is bloody 3 classes with 4 methods in it, and we are not talking here
> about few % but tens.
> It can only grow exponentially to the scale of your project.
I don't know enough to have an reason not to go the classic route. But
someone else will have to step up to do the work.
That said, because we are cross compiling AS, does the classic route support
as many features of AS, especially the reflection-oriented features? We
want to try to compile business logic untouched and it might be using "is",
"in", "instanceof", etc. Resig's blog seems to indicate that support for
instanceOf was important and required all of that code.
>
> Dan
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Ok, both test are up to date including HaXe.
*Test of creation of this little structure*
http://jsperf.com/inheritance-yet-another-test/3
*Test of speed of accession already created objects*
http://jsperf.com/inheritance-yet-another-test/4
Which confirms what I have said before, that is a best out there but not
the best possible ;)
There was also a functionality test for all of them, not unit test really ;)
*//Classic*
//Just a Java like setters/getters for backward compatibility
var instanceA = new MySubSubClassA();
//Having public variable when setter/getter pattern is not needed it
shouldn't even be there, but this is just a test
instanceA.setName("James");
//instead of using setter we assigned it directly to public variable to
see if you can omit setters for public variables
instanceA.surname = "Bond";
console.log(instanceA.name); //expected undefined, because it's a
private field and not accessible from outside of prototypal chain.
It makes it perfect for hiding internals when getter/setter patterns
applies.
console.log(instanceA.surname); //Bond, because it's public
console.log(instanceA.getSurname()); //"my name is Bond", because getter
has been overridden in subclass
console.log(instanceA.getFullName()); //"James Bond"
*
**Output*
-::constructed
--::constructed
---::constructed
// to see if all Classes in the chain has been invoked on constructor in the correct order; Passed
undefined, as expected, private field not accessible
Bond
my name is Bond
James Bond
// All good here
*
**//adobe.js* I took only essence of it and renamed adobe to mod.
*Output
*
-::constructed
--::constructed
---::constructed
//super figured out, all good
James - it shouldn't be here! safety of module pattern fails ;)
It might not be considered as an issue since we don't really care about safety of output.
Bond
my name is Bond
JamesBond
*HaXe*
Same scenario like for other tests but I need to mention one thing here.
*IMPORTANT:*
I took just $extend model of HaXe, there is much more going on in the final output, also,
I kept the structure on the same level as the Main.hx class to avoid namespace issue.
otherwise instead:
var instanceC = new MyExExClassC();
var instanceC = new com.apache.flex.MyExExClassC();
not to mention that you have massive bunch of objects represents entire tree of your project like this:
var com = com || {}
if(!com.apache) com.apache = {}
if(!com.apache.flex) com.apache.flex = {}
com.apache.flex.MyClassC = function() {
};
com.apache.flex.MyClassC.__name__ = true;
com.apache.flex.MyClassC.prototype = {
setSurname: function(value) {
this.surname = value;
}
,getSurname: function() {
return this.surname;
}
,setName: function(value) {
this.name = value;
}
,getName: function() {
return this.name;
}
,__class__: com.apache.flex.MyClassC
}
That will slow down both test and I am sure adobe.js is the winner in this situation.
This very little thing destroys performance of everything. JavaScript is a shallow water friendly more than anything else.
And this very test does not represents real world example unless you crazy enough and keep your all classes next to Main.hx a t all time :)
*Output*
---::constructed
--::constructed
-::constructed
Reverse order of instantiation..!? interesting
James - same issue aka adobe'js. It might not be considered as an issue since we don't really care about safety of output.
Bond
my name is Bond
James Bond
this part is correct
So, please tell me why not to go the classic route as a very little overhaul for the application that can be built on top of AS3/Flex?
This is bloody 3 classes with 4 methods in it, and we are not talking here about few % but tens.
It can only grow exponentially to the scale of your project.
Dan
On 11/28/2012 8:26 PM, Markus Gritsch wrote:
> Hi everyone,
>
> Maybe someone can clarify the difference between haxe`s - as3-2-js output target and falcon-js. Both are producing js code. Haxe supports a collection of multiple output formats, too. Maybe the solution everyone is talking about is already out there - have???
>
> Thanks for your input
>
>
>
> On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
>
>> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> Ok will try again by changing a subject because you seems to moved away
>>> from original topic, and I don't want to interrupt :)
>>>
>>> So far I have a test to compare very simple model of prototypal
>>> inheritance and proposed module pattern that seems to be out of falconJS
>>> compiler little syntactic sugar.
>>> I have minimised this source a bit, there was few more additional fields
>>> that I guess something is depends on but even striping it out:
>>>
>>> http://jsperf.com/inheritance-yet-another-test/3
>>>
>>> If you go to the revision 2 of this test, there will be different
>>> comparison.
>>> http://jsperf.com/inheritance-yet-another-test/3
>>> Speed of accession of those objects.
>>>
>>> However I would like to improve it, because adobe.js implementation
>>> doesn't seems to call super as the classic does.
>>> So it might be not relevant test right now. Does anybody know how to
>>> call super from there?
>> It looks like in adobe.js around line 61 it tests to see if the super class
>> has the function and creates a _super function you can call.
>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Good point, I will try to add HaXe output to this test as well. But as
far as I can tell.
It was the best JS output out there but had some fundamental issues with
namespaces represented by object chain. I was playing around it a while ago.
Dan
On 11/28/2012 8:26 PM, Markus Gritsch wrote:
> Hi everyone,
>
> Maybe someone can clarify the difference between haxe`s - as3-2-js output target and falcon-js. Both are producing js code. Haxe supports a collection of multiple output formats, too. Maybe the solution everyone is talking about is already out there - have???
>
> Thanks for your input
>
>
>
> On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
>
>> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> Ok will try again by changing a subject because you seems to moved away
>>> from original topic, and I don't want to interrupt :)
>>>
>>> So far I have a test to compare very simple model of prototypal
>>> inheritance and proposed module pattern that seems to be out of falconJS
>>> compiler little syntactic sugar.
>>> I have minimised this source a bit, there was few more additional fields
>>> that I guess something is depends on but even striping it out:
>>>
>>> http://jsperf.com/inheritance-yet-another-test/3
>>>
>>> If you go to the revision 2 of this test, there will be different
>>> comparison.
>>> http://jsperf.com/inheritance-yet-another-test/3
>>> Speed of accession of those objects.
>>>
>>> However I would like to improve it, because adobe.js implementation
>>> doesn't seems to call super as the classic does.
>>> So it might be not relevant test right now. Does anybody know how to
>>> call super from there?
>> It looks like in adobe.js around line 61 it tests to see if the super class
>> has the function and creates a _super function you can call.
>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
Re: [FalconJS] concepts
Posted by Markus Gritsch <ma...@gmx.de>.
Hi everyone,
Maybe someone can clarify the difference between haxe`s - as3-2-js output target and falcon-js. Both are producing js code. Haxe supports a collection of multiple output formats, too. Maybe the solution everyone is talking about is already out there - have???
Thanks for your input
On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
>
> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> Ok will try again by changing a subject because you seems to moved away
>> from original topic, and I don't want to interrupt :)
>>
>> So far I have a test to compare very simple model of prototypal
>> inheritance and proposed module pattern that seems to be out of falconJS
>> compiler little syntactic sugar.
>> I have minimised this source a bit, there was few more additional fields
>> that I guess something is depends on but even striping it out:
>>
>> http://jsperf.com/inheritance-yet-another-test/3
>>
>> If you go to the revision 2 of this test, there will be different
>> comparison.
>> http://jsperf.com/inheritance-yet-another-test/3
>> Speed of accession of those objects.
>>
>> However I would like to improve it, because adobe.js implementation
>> doesn't seems to call super as the classic does.
>> So it might be not relevant test right now. Does anybody know how to
>> call super from there?
> It looks like in adobe.js around line 61 it tests to see if the super class
> has the function and creates a _super function you can call.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Thanks for hint, I figured it out.
I was confused about it and was trying to call this._super.init();
but just this._super() inside the init does a job.
Here is speed of accession test
http://jsperf.com/inheritance-yet-another-test/4
Dan
On 11/28/2012 8:04 PM, Alex Harui wrote:
> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> Ok will try again by changing a subject because you seems to moved away
>> from original topic, and I don't want to interrupt :)
>>
>> So far I have a test to compare very simple model of prototypal
>> inheritance and proposed module pattern that seems to be out of falconJS
>> compiler little syntactic sugar.
>> I have minimised this source a bit, there was few more additional fields
>> that I guess something is depends on but even striping it out:
>>
>> http://jsperf.com/inheritance-yet-another-test/3
>>
>> If you go to the revision 2 of this test, there will be different
>> comparison.
>> http://jsperf.com/inheritance-yet-another-test/3
>> Speed of accession of those objects.
>>
>> However I would like to improve it, because adobe.js implementation
>> doesn't seems to call super as the classic does.
>> So it might be not relevant test right now. Does anybody know how to
>> call super from there?
> It looks like in adobe.js around line 61 it tests to see if the super class
> has the function and creates a _super function you can call.
>
>
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> Ok will try again by changing a subject because you seems to moved away
> from original topic, and I don't want to interrupt :)
>
> So far I have a test to compare very simple model of prototypal
> inheritance and proposed module pattern that seems to be out of falconJS
> compiler little syntactic sugar.
> I have minimised this source a bit, there was few more additional fields
> that I guess something is depends on but even striping it out:
>
> http://jsperf.com/inheritance-yet-another-test/3
>
> If you go to the revision 2 of this test, there will be different
> comparison.
> http://jsperf.com/inheritance-yet-another-test/3
> Speed of accession of those objects.
>
> However I would like to improve it, because adobe.js implementation
> doesn't seems to call super as the classic does.
> So it might be not relevant test right now. Does anybody know how to
> call super from there?
It looks like in adobe.js around line 61 it tests to see if the super class
has the function and creates a _super function you can call.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
[FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Ok will try again by changing a subject because you seems to moved away
from original topic, and I don't want to interrupt :)
So far I have a test to compare very simple model of prototypal
inheritance and proposed module pattern that seems to be out of falconJS
compiler little syntactic sugar.
I have minimised this source a bit, there was few more additional fields
that I guess something is depends on but even striping it out:
http://jsperf.com/inheritance-yet-another-test/3
If you go to the revision 2 of this test, there will be different
comparison.
http://jsperf.com/inheritance-yet-another-test/3
Speed of accession of those objects.
However I would like to improve it, because adobe.js implementation
doesn't seems to call super as the classic does.
So it might be not relevant test right now. Does anybody know how to
call super from there?
Dan
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>> Are we ready to put the framework.js in the FalconJS develop branch so
>>> we can all work on it?
>> IMO, framework.js shouldn't be in the FalconJS branch. It is as independent
>> of FalconJS as any of the AS code is independent of Falcon.
>>
>> I would refactor framework.js into separate js files so we don't step on
>> each others toes and put it somewhere else in SVN and start adding to it and
>> the .AS files. We could start by having folks just work in my whiteboard or
>> we can create a new whiteboard folder not under my name if that makes folks
>> more comfortable. I was going to branch what I have checked in for further
>> modifications so what I checked in stays running.
>
> Might I suggest a 'as2js' in the root of the repo, with branches, tags
> and trunk. In trunk (and/or branches/develop?) I would have an 'as'
> and a 'js' folder, and within each of those a 'src' and 'srcTest'...
> But that's just of the top of my head, so I'm open to suggestions ;-)
Yeah, let's sit on this until tomorrow in case we get other suggestions on
this topic.
>
>>> Another question: for your prototype you modified/bypassed parts of
>>> the SDK, it looks like. Does this mean that you envision 2 versions of
>>> the SDK, one for Flash Player deployment and one for web native
>>> deployment?
>> I'm not sure what you mean here. For this new effort, I am not using Apache
>> Flex 4.8 at all and have no plans to. This is a next-generation and a full
>> rewrite with different goals. What it has in common with Flex is MXML and
>> AS3 and many but not all APIs. The idea is that for every component you
>> write in AS, you have to create its equivalent in JS. You might be able to
>> get FalconJS to help you create parts of the JS equivalent, but the parts
>> that touch the visuals pretty much have to be written differently.
>
> This was the missing link in my understanding. We're writing a new
> SDK, fresh components on both sides of the FalconJS compiler.
Yep, IMO the current code is too hard to port to JS. It has expectations on
AS features that will be hard or expensive to implement in JS, and some
fundamental APIs like addChild need to change to better deal with the
abstraction.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
I branched my whiteboard into the root. I decided to call it "asjs" because
we are developing parallel as and js frameworks. There is a develop branch
in there where we should be making our commits.
-Alex
On 11/28/12 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>> Are we ready to put the framework.js in the FalconJS develop branch so
>>> we can all work on it?
>> IMO, framework.js shouldn't be in the FalconJS branch. It is as independent
>> of FalconJS as any of the AS code is independent of Falcon.
>>
>> I would refactor framework.js into separate js files so we don't step on
>> each others toes and put it somewhere else in SVN and start adding to it and
>> the .AS files. We could start by having folks just work in my whiteboard or
>> we can create a new whiteboard folder not under my name if that makes folks
>> more comfortable. I was going to branch what I have checked in for further
>> modifications so what I checked in stays running.
>
> Might I suggest a 'as2js' in the root of the repo, with branches, tags
> and trunk. In trunk (and/or branches/develop?) I would have an 'as'
> and a 'js' folder, and within each of those a 'src' and 'srcTest'...
> But that's just of the top of my head, so I'm open to suggestions ;-)
>
>> Are you planning to use FlexUnit to test the AS side? What will you use for
>> the JS side?
>
> FlexUnit seems to make sense for the AS. I use Jasmine [1] for
> JavaScript, so that would have my preference...
>
>>> Question: I expect that we'll need to figure out a way to put the
>>> framework components through the Closure Compiler upon "publish",
>>> correct?
>> Yes, there is a missing step where we generate an index.html and collect all
>> of the required JS files and minify them. I'm hand-assembling stuff right
>> now.
>
> Don't let Om hear it, or he'll start another AIR project :-) I'll give
> this some thought once we've set the rest up.
>
>>> Another question: for your prototype you modified/bypassed parts of
>>> the SDK, it looks like. Does this mean that you envision 2 versions of
>>> the SDK, one for Flash Player deployment and one for web native
>>> deployment?
>> I'm not sure what you mean here. For this new effort, I am not using Apache
>> Flex 4.8 at all and have no plans to. This is a next-generation and a full
>> rewrite with different goals. What it has in common with Flex is MXML and
>> AS3 and many but not all APIs. The idea is that for every component you
>> write in AS, you have to create its equivalent in JS. You might be able to
>> get FalconJS to help you create parts of the JS equivalent, but the parts
>> that touch the visuals pretty much have to be written differently.
>
> This was the missing link in my understanding. We're writing a new
> SDK, fresh components on both sides of the FalconJS compiler.
>
>>> I'll stop here and catch my breath ;-) I like what I'm seeing so far
>>> and certainly see the possibilities going forward. I do not share your
>>> caution about creating components that are more than basic
>>> implementations of available HTML controls. But we'll cross that
>>> bridge once we have a "working" version of the JS framework hooked up
>>> to the FalconJS compiler :-) First things first, right?
>> Definitely. My only "caution" about creating more than basic controls is
>> how long it will take to create them. My goal is to get the basic
>> unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
>> Label) running ASAP so folks can actually play with it. If you have the
>> time/energy to do fancier stuff you are more than welcome to get going on
>> it.
>
> Sure, first things first though, set up this sub-project, ok?
>
> EdB
>
> 1:
> http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-w
> ith-jasmine.html
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> Are we ready to put the framework.js in the FalconJS develop branch so
>> we can all work on it?
> IMO, framework.js shouldn't be in the FalconJS branch. It is as independent
> of FalconJS as any of the AS code is independent of Falcon.
>
> I would refactor framework.js into separate js files so we don't step on
> each others toes and put it somewhere else in SVN and start adding to it and
> the .AS files. We could start by having folks just work in my whiteboard or
> we can create a new whiteboard folder not under my name if that makes folks
> more comfortable. I was going to branch what I have checked in for further
> modifications so what I checked in stays running.
Might I suggest a 'as2js' in the root of the repo, with branches, tags
and trunk. In trunk (and/or branches/develop?) I would have an 'as'
and a 'js' folder, and within each of those a 'src' and 'srcTest'...
But that's just of the top of my head, so I'm open to suggestions ;-)
> Are you planning to use FlexUnit to test the AS side? What will you use for
> the JS side?
FlexUnit seems to make sense for the AS. I use Jasmine [1] for
JavaScript, so that would have my preference...
>> Question: I expect that we'll need to figure out a way to put the
>> framework components through the Closure Compiler upon "publish",
>> correct?
> Yes, there is a missing step where we generate an index.html and collect all
> of the required JS files and minify them. I'm hand-assembling stuff right
> now.
Don't let Om hear it, or he'll start another AIR project :-) I'll give
this some thought once we've set the rest up.
>> Another question: for your prototype you modified/bypassed parts of
>> the SDK, it looks like. Does this mean that you envision 2 versions of
>> the SDK, one for Flash Player deployment and one for web native
>> deployment?
> I'm not sure what you mean here. For this new effort, I am not using Apache
> Flex 4.8 at all and have no plans to. This is a next-generation and a full
> rewrite with different goals. What it has in common with Flex is MXML and
> AS3 and many but not all APIs. The idea is that for every component you
> write in AS, you have to create its equivalent in JS. You might be able to
> get FalconJS to help you create parts of the JS equivalent, but the parts
> that touch the visuals pretty much have to be written differently.
This was the missing link in my understanding. We're writing a new
SDK, fresh components on both sides of the FalconJS compiler.
>> I'll stop here and catch my breath ;-) I like what I'm seeing so far
>> and certainly see the possibilities going forward. I do not share your
>> caution about creating components that are more than basic
>> implementations of available HTML controls. But we'll cross that
>> bridge once we have a "working" version of the JS framework hooked up
>> to the FalconJS compiler :-) First things first, right?
> Definitely. My only "caution" about creating more than basic controls is
> how long it will take to create them. My goal is to get the basic
> unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
> Label) running ASAP so folks can actually play with it. If you have the
> time/energy to do fancier stuff you are more than welcome to get going on
> it.
Sure, first things first though, set up this sub-project, ok?
EdB
1: http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 10:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Thank you Alex.
>
> FYI, I was able to hack in an Image component by copying and modifying
> the Label component in framework.js and 'faking' the generated code
> that implements it. So that's promising for future work ;-)
>
> Note: I thought I'd add another Label in the mix. This showed up and
> initiated well, but having the second Label on screen, the on click
> event of the button stopped working. That is to say, it did still
> update the value of the property, but it failed to update the
> displayed text.
In theory, you did this by modifying MyInitialView.as and you should be able
to build a SWF from the available .as files and see if it runs in Flash. If
it does, then I was using FireBug in FireFox to walk through the JS
implementation.
>
> Are we ready to put the framework.js in the FalconJS develop branch so
> we can all work on it?
IMO, framework.js shouldn't be in the FalconJS branch. It is as independent
of FalconJS as any of the AS code is independent of Falcon.
I would refactor framework.js into separate js files so we don't step on
each others toes and put it somewhere else in SVN and start adding to it and
the .AS files. We could start by having folks just work in my whiteboard or
we can create a new whiteboard folder not under my name if that makes folks
more comfortable. I was going to branch what I have checked in for further
modifications so what I checked in stays running.
> I'd like to take it apart and try to implement
> some ideas I have, as well as start to put some unit tests in place
> for the various components and start building other AS/MXML test
> cases.
IMO, big changes should go in their own branches, small ones can just go in
some active branch we decide to share.
Are you planning to use FlexUnit to test the AS side? What will you use for
the JS side?
>
> Question: I expect that we'll need to figure out a way to put the
> framework components through the Closure Compiler upon "publish",
> correct?
Yes, there is a missing step where we generate an index.html and collect all
of the required JS files and minify them. I'm hand-assembling stuff right
now.
>
> Another question: for your prototype you modified/bypassed parts of
> the SDK, it looks like. Does this mean that you envision 2 versions of
> the SDK, one for Flash Player deployment and one for web native
> deployment?
I'm not sure what you mean here. For this new effort, I am not using Apache
Flex 4.8 at all and have no plans to. This is a next-generation and a full
rewrite with different goals. What it has in common with Flex is MXML and
AS3 and many but not all APIs. The idea is that for every component you
write in AS, you have to create its equivalent in JS. You might be able to
get FalconJS to help you create parts of the JS equivalent, but the parts
that touch the visuals pretty much have to be written differently.
>
> I'll stop here and catch my breath ;-) I like what I'm seeing so far
> and certainly see the possibilities going forward. I do not share your
> caution about creating components that are more than basic
> implementations of available HTML controls. But we'll cross that
> bridge once we have a "working" version of the JS framework hooked up
> to the FalconJS compiler :-) First things first, right?
Definitely. My only "caution" about creating more than basic controls is
how long it will take to create them. My goal is to get the basic
unskinnable 7 (Button, CheckBox, RadioButton, TextInput, TextArea, List,
Label) running ASAP so folks can actually play with it. If you have the
time/energy to do fancier stuff you are more than welcome to get going on
it.
>
> EdB
>
>
>
> On Wed, Nov 28, 2012 at 6:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 11/28/12 12:37 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
>>
>>> I like the approach (I just read the wiki, didn't look at the JS vs AS
>>> implementation parts). It has a lot of sense.
>>> I think that Goals vs Non Goals are a key part, specially this statement:
>>> "we
>>> will encapsulate the best implementation possible under a given API contract
>>> ".
>>> Specially if we want to support the spark skinning model and other Flex
>>> architectural gems throughout all rendering targets.
>> There will be skinning, but I currently don't want to bring in the Spark
>> skinning model verbatim. I think the SkinPart concept was a compromise
>> required to meet some performance requirements. Maybe we'll run into the
>> same performance issues and have to make the same compromise, but the
>> prototype currently uses a more distinct model/view/controller pattern. In
>> Spark, the model is baked into the component and cannot be replaced/extended
>> without extending the component. Remember how in early Flex 4 it was
>> difficult to add an icon to the Button skin? Even now, try adding a second
>> icon to the skin. You can't just change the model and the skin, you have to
>> subclass the component. Also, it has a key flaw in that it pushes
>> information down to the child/skin up front instead of allowing the skin to
>> get what it needs on-demand. If the initial state of a skin did not need
>> the icon, too bad, cycles were taken to push it down to the skin.
>>
>> One other thing: I think the fundamental piece of skinning in this new
>> model will be bitmaps. I think it might be a lot of work to get vector art
>> to "skin" a button in HTML/JS. And, yes, then those buttons won't scale as
>> well, but maybe they will be more compatible with GPU renderers?
>>>
>>> What's needed to run the sample project you provide?
>> I built the FlexJSUI swc and FlexJSTest.as in FlashBuilder.
>> Then, I
>> -copied the .as files to a folder and ran FalconJS on it.
>> -hand-created the index.html
>> -copied the js directory
>> Opened the index.html in FireFox
>>
>> After that, I
>> -installed PhoneGap/Cordova.
>> -installed the Android/Eclipse IDE
>> -created a new PhoneGap project.
>> -replaced the index.html and js files it created for me with the index.html
>> and js files from above.
>> -published for Android and saw it run in the emulator.
>>
>>> What's next? :-)
>> 1) Put more information in the wiki.
>> 2) Get working on Falcon
>> 3) Get working on more components
>>
>>>
>>> Cheers!
>>>
>>>
>>> --
>>> Joan Llenas Masó
>>> CEO/CTO Garnet Works SL
>>> T. 93 848 57 27
>>> --
>>> @joangarnet (es)
>>> @joanllenas (en)
>>> http://joan.garnet.io
>>> http://www.garnetworks.com
>>>
>>>
>>>
>>>
>>> On Wed, Nov 28, 2012 at 8:34 AM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I finally got permission to check in a demo that uses FalconJS into my
>>>> whiteboard at [1].
>>>>
>>>> I started a writeup on it on the wiki that I will try to complete tomorrow
>>>> at [2].
>>>>
>>>> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
>>>> [2]
>>>> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>>>>
>>>> Thanks,
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Thank you Alex.
FYI, I was able to hack in an Image component by copying and modifying
the Label component in framework.js and 'faking' the generated code
that implements it. So that's promising for future work ;-)
Note: I thought I'd add another Label in the mix. This showed up and
initiated well, but having the second Label on screen, the on click
event of the button stopped working. That is to say, it did still
update the value of the property, but it failed to update the
displayed text.
Are we ready to put the framework.js in the FalconJS develop branch so
we can all work on it? I'd like to take it apart and try to implement
some ideas I have, as well as start to put some unit tests in place
for the various components and start building other AS/MXML test
cases.
Question: I expect that we'll need to figure out a way to put the
framework components through the Closure Compiler upon "publish",
correct?
Another question: for your prototype you modified/bypassed parts of
the SDK, it looks like. Does this mean that you envision 2 versions of
the SDK, one for Flash Player deployment and one for web native
deployment?
I'll stop here and catch my breath ;-) I like what I'm seeing so far
and certainly see the possibilities going forward. I do not share your
caution about creating components that are more than basic
implementations of available HTML controls. But we'll cross that
bridge once we have a "working" version of the JS framework hooked up
to the FalconJS compiler :-) First things first, right?
EdB
On Wed, Nov 28, 2012 at 6:18 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/28/12 12:37 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
>
>> I like the approach (I just read the wiki, didn't look at the JS vs AS
>> implementation parts). It has a lot of sense.
>> I think that Goals vs Non Goals are a key part, specially this statement: "we
>> will encapsulate the best implementation possible under a given API contract
>> ".
>> Specially if we want to support the spark skinning model and other Flex
>> architectural gems throughout all rendering targets.
> There will be skinning, but I currently don't want to bring in the Spark
> skinning model verbatim. I think the SkinPart concept was a compromise
> required to meet some performance requirements. Maybe we'll run into the
> same performance issues and have to make the same compromise, but the
> prototype currently uses a more distinct model/view/controller pattern. In
> Spark, the model is baked into the component and cannot be replaced/extended
> without extending the component. Remember how in early Flex 4 it was
> difficult to add an icon to the Button skin? Even now, try adding a second
> icon to the skin. You can't just change the model and the skin, you have to
> subclass the component. Also, it has a key flaw in that it pushes
> information down to the child/skin up front instead of allowing the skin to
> get what it needs on-demand. If the initial state of a skin did not need
> the icon, too bad, cycles were taken to push it down to the skin.
>
> One other thing: I think the fundamental piece of skinning in this new
> model will be bitmaps. I think it might be a lot of work to get vector art
> to "skin" a button in HTML/JS. And, yes, then those buttons won't scale as
> well, but maybe they will be more compatible with GPU renderers?
>>
>> What's needed to run the sample project you provide?
> I built the FlexJSUI swc and FlexJSTest.as in FlashBuilder.
> Then, I
> -copied the .as files to a folder and ran FalconJS on it.
> -hand-created the index.html
> -copied the js directory
> Opened the index.html in FireFox
>
> After that, I
> -installed PhoneGap/Cordova.
> -installed the Android/Eclipse IDE
> -created a new PhoneGap project.
> -replaced the index.html and js files it created for me with the index.html
> and js files from above.
> -published for Android and saw it run in the emulator.
>
>> What's next? :-)
> 1) Put more information in the wiki.
> 2) Get working on Falcon
> 3) Get working on more components
>
>>
>> Cheers!
>>
>>
>> --
>> Joan Llenas Masó
>> CEO/CTO Garnet Works SL
>> T. 93 848 57 27
>> --
>> @joangarnet (es)
>> @joanllenas (en)
>> http://joan.garnet.io
>> http://www.garnetworks.com
>>
>>
>>
>>
>> On Wed, Nov 28, 2012 at 8:34 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> Hi,
>>>
>>> I finally got permission to check in a demo that uses FalconJS into my
>>> whiteboard at [1].
>>>
>>> I started a writeup on it on the wiki that I will try to complete tomorrow
>>> at [2].
>>>
>>> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
>>> [2]
>>> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>>>
>>> Thanks,
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 12:37 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
> I like the approach (I just read the wiki, didn't look at the JS vs AS
> implementation parts). It has a lot of sense.
> I think that Goals vs Non Goals are a key part, specially this statement: "we
> will encapsulate the best implementation possible under a given API contract
> ".
> Specially if we want to support the spark skinning model and other Flex
> architectural gems throughout all rendering targets.
There will be skinning, but I currently don't want to bring in the Spark
skinning model verbatim. I think the SkinPart concept was a compromise
required to meet some performance requirements. Maybe we'll run into the
same performance issues and have to make the same compromise, but the
prototype currently uses a more distinct model/view/controller pattern. In
Spark, the model is baked into the component and cannot be replaced/extended
without extending the component. Remember how in early Flex 4 it was
difficult to add an icon to the Button skin? Even now, try adding a second
icon to the skin. You can't just change the model and the skin, you have to
subclass the component. Also, it has a key flaw in that it pushes
information down to the child/skin up front instead of allowing the skin to
get what it needs on-demand. If the initial state of a skin did not need
the icon, too bad, cycles were taken to push it down to the skin.
One other thing: I think the fundamental piece of skinning in this new
model will be bitmaps. I think it might be a lot of work to get vector art
to "skin" a button in HTML/JS. And, yes, then those buttons won't scale as
well, but maybe they will be more compatible with GPU renderers?
>
> What's needed to run the sample project you provide?
I built the FlexJSUI swc and FlexJSTest.as in FlashBuilder.
Then, I
-copied the .as files to a folder and ran FalconJS on it.
-hand-created the index.html
-copied the js directory
Opened the index.html in FireFox
After that, I
-installed PhoneGap/Cordova.
-installed the Android/Eclipse IDE
-created a new PhoneGap project.
-replaced the index.html and js files it created for me with the index.html
and js files from above.
-published for Android and saw it run in the emulator.
> What's next? :-)
1) Put more information in the wiki.
2) Get working on Falcon
3) Get working on more components
>
> Cheers!
>
>
> --
> Joan Llenas Masó
> CEO/CTO Garnet Works SL
> T. 93 848 57 27
> --
> @joangarnet (es)
> @joanllenas (en)
> http://joan.garnet.io
> http://www.garnetworks.com
>
>
>
>
> On Wed, Nov 28, 2012 at 8:34 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> Hi,
>>
>> I finally got permission to check in a demo that uses FalconJS into my
>> whiteboard at [1].
>>
>> I started a writeup on it on the wiki that I will try to complete tomorrow
>> at [2].
>>
>> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
>> [2]
>> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>>
>> Thanks,
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
I like the approach (I just read the wiki, didn't look at the JS vs AS
implementation parts). It has a lot of sense.
I think that Goals vs Non Goals are a key part, specially this statement: "we
will encapsulate the best implementation possible under a given API contract
".
Specially if we want to support the spark skinning model and other Flex
architectural gems throughout all rendering targets.
What's needed to run the sample project you provide?
What's next? :-)
Cheers!
--
Joan Llenas Masó
CEO/CTO Garnet Works SL
T. 93 848 57 27
--
@joangarnet (es)
@joanllenas (en)
http://joan.garnet.io
http://www.garnetworks.com
On Wed, Nov 28, 2012 at 8:34 AM, Alex Harui <ah...@adobe.com> wrote:
> Hi,
>
> I finally got permission to check in a demo that uses FalconJS into my
> whiteboard at [1].
>
> I started a writeup on it on the wiki that I will try to complete tomorrow
> at [2].
>
> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
> [2]
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>
> Thanks,
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
>> For methods, if a method name exists on parent, and also exists on
>> child, the extend method is adding a closure, which will preserve, and
>> then invoke the parent's method in _super() (line 75 in adobe.js).
> As you probably know better than me, the author of [1] is a pretty
> well-known JS guru. I haven't looked at his other work like Jquery to see
> if he uses this pattern there or has since become a convert to some other
> pattern. But for now I have to assume there was some important reason for
> every line of the code. Was it just to get instanceof to work?
>
> I don't really care what the output code looks like, but I do know I don't
> have the ability to quickly change the output code so I am working on other
> aspects and hoping some other volunteer will do that if so motivated.
>>
I am not a js guru either BUT if I were told what things needed to
look like I am sure I could make the compiler spit out something that
you wanted by changing the String emitter values.
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: FalconJS "Demo" checked in
Posted by Daniel Wasilewski <de...@gmail.com>.
Alex,
I am sure nobody here said anything against your job and contribution.
As a starting point is great!
And at least you get us started on this. And thank you for your hard work.
But I would be careful with a gurus. There is as many JS gurus as styles
they invented.
And the guy behind jQuery hmm.. if you are performance lover you have no
idea how big damage he did to the JS community.
Every single method up there is 100x slower to compare to native JS.
People love it because is simple to use.
Because they are too lazy to learn the core and basic concepts behind
it. This language is flexible enough to write Action Script on top of it!
But jQuery trade off, 100x or even 1000x sometimes proves is not worth
it. Is a Be or Not-To-Be for a lot of applications.
Check how many tests on jsperf are putting jQuery into shame.
And pushing this into mobile development is complete misunderstanding of
the current state of art.
I do believe that it is possible to make a easy to develop environment
and spit out efficient code on the other side.
And not many ongoing development in this area has as much opportunity to
get something done well as Apache has at the moment.
Building on efficient solution/foundation is important, because from now
on thing can only slow down.
Just my 2 cents
Dan
On 11/28/2012 9:35 PM, Alex Harui wrote:
> And [1] is:
>
> [1] http://ejohn.org/blog/simple-javascript-inheritance/
>
>
> On 11/28/12 1:23 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>> On 11/28/12 12:32 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
>>
>>> It looks like adobe.js is using the constructor method as a kind of
>>> marker function, and compiling the actual constructor into the 'init'
>>> method (which is weird IMHO, since you can inherit from the parent
>>> constructor, and protect the prototype chain without calling the
>>> constructor via other means - and many AS3 classes may already
>>> legitimately be using an init method for other purposes, creating a
>>> collision).
>> FWIW, the adobe.js file was cooked up by me. The original engineer did not
>> include it in the donation and I never saw his version. Based on some
>> comments in the FalconJS code, I started with the code at [1] and modified
>> it until it actually did something. So, since I'm a JS newbie I could have
>> screwed up something, but I'm pretty sure the code at [1] is the correct
>> starting point for what FalconJS outputs.
>>
>> The init() name collision caught me too, but I think it would be easy to
>> change it so something a bit more obfuscated.
>>> So, the adobe.extend( 'name', SuperRef ) - the SuperRef is the marker
>>> function, and when you call extend it should be invoking the super
>>> constructor (line 88 in adobe.js).
>>>
>>> For methods, if a method name exists on parent, and also exists on
>>> child, the extend method is adding a closure, which will preserve, and
>>> then invoke the parent's method in _super() (line 75 in adobe.js).
>> As you probably know better than me, the author of [1] is a pretty
>> well-known JS guru. I haven't looked at his other work like Jquery to see
>> if he uses this pattern there or has since become a convert to some other
>> pattern. But for now I have to assume there was some important reason for
>> every line of the code. Was it just to get instanceof to work?
>>
>> I don't really care what the output code looks like, but I do know I don't
>> have the ability to quickly change the output code so I am working on other
>> aspects and hoping some other volunteer will do that if so motivated.
>>> I didn't notice any place in the example code where super was invoked
>>> directly, so I'm not sure how Falcon handles that.
>> Did you really mean Falcon here or FalconJS? I'm not sure I understood
>> this. I don't think you can use super from outside the class to skip around
>> an override like I think you can in C++.
>>> From a quick look anyway.
>>>
>>> Kevin N.
>>>
>>>
>>> On 11/28/12 2:54 PM, Daniel Wasilewski wrote:
>>>> Can any JS savvy person here tell me how according to adobe.js module
>>>> pattern call super? I just lost my head..., got 3 classes extending
>>>> each other and the only top one call init(); I am preparing those
>>>> performance tests for comparison.
>>>>
>>>> Dan
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
And [1] is:
[1] http://ejohn.org/blog/simple-javascript-inheritance/
On 11/28/12 1:23 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 11/28/12 12:32 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
>
>> It looks like adobe.js is using the constructor method as a kind of
>> marker function, and compiling the actual constructor into the 'init'
>> method (which is weird IMHO, since you can inherit from the parent
>> constructor, and protect the prototype chain without calling the
>> constructor via other means - and many AS3 classes may already
>> legitimately be using an init method for other purposes, creating a
>> collision).
> FWIW, the adobe.js file was cooked up by me. The original engineer did not
> include it in the donation and I never saw his version. Based on some
> comments in the FalconJS code, I started with the code at [1] and modified
> it until it actually did something. So, since I'm a JS newbie I could have
> screwed up something, but I'm pretty sure the code at [1] is the correct
> starting point for what FalconJS outputs.
>
> The init() name collision caught me too, but I think it would be easy to
> change it so something a bit more obfuscated.
>>
>> So, the adobe.extend( 'name', SuperRef ) - the SuperRef is the marker
>> function, and when you call extend it should be invoking the super
>> constructor (line 88 in adobe.js).
>>
>> For methods, if a method name exists on parent, and also exists on
>> child, the extend method is adding a closure, which will preserve, and
>> then invoke the parent's method in _super() (line 75 in adobe.js).
> As you probably know better than me, the author of [1] is a pretty
> well-known JS guru. I haven't looked at his other work like Jquery to see
> if he uses this pattern there or has since become a convert to some other
> pattern. But for now I have to assume there was some important reason for
> every line of the code. Was it just to get instanceof to work?
>
> I don't really care what the output code looks like, but I do know I don't
> have the ability to quickly change the output code so I am working on other
> aspects and hoping some other volunteer will do that if so motivated.
>>
>> I didn't notice any place in the example code where super was invoked
>> directly, so I'm not sure how Falcon handles that.
> Did you really mean Falcon here or FalconJS? I'm not sure I understood
> this. I don't think you can use super from outside the class to skip around
> an override like I think you can in C++.
>>
>> From a quick look anyway.
>>
>> Kevin N.
>>
>>
>> On 11/28/12 2:54 PM, Daniel Wasilewski wrote:
>>> Can any JS savvy person here tell me how according to adobe.js module
>>> pattern call super? I just lost my head..., got 3 classes extending
>>> each other and the only top one call init(); I am preparing those
>>> performance tests for comparison.
>>>
>>> Dan
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 12:32 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
> It looks like adobe.js is using the constructor method as a kind of
> marker function, and compiling the actual constructor into the 'init'
> method (which is weird IMHO, since you can inherit from the parent
> constructor, and protect the prototype chain without calling the
> constructor via other means - and many AS3 classes may already
> legitimately be using an init method for other purposes, creating a
> collision).
FWIW, the adobe.js file was cooked up by me. The original engineer did not
include it in the donation and I never saw his version. Based on some
comments in the FalconJS code, I started with the code at [1] and modified
it until it actually did something. So, since I'm a JS newbie I could have
screwed up something, but I'm pretty sure the code at [1] is the correct
starting point for what FalconJS outputs.
The init() name collision caught me too, but I think it would be easy to
change it so something a bit more obfuscated.
>
> So, the adobe.extend( 'name', SuperRef ) - the SuperRef is the marker
> function, and when you call extend it should be invoking the super
> constructor (line 88 in adobe.js).
>
> For methods, if a method name exists on parent, and also exists on
> child, the extend method is adding a closure, which will preserve, and
> then invoke the parent's method in _super() (line 75 in adobe.js).
As you probably know better than me, the author of [1] is a pretty
well-known JS guru. I haven't looked at his other work like Jquery to see
if he uses this pattern there or has since become a convert to some other
pattern. But for now I have to assume there was some important reason for
every line of the code. Was it just to get instanceof to work?
I don't really care what the output code looks like, but I do know I don't
have the ability to quickly change the output code so I am working on other
aspects and hoping some other volunteer will do that if so motivated.
>
> I didn't notice any place in the example code where super was invoked
> directly, so I'm not sure how Falcon handles that.
Did you really mean Falcon here or FalconJS? I'm not sure I understood
this. I don't think you can use super from outside the class to skip around
an override like I think you can in C++.
>
> From a quick look anyway.
>
> Kevin N.
>
>
> On 11/28/12 2:54 PM, Daniel Wasilewski wrote:
>> Can any JS savvy person here tell me how according to adobe.js module
>> pattern call super? I just lost my head..., got 3 classes extending
>> each other and the only top one call init(); I am preparing those
>> performance tests for comparison.
>>
>> Dan
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Kevin Newman <Ca...@unFocus.com>.
It looks like adobe.js is using the constructor method as a kind of
marker function, and compiling the actual constructor into the 'init'
method (which is weird IMHO, since you can inherit from the parent
constructor, and protect the prototype chain without calling the
constructor via other means - and many AS3 classes may already
legitimately be using an init method for other purposes, creating a
collision).
So, the adobe.extend( 'name', SuperRef ) - the SuperRef is the marker
function, and when you call extend it should be invoking the super
constructor (line 88 in adobe.js).
For methods, if a method name exists on parent, and also exists on
child, the extend method is adding a closure, which will preserve, and
then invoke the parent's method in _super() (line 75 in adobe.js).
I didn't notice any place in the example code where super was invoked
directly, so I'm not sure how Falcon handles that.
From a quick look anyway.
Kevin N.
On 11/28/12 2:54 PM, Daniel Wasilewski wrote:
> Can any JS savvy person here tell me how according to adobe.js module
> pattern call super? I just lost my head..., got 3 classes extending
> each other and the only top one call init(); I am preparing those
> performance tests for comparison.
>
> Dan
Re: FalconJS "Demo" checked in
Posted by Daniel Wasilewski <de...@gmail.com>.
Can any JS savvy person here tell me how according to adobe.js module
pattern call super? I just lost my head..., got 3 classes extending each
other and the only top one call init(); I am preparing those performance
tests for comparison.
Dan
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
No, I'm not getting confused here, remember I wrote an ASDoc clone
based off the MXMLC in about 2 weeks. I completely understand what the
difference between Falcon and FalconJS is.
Basically, the MXMLJSC class is the class that does what I listed
below. It almost loads like MXMLC does.
The algorithm is;
- main()
- mainNoExit(args)
- configure(args)
- compile()
- setupJS()
- buildArtifact()
- buildSWFModel()
- buildSWF()
- target:JSTarget.build(mainCU)
JSTarget.build()
- getRootedCompilationUnits() Gets all units
- initializeSWF() creates the ISWF from the compilation unit
- swf.addFrame(mainFrame)
- addToFrame(cu, mainFrame) add unit to frame
buildSWFModel() will return the ISWF to compile()
------------------------------------------------
Everything up to this point was falcon, we have the dependency graph
and compilation units created, now FalconJS impl kicks in.
- loop through all reachable compilation units
- JSWriter writer (JSWriter)swfWriter
- writer.writeTo(output)
The above is the extent to which the whole emitter framework is
exposed within the MXMLJSC compiler.
I know everything up to this point, I used around the same pattern to
make ASDoc. The problem is, when you head into the JSWriter you get
1444 lines of code, then
the JSGenerating reducer has 11,630 lines of code with comments of course.
The problem is, you can't just go into the generating reducer and
writer and change code from js to java. The sematics are all different
for the languages. That is where the custom jburg cmc emitter comes
in. It uses js language specific rules to determine is reducing route.
--------------------------------------------------
Now what I was saying was to reimplement new visitor/emitter code
right at JSWriter writer (JSWriter)swfWriter. To a manageable hand
written visitor emitter.
So basically I am going to create a new writer with my own impl for a
test Java case.
Well, anyway, just writing this out for myself I understand where the line is.
I'm going to do a prototype of something just to answer my own curiosity.
Mike
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 11/28/12 1:06 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> I have experience with code emitting but it used actual AST, no JBurg
>> and no reducers etc.
>>
>> I may be getting confused to what is actually needed in a simple cross
>> compiler but to me it seems;
>>
>> - gather all sourcepaths
>> - gather libraries
>> - execute a build target that will create the compilation units
>> - create a walker/visitor/emitter framework that recursively visits
>> each compilation unit
>> - foreach compilation unit emit the correct code that will create the
>> "mirror" platform code.
>>
>> I know I must sound completely naive here but for what is trying to be
>> accomplished it seems that FalconJS is overly complicated for what it
>> is outputing.
> I think you may be confusing what Falcon does vs FalconJS. FalconJS is only
> about 40 java files and leverages hundreds of classes from Falcon. AFAICT,
> the entire buildup of the AST is all in Falcon code. I believe that Falcon
> code is scanning source paths and library paths and parsing SWCs in order to
> build out the symbol table to resolve references in the .AS files and fail
> on missing references. It won't let you cheat and write code that may
> survive in JS but wouldn't in plain AS compilation. Then once the units are
> parsed it seems to go through the reduce/emitter/writer to create .JS files.
>>
>> From my research, it seems the engineers just copied a lot of classes
>> over from the ABC byte code generation framework and replaced things
>> to fit a javascript impl.
> Yup, I think there is subclassing and substitution going on to replace the
> SWF/ABC output pipeline with JS output.
>>
>> I know they created a "backend" API but to me again and PLEASE some
>> one that is 100 times smarter than me tell me I'm wrong in assuming to
>> create JS or Java you could just loop through compilation units and
>> use a hand written visitor/emitter?!
> I don't know what the backend API looks like. It appears to be that you can
> replace which Reducer/Emitter/Writer gets used. I'm still not clear how
> Jburg fits into the mix, but I also wonder whether you can rewrite the code
> in a copy of the JS CMC emitter to emit Java constructs instead and not need
> to know Jburg.
>
>>
>> So.. really I am out of my ballpark with even trying to understand the
>> JS classes they have because they are connected to 100's of different
>> objects being passed around.
> AFAICT, the JS classes are being handed AST entities to reduce to output
> code. If you are trying to follow code in the debugger, keep in mind that
> there is a thread for each compilation unit and they sometimes block.
>
> But it still seems like it could be as simple as changing all of the emitter
> method to generate .java instead of .js.
>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>>
>>> Ok,
>>>
>>> Challenge accepted.
>>>
>>> I was just looking through the cmc-js.jbg file. I actually think
>>> this might be doable. The JavaScript impl looks very complicated
>>> but, that's because it's doing a lot of things right now as far as
>>> building the .js code.
>>>
>>> I'm going to start small and see what I get. The first order of
>>> business is just trying to hack together the base framework
>>> (emitter) using FalconJS as a template.
>>>
>>> If I can get C working we are going somwhere. That will take awhile,
>>> I'll let you know what I discover.
>>>
>>> Mike
>>>
>>>
>>> Quoting Alex Harui <ah...@adobe.com>:
>>>
>>>>
>>>>
>>>>
>>>> On 11/28/12 11:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>
>>>>
>>>>>
>>>>> Are we creating just views? Are we creating business logic? As you can
>>>>> see I have confused myself here.
>>>>>
>>>>> What would be really kewl is if someone reading this says, Mike I bet
>>>>> you can go from A to B to C then D. If I saw the whole prototype flow
>>>>> in front of me I probably could make it work some how.
>>>> OK, so if you take the code I've checked in, the workflow is this:
>>>>
>>>> A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml
>>>> and Model.as
>>>> and Controller.as
>>>> B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
>>>> MyInitialViewMXML.mxml to MyInitialView.as
>>>> C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
>>>> D) I get a bunch of JS files
>>>> E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
>>>> F) I hand-create an index.html to load all of the .js files
>>>> G) I run it in the browser (FireFox).
>>>>
>>>> The parallel as I see it is that you start with B and:
>>>> C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
>>>> D') You get a .jar
>>>> E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar. They
>>>> should be thin wrappers on native Android controls, just like framework.js
>>>> is a thin wrapper on native HTML controls
>>>> F') You package it up into an APK.
>>>> G') You run it on Android device.
>>>>>
>>>>> JBurg is just grammar, it took me about 3 months to finally learn
>>>>> ANTLR and it's rewriting syntax. So if I had a clear path of what I
>>>>> was trying to prototype with Java I would put time into learning JBurg.
>>>>>
>>>>> What would be interesting is paralleling what you are implementing in
>>>>> JS (your proto components) with Java Android. I know some people would
>>>>> say this is ridiculous but it would be a path to a prototype.
>>>> What I don't know is if it is 'ridiculous' or not. If it isn't,
>>>> it could be
>>>> pretty cool.
>>>>>
>>>>
>>>> --
>>>> 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
>>>
>>>
>
> --
> 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: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 1:06 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> I have experience with code emitting but it used actual AST, no JBurg
> and no reducers etc.
>
> I may be getting confused to what is actually needed in a simple cross
> compiler but to me it seems;
>
> - gather all sourcepaths
> - gather libraries
> - execute a build target that will create the compilation units
> - create a walker/visitor/emitter framework that recursively visits
> each compilation unit
> - foreach compilation unit emit the correct code that will create the
> "mirror" platform code.
>
> I know I must sound completely naive here but for what is trying to be
> accomplished it seems that FalconJS is overly complicated for what it
> is outputing.
I think you may be confusing what Falcon does vs FalconJS. FalconJS is only
about 40 java files and leverages hundreds of classes from Falcon. AFAICT,
the entire buildup of the AST is all in Falcon code. I believe that Falcon
code is scanning source paths and library paths and parsing SWCs in order to
build out the symbol table to resolve references in the .AS files and fail
on missing references. It won't let you cheat and write code that may
survive in JS but wouldn't in plain AS compilation. Then once the units are
parsed it seems to go through the reduce/emitter/writer to create .JS files.
>
> From my research, it seems the engineers just copied a lot of classes
> over from the ABC byte code generation framework and replaced things
> to fit a javascript impl.
Yup, I think there is subclassing and substitution going on to replace the
SWF/ABC output pipeline with JS output.
>
> I know they created a "backend" API but to me again and PLEASE some
> one that is 100 times smarter than me tell me I'm wrong in assuming to
> create JS or Java you could just loop through compilation units and
> use a hand written visitor/emitter?!
I don't know what the backend API looks like. It appears to be that you can
replace which Reducer/Emitter/Writer gets used. I'm still not clear how
Jburg fits into the mix, but I also wonder whether you can rewrite the code
in a copy of the JS CMC emitter to emit Java constructs instead and not need
to know Jburg.
>
> So.. really I am out of my ballpark with even trying to understand the
> JS classes they have because they are connected to 100's of different
> objects being passed around.
AFAICT, the JS classes are being handed AST entities to reduce to output
code. If you are trying to follow code in the debugger, keep in mind that
there is a thread for each compilation unit and they sometimes block.
But it still seems like it could be as simple as changing all of the emitter
method to generate .java instead of .js.
>
> Mike
>
>
>
>
>
>
>
>
>
> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
>> Ok,
>>
>> Challenge accepted.
>>
>> I was just looking through the cmc-js.jbg file. I actually think
>> this might be doable. The JavaScript impl looks very complicated
>> but, that's because it's doing a lot of things right now as far as
>> building the .js code.
>>
>> I'm going to start small and see what I get. The first order of
>> business is just trying to hack together the base framework
>> (emitter) using FalconJS as a template.
>>
>> If I can get C working we are going somwhere. That will take awhile,
>> I'll let you know what I discover.
>>
>> Mike
>>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 11/28/12 11:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>
>>>
>>>>
>>>> Are we creating just views? Are we creating business logic? As you can
>>>> see I have confused myself here.
>>>>
>>>> What would be really kewl is if someone reading this says, Mike I bet
>>>> you can go from A to B to C then D. If I saw the whole prototype flow
>>>> in front of me I probably could make it work some how.
>>> OK, so if you take the code I've checked in, the workflow is this:
>>>
>>> A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml and Model.as
>>> and Controller.as
>>> B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
>>> MyInitialViewMXML.mxml to MyInitialView.as
>>> C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
>>> D) I get a bunch of JS files
>>> E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
>>> F) I hand-create an index.html to load all of the .js files
>>> G) I run it in the browser (FireFox).
>>>
>>> The parallel as I see it is that you start with B and:
>>> C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
>>> D') You get a .jar
>>> E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar. They
>>> should be thin wrappers on native Android controls, just like framework.js
>>> is a thin wrapper on native HTML controls
>>> F') You package it up into an APK.
>>> G') You run it on Android device.
>>>>
>>>> JBurg is just grammar, it took me about 3 months to finally learn
>>>> ANTLR and it's rewriting syntax. So if I had a clear path of what I
>>>> was trying to prototype with Java I would put time into learning JBurg.
>>>>
>>>> What would be interesting is paralleling what you are implementing in
>>>> JS (your proto components) with Java Android. I know some people would
>>>> say this is ridiculous but it would be a path to a prototype.
>>> What I don't know is if it is 'ridiculous' or not. If it isn't, it could be
>>> pretty cool.
>>>>
>>>
>>> --
>>> 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
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ha,
I just spent 2 hours looking at the code in FalconJS to try and
understand the pattern.
From a highlevel I get what they are doing but when it actually comes
to programming, there is so much indirection and composition I highly
doubt I could even attempt to use this pattern to create anything in
the next 2 years.
I have experience with code emitting but it used actual AST, no JBurg
and no reducers etc.
I may be getting confused to what is actually needed in a simple cross
compiler but to me it seems;
- gather all sourcepaths
- gather libraries
- execute a build target that will create the compilation units
- create a walker/visitor/emitter framework that recursively visits
each compilation unit
- foreach compilation unit emit the correct code that will create the
"mirror" platform code.
I know I must sound completely naive here but for what is trying to be
accomplished it seems that FalconJS is overly complicated for what it
is outputing.
From my research, it seems the engineers just copied a lot of classes
over from the ABC byte code generation framework and replaced things
to fit a javascript impl.
I know they created a "backend" API but to me again and PLEASE some
one that is 100 times smarter than me tell me I'm wrong in assuming to
create JS or Java you could just loop through compilation units and
use a hand written visitor/emitter?!
So.. really I am out of my ballpark with even trying to understand the
JS classes they have because they are connected to 100's of different
objects being passed around.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> Ok,
>
> Challenge accepted.
>
> I was just looking through the cmc-js.jbg file. I actually think
> this might be doable. The JavaScript impl looks very complicated
> but, that's because it's doing a lot of things right now as far as
> building the .js code.
>
> I'm going to start small and see what I get. The first order of
> business is just trying to hack together the base framework
> (emitter) using FalconJS as a template.
>
> If I can get C working we are going somwhere. That will take awhile,
> I'll let you know what I discover.
>
> Mike
>
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>>
>>
>>
>> On 11/28/12 11:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>
>>>
>>> Are we creating just views? Are we creating business logic? As you can
>>> see I have confused myself here.
>>>
>>> What would be really kewl is if someone reading this says, Mike I bet
>>> you can go from A to B to C then D. If I saw the whole prototype flow
>>> in front of me I probably could make it work some how.
>> OK, so if you take the code I've checked in, the workflow is this:
>>
>> A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml and Model.as
>> and Controller.as
>> B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
>> MyInitialViewMXML.mxml to MyInitialView.as
>> C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
>> D) I get a bunch of JS files
>> E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
>> F) I hand-create an index.html to load all of the .js files
>> G) I run it in the browser (FireFox).
>>
>> The parallel as I see it is that you start with B and:
>> C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
>> D') You get a .jar
>> E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar. They
>> should be thin wrappers on native Android controls, just like framework.js
>> is a thin wrapper on native HTML controls
>> F') You package it up into an APK.
>> G') You run it on Android device.
>>>
>>> JBurg is just grammar, it took me about 3 months to finally learn
>>> ANTLR and it's rewriting syntax. So if I had a clear path of what I
>>> was trying to prototype with Java I would put time into learning JBurg.
>>>
>>> What would be interesting is paralleling what you are implementing in
>>> JS (your proto components) with Java Android. I know some people would
>>> say this is ridiculous but it would be a path to a prototype.
>> What I don't know is if it is 'ridiculous' or not. If it isn't, it could be
>> pretty cool.
>>>
>>
>> --
>> 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
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ok,
Challenge accepted.
I was just looking through the cmc-js.jbg file. I actually think this
might be doable. The JavaScript impl looks very complicated but,
that's because it's doing a lot of things right now as far as building
the .js code.
I'm going to start small and see what I get. The first order of
business is just trying to hack together the base framework (emitter)
using FalconJS as a template.
If I can get C working we are going somwhere. That will take awhile,
I'll let you know what I discover.
Mike
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 11/28/12 11:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>
>>
>> Are we creating just views? Are we creating business logic? As you can
>> see I have confused myself here.
>>
>> What would be really kewl is if someone reading this says, Mike I bet
>> you can go from A to B to C then D. If I saw the whole prototype flow
>> in front of me I probably could make it work some how.
> OK, so if you take the code I've checked in, the workflow is this:
>
> A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml and Model.as
> and Controller.as
> B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
> MyInitialViewMXML.mxml to MyInitialView.as
> C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
> D) I get a bunch of JS files
> E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
> F) I hand-create an index.html to load all of the .js files
> G) I run it in the browser (FireFox).
>
> The parallel as I see it is that you start with B and:
> C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
> D') You get a .jar
> E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar. They
> should be thin wrappers on native Android controls, just like framework.js
> is a thin wrapper on native HTML controls
> F') You package it up into an APK.
> G') You run it on Android device.
>>
>> JBurg is just grammar, it took me about 3 months to finally learn
>> ANTLR and it's rewriting syntax. So if I had a clear path of what I
>> was trying to prototype with Java I would put time into learning JBurg.
>>
>> What would be interesting is paralleling what you are implementing in
>> JS (your proto components) with Java Android. I know some people would
>> say this is ridiculous but it would be a path to a prototype.
> What I don't know is if it is 'ridiculous' or not. If it isn't, it could be
> pretty cool.
>>
>
> --
> 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: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 11:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> Are we creating just views? Are we creating business logic? As you can
> see I have confused myself here.
>
> What would be really kewl is if someone reading this says, Mike I bet
> you can go from A to B to C then D. If I saw the whole prototype flow
> in front of me I probably could make it work some how.
OK, so if you take the code I've checked in, the workflow is this:
A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml and Model.as
and Controller.as
B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
MyInitialViewMXML.mxml to MyInitialView.as
C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
D) I get a bunch of JS files
E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
F) I hand-create an index.html to load all of the .js files
G) I run it in the browser (FireFox).
The parallel as I see it is that you start with B and:
C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
D') You get a .jar
E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar. They
should be thin wrappers on native Android controls, just like framework.js
is a thin wrapper on native HTML controls
F') You package it up into an APK.
G') You run it on Android device.
>
> JBurg is just grammar, it took me about 3 months to finally learn
> ANTLR and it's rewriting syntax. So if I had a clear path of what I
> was trying to prototype with Java I would put time into learning JBurg.
>
> What would be interesting is paralleling what you are implementing in
> JS (your proto components) with Java Android. I know some people would
> say this is ridiculous but it would be a path to a prototype.
What I don't know is if it is 'ridiculous' or not. If it isn't, it could be
pretty cool.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 11/28/12 10:48 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>> I think you can pretty much throw away about 1/2 of my thoughts below
>> based in my misunderstanding of the emitter stage. I wanted a visitor
>> pattern, it's being used in the JSEmitter.
> There seems to also be a CMCEmitter as well as a JSEmitter. The
> CMCEmitter.java is generated by Jburg. I tried looking at the Jburg stuff
> and gave up. I hope I don't need to go in there any time soon.
>
> Anyway, now that you understand the code better, any idea what it would take
> to create a FalconJava?
The problem I see is my impulsive thinking. :) When I wrote about that
idea a week or so ago, I didn't think it through, I will be the first
to say it.
I think I can pretty much say that the fact Falcon spits out nasty
javascript as an emitter, java would bee a piece of cake. joke...
The problem is, I would and others need to think about "where" and
"What" would hook into Android java.
Are we creating just views? Are we creating business logic? As you can
see I have confused myself here.
What would be really kewl is if someone reading this says, Mike I bet
you can go from A to B to C then D. If I saw the whole prototype flow
in front of me I probably could make it work some how.
JBurg is just grammar, it took me about 3 months to finally learn
ANTLR and it's rewriting syntax. So if I had a clear path of what I
was trying to prototype with Java I would put time into learning JBurg.
What would be interesting is paralleling what you are implementing in
JS (your proto components) with Java Android. I know some people would
say this is ridiculous but it would be a path to a prototype.
On that note, there is a huge curve we have to overcome to get AS
moving over to
Java with JBurg. I guess the only way to find out is trying to figure
out JBurg. Someone around here is going to have to know it eventually
or we are going to be drifting on a boat with no one knowing how to
sail. :)
I will see if I can get a hello world thing going with the jburg
framework, I haven't even looked at it.
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: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 10:48 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> I think you can pretty much throw away about 1/2 of my thoughts below
> based in my misunderstanding of the emitter stage. I wanted a visitor
> pattern, it's being used in the JSEmitter.
There seems to also be a CMCEmitter as well as a JSEmitter. The
CMCEmitter.java is generated by Jburg. I tried looking at the Jburg stuff
and gave up. I hope I don't need to go in there any time soon.
Anyway, now that you understand the code better, any idea what it would take
to create a FalconJava?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Thanks for the information.
I'm not afraid of the compiler for sure, it was the reducer and abc
stuff that confused me. After reading what you wrote about the reducer
I just went back to the code and looked at it again with a fresh
perspective and see it's basically the visitor pattern that most cross
compilers use.
My point was that there will be people creating components and there
will be people developing Falcon and FalconJS. I will be in the latter
camp, developing the compiler and emitter.
So, my first impression was man, I don't understand this. Which just
meant I want to work on it but it seems to technical dealing with ABC.
Now that I read what you wrote my dyslexia turned around and I finally
grasped what it's doing.
My thought about the SWC had to do with the above misinterpretation of
what FalconJS was doing. I understand it's for linking basically.
I think you can pretty much throw away about 1/2 of my thoughts below
based in my misunderstanding of the emitter stage. I wanted a visitor
pattern, it's being used in the JSEmitter.
I really need to write some notes on the wiki...
Mike
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 11/28/12 3:01 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Very interesting Alex. I like this quote:
>>
>> "The initial versions will be relatively feature-poor compared to
>> Flex, but the hope is that the architecture is small enough and
>> modular enough to allow Apache Flex community members, many who are
>> participating in their spare time, to participate without having to be
>> immersed in the internals of the framework."
>>
>> Seems to be the only way out of the forest.
>>
>> So since you actually have a working prototype, what do you see the
>> priorities of action here and the levels of contribution?
> My priority, after finishing the wiki writeup, is to get Falcon working
> better and figure out how to do MXML to JS. Folks are more than welcome to
> help here or try to write new components based on agreed upon goals.
>>
>>
>> I looked at FalconJS. The problem with me is the lowlevel nature of
>> the SWF format being involved in the cross compilation.
> I'm not sure what you mean by that. I don't recall running into any SWF
> related restrictions in getting this demo up. FalconJS does know how to
> consume a SWF in order to process SWCs so that it can resolve symbols when
> compiling your AS files, but I didn't run into anything else, and I am using
> the fact that it does not try to generate JS from the SWCs to my advantage.
> All references to symbols in the SWC are to be replaced by JS that fulfills
> those API contracts.
>
> I'm not an expert on Falcon or FalconJS, but what I think I see is the
> AS/JSCompilation unit creates the AST, then a Reducer gets called to reduce
> it to output format. For a SWF, that is an ABCReducer, for FalconJS it is
> the JSReducer. The Reducers seem to use Emitters to create
> InstructionLists. For a SWF the instruction lists are ABC code, for JS, it
> appears that each instruction list is one instruction long but that
> instruction is a string of JS. All of those instruction lists are
> concatenated then a Writer writes them out. For a SWF it writes ABC blocks
> and I think manages constant pools. For JS I have it wired to write out
> separate JS files, but there is code in there that tries to aggregate them
> and push them through the Closure compiler to get optimized/minified.
>
>> In a way I
>> understand why the engineer chose this route but... are we going to
>> shot oursevles in the foot because we have "one more layer" that
>> community members would have to be proficient in to work on it?
> I think Falcon and FalconJS are well-written enough that there is separation
> of concerns. Folks in the community who don't want to know about the
> compiler won't have to know. This will be especially true once I change
> Falcon to generate data structures instead of code. Then folks who only want
> to write AS code can contribute components or parts of components, and those
> of us who can do compiler work can. But my hope is that the compiler work
> gets done in a way that the main emphasis is on writing AS code, which we
> have more community members who are good at that.
>
>>
>>
>> Also, I haven't put much time into this thought but, since I have now
>> read your "Non-Goals" and "Pay as You Go", I would venture to guess at
>> least exploring a simple implementation using straight AST/IDefinition
>> would be worth checking out with FlaconJS.
> I'm not sure what that means either, but maybe Gordon can offer an opinion.
>>
>> My problem is we have Flacon which is a huge parser/compiler, MXML
>> which is another animal and then FlaconJS which using block code just
>> makes this project insanely complicated for the casual developer.
> If we want to own/control the language we need folks who are not afraid to
> touch the compiler. At least with Falcon I'm happy with the basic way the
> code works. It has not taken me long to be successful in it, compared to
> MXMLC. And it was modular enough to allow FalconJS to happen, and it didn't
> take me too long to get a feel for FalconJS.
>
> But I want to hide all of that from the casual developer, who I expect will
> contribute on the AS/JS side and not ever look at a java file.
>
>>
>> he other problem is I have really no knowledge with the latest and
>> greatest JS techs, so I am seeing what people are saying to even get a
>> clue as to what the output would be.
> Yup, I have no idea what the best output code is. For now, it is working
> and enables me to keep on plugging.
>>
>> Well, a ramble but my post should just say, Should we try a cross
>> compilation impl that only uses the IDefinition/AST Nodes API to keep
>> it simple?
>>
>> Using the proto FalconJS we are STILL tied to Adobe and the SWF/SWC
>> spec, to my knowledge that is not considered ActionScript correct?
> FalconJS is using SWCs but Apache Flex "own" the code that generates SWCs so
> IMO, we are not tied to Adobe. We can change anything we want there as long
> as the Flash runtime can understand it, or doesn't need to run it.
>>
>>
>> Mike
>>
>>
>>
>>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>> Hi,
>>>
>>> I finally got permission to check in a demo that uses FalconJS into my
>>> whiteboard at [1].
>>>
>>> I started a writeup on it on the wiki that I will try to complete tomorrow
>>> at [2].
>>>
>>> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
>>> [2]
>>> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>>>
>>> Thanks,
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>
> --
> 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: FalconJS "Demo" checked in
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 3:01 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Very interesting Alex. I like this quote:
>
> "The initial versions will be relatively feature-poor compared to
> Flex, but the hope is that the architecture is small enough and
> modular enough to allow Apache Flex community members, many who are
> participating in their spare time, to participate without having to be
> immersed in the internals of the framework."
>
> Seems to be the only way out of the forest.
>
> So since you actually have a working prototype, what do you see the
> priorities of action here and the levels of contribution?
My priority, after finishing the wiki writeup, is to get Falcon working
better and figure out how to do MXML to JS. Folks are more than welcome to
help here or try to write new components based on agreed upon goals.
>
>
> I looked at FalconJS. The problem with me is the lowlevel nature of
> the SWF format being involved in the cross compilation.
I'm not sure what you mean by that. I don't recall running into any SWF
related restrictions in getting this demo up. FalconJS does know how to
consume a SWF in order to process SWCs so that it can resolve symbols when
compiling your AS files, but I didn't run into anything else, and I am using
the fact that it does not try to generate JS from the SWCs to my advantage.
All references to symbols in the SWC are to be replaced by JS that fulfills
those API contracts.
I'm not an expert on Falcon or FalconJS, but what I think I see is the
AS/JSCompilation unit creates the AST, then a Reducer gets called to reduce
it to output format. For a SWF, that is an ABCReducer, for FalconJS it is
the JSReducer. The Reducers seem to use Emitters to create
InstructionLists. For a SWF the instruction lists are ABC code, for JS, it
appears that each instruction list is one instruction long but that
instruction is a string of JS. All of those instruction lists are
concatenated then a Writer writes them out. For a SWF it writes ABC blocks
and I think manages constant pools. For JS I have it wired to write out
separate JS files, but there is code in there that tries to aggregate them
and push them through the Closure compiler to get optimized/minified.
> In a way I
> understand why the engineer chose this route but... are we going to
> shot oursevles in the foot because we have "one more layer" that
> community members would have to be proficient in to work on it?
I think Falcon and FalconJS are well-written enough that there is separation
of concerns. Folks in the community who don't want to know about the
compiler won't have to know. This will be especially true once I change
Falcon to generate data structures instead of code. Then folks who only want
to write AS code can contribute components or parts of components, and those
of us who can do compiler work can. But my hope is that the compiler work
gets done in a way that the main emphasis is on writing AS code, which we
have more community members who are good at that.
>
>
> Also, I haven't put much time into this thought but, since I have now
> read your "Non-Goals" and "Pay as You Go", I would venture to guess at
> least exploring a simple implementation using straight AST/IDefinition
> would be worth checking out with FlaconJS.
I'm not sure what that means either, but maybe Gordon can offer an opinion.
>
> My problem is we have Flacon which is a huge parser/compiler, MXML
> which is another animal and then FlaconJS which using block code just
> makes this project insanely complicated for the casual developer.
If we want to own/control the language we need folks who are not afraid to
touch the compiler. At least with Falcon I'm happy with the basic way the
code works. It has not taken me long to be successful in it, compared to
MXMLC. And it was modular enough to allow FalconJS to happen, and it didn't
take me too long to get a feel for FalconJS.
But I want to hide all of that from the casual developer, who I expect will
contribute on the AS/JS side and not ever look at a java file.
>
> he other problem is I have really no knowledge with the latest and
> greatest JS techs, so I am seeing what people are saying to even get a
> clue as to what the output would be.
Yup, I have no idea what the best output code is. For now, it is working
and enables me to keep on plugging.
>
> Well, a ramble but my post should just say, Should we try a cross
> compilation impl that only uses the IDefinition/AST Nodes API to keep
> it simple?
>
> Using the proto FalconJS we are STILL tied to Adobe and the SWF/SWC
> spec, to my knowledge that is not considered ActionScript correct?
FalconJS is using SWCs but Apache Flex "own" the code that generates SWCs so
IMO, we are not tied to Adobe. We can change anything we want there as long
as the Flash runtime can understand it, or doesn't need to run it.
>
>
> Mike
>
>
>
>
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>> Hi,
>>
>> I finally got permission to check in a demo that uses FalconJS into my
>> whiteboard at [1].
>>
>> I started a writeup on it on the wiki that I will try to complete tomorrow
>> at [2].
>>
>> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
>> [2] https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>>
>> Thanks,
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS "Demo" checked in
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Very interesting Alex. I like this quote:
"The initial versions will be relatively feature-poor compared to
Flex, but the hope is that the architecture is small enough and
modular enough to allow Apache Flex community members, many who are
participating in their spare time, to participate without having to be
immersed in the internals of the framework."
Seems to be the only way out of the forest.
So since you actually have a working prototype, what do you see the
priorities of action here and the levels of contribution?
I looked at FalconJS. The problem with me is the lowlevel nature of
the SWF format being involved in the cross compilation. In a way I
understand why the engineer chose this route but... are we going to
shot oursevles in the foot because we have "one more layer" that
community members would have to be proficient in to work on it?
Also, I haven't put much time into this thought but, since I have now
read your "Non-Goals" and "Pay as You Go", I would venture to guess at
least exploring a simple implementation using straight AST/IDefinition
would be worth checking out with FlaconJS.
My problem is we have Flacon which is a huge parser/compiler, MXML
which is another animal and then FlaconJS which using block code just
makes this project insanely complicated for the casual developer.
he other problem is I have really no knowledge with the latest and
greatest JS techs, so I am seeing what people are saying to even get a
clue as to what the output would be.
Well, a ramble but my post should just say, Should we try a cross
compilation impl that only uses the IDefinition/AST Nodes API to keep
it simple?
Using the proto FalconJS we are STILL tied to Adobe and the SWF/SWC
spec, to my knowledge that is not considered ActionScript correct?
Mike
Quoting Alex Harui <ah...@adobe.com>:
> Hi,
>
> I finally got permission to check in a demo that uses FalconJS into my
> whiteboard at [1].
>
> I started a writeup on it on the wiki that I will try to complete tomorrow
> at [2].
>
> [1] http://svn.apache.org/viewvc/incubator/flex/whiteboard/aharui/flexjs
> [2] https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>
> Thanks,
> --
> 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