[FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Hi,

Well, I spent the last 4 days working on this to where it was  
something we all could start talking about.

Is it viable?, I really think so. I have spent a lot of time tinkering  
with the framework, take a look. It's in my whiteboard for now under 2  
Eclipse projects.

I know there was just a discussion about .project files but I  
committed the .project and .classpath for both application and test  
project, just like the rest of Falcon.

I'm working on more documentation. A thing to note about the code, my  
goal is to product ActionScript first, I will explain my thinking  
later but, since I'm the one putting this together, that is what I  
decided was best for testing first. Once we get all ActionScript  
generating, we start overriding things for JavaScript specific  
implementations.

Source [0]

Right now I have 103 unit tests ALL passing for expressions and  
statements. Its a good start.

Note; I have not don't a build file, if anybody wants to go for it.  
Please, I hate them. :)

Peace,
Mike

- [0] https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/

-- 


Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Gordon Smith <go...@adobe.com>]

Bernd Paradies may have had a different reason for using the BURM... I don't really know.

- Gordon

-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com] 
Sent: Friday, December 14, 2012 12:03 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

Thanks Gordon!

The really answered a question I had and also explains why you didn't just use the ANTLR rewriter to create the tree or nodes during parsing. I really understand now.

And as you said, a top down walk should work for what we have to do and it is quite maintainable. Which will mean more development from more devs.

Our current plans involve running generated js through googles closure compiler which drastically optimizes the code before it even gets to the browser's parser and compiler.

Thanks for the info.

Mike

Quoting Gordon Smith <go...@adobe.com>:

> I would be surprised if the BURM is faster than a simple top-down walk.
>
> The main advantage of using a BURM is that it allows for optimizations 
> to be easily coded as alternate reductions with lower cost. Typically 
> there are many difference sequences of bottom-up reductions that could 
> be applied to reduce the tree, and the BURM actually computes the 
> *lowest-cost*  sequence out of all possible sequences. (It is solving 
> a complicated optimization problem, although in an efficient way.)
>
> As a trivial example, in addition to writing a reduction for
>
>     expression + expression
>
> that reduces
>
>     a + b
>
> to instructions like
>
>     push a
>     push b
>     add
>
> and
>
>     1 + 2
>
> to (inefficient) instructions like
>
>     push 1
>     push 2
>     add
>
> you can write a reduction for
>
>     constant + constant
>
> and assign it a lower "cost" so that
>
>     1 + 2
>
> reduces to
>
>     push 3
>
> In the case of JavaScript, I'll bet that today's JavaScript engines 
> are good at doing various optimizations, so I don't see why an
> AS->JS cross-compiler needs to do them in advance using a BURM.
>
> - Gordon
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, December 14, 2012 10:34 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FalconJx] Prototype ActionScript -> JavaScript compiler 
> code up in svn
>
>
>
>
> On 12/14/12 10:04 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> Dude,
>>>>
>>>> "goog" it is.
>>>>
>>>> I just needed a little pep-talk, I guess ;-)
>>> Right now, I'm trying to get FalconJS to compile an MXML file and 
>>> output the goog stuff.  That work got delayed because there were 
>>> more distractions from the 4.9 release than I expected.  Then I will 
>>> try to get the BURM/Reducer/Emitter to do the same.  Mike sent me 
>>> what he tried to do in this area so I can reference it if needed.
>>>
>>> We are definitely in prototype/research mode and different angles 
>>> should be investigated.  The key to the "Apache Way" is that if we 
>>> have to make choices in deciding what to ship, it should be done on 
>>> technical merit.
>>
>> What context are you speaking from? compiler, js framework?
> In theory, everything in Apache is decided on technical merit.  If 
> your version of AS to JS turns out to be faster and easier to 
> maintain, it will win.
>
> It will be interesting to figure out what to do if the BURM version is 
> significantly faster, but my gut says that won't be the case.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Thanks Gordon!

The really answered a question I had and also explains why you didn't  
just use the ANTLR rewriter to create the tree or nodes during  
parsing. I really understand now.

And as you said, a top down walk should work for what we have to do  
and it is quite maintainable. Which will mean more development from  
more devs.

Our current plans involve running generated js through googles closure  
compiler which drastically optimizes the code before it even gets to  
the browser's parser and compiler.

Thanks for the info.

Mike

Quoting Gordon Smith <go...@adobe.com>:

> I would be surprised if the BURM is faster than a simple top-down walk.
>
> The main advantage of using a BURM is that it allows for  
> optimizations to be easily coded as alternate reductions with lower  
> cost. Typically there are many difference sequences of bottom-up  
> reductions that could be applied to reduce the tree, and the BURM  
> actually computes the *lowest-cost*  sequence out of all possible  
> sequences. (It is solving a complicated optimization problem,  
> although in an efficient way.)
>
> As a trivial example, in addition to writing a reduction for
>
>     expression + expression
>
> that reduces
>
>     a + b
>
> to instructions like
>
>     push a
>     push b
>     add
>
> and
>
>     1 + 2
>
> to (inefficient) instructions like
>
>     push 1
>     push 2
>     add
>
> you can write a reduction for
>
>     constant + constant
>
> and assign it a lower "cost" so that
>
>     1 + 2
>
> reduces to
>
>     push 3
>
> In the case of JavaScript, I'll bet that today's JavaScript engines  
> are good at doing various optimizations, so I don't see why an  
> AS->JS cross-compiler needs to do them in advance using a BURM.
>
> - Gordon
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, December 14, 2012 10:34 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FalconJx] Prototype ActionScript -> JavaScript  
> compiler code up in svn
>
>
>
>
> On 12/14/12 10:04 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> Dude,
>>>>
>>>> "goog" it is.
>>>>
>>>> I just needed a little pep-talk, I guess ;-)
>>> Right now, I'm trying to get FalconJS to compile an MXML file and
>>> output the goog stuff.  That work got delayed because there were more
>>> distractions from the 4.9 release than I expected.  Then I will try
>>> to get the BURM/Reducer/Emitter to do the same.  Mike sent me what he
>>> tried to do in this area so I can reference it if needed.
>>>
>>> We are definitely in prototype/research mode and different angles
>>> should be investigated.  The key to the "Apache Way" is that if we
>>> have to make choices in deciding what to ship, it should be done  
>>> on technical merit.
>>
>> What context are you speaking from? compiler, js framework?
> In theory, everything in Apache is decided on technical merit.  If  
> your version of AS to JS turns out to be faster and easier to  
> maintain, it will win.
>
> It will be interesting to figure out what to do if the BURM version  
> is significantly faster, but my gut says that won't be the case.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

Maybe initial design of FalconJS was design for future Flex Builder in 
mind. I have seen some demo showing how cool will be to see changes on 
runtime without compiling a project, but it was done in AS3. BURM will 
definitely be the way to go in that case. But just wonder if both 
solutions can actually work together under one enviroment and produce 
the same output? Or even help to optimise the code?

On 12/14/2012 7:31 PM, Gordon Smith wrote:
> I would be surprised if the BURM is faster than a simple top-down walk.
>
> The main advantage of using a BURM is that it allows for optimizations to be easily coded as alternate reductions with lower cost. Typically there are many difference sequences of bottom-up reductions that could be applied to reduce the tree, and the BURM actually computes the *lowest-cost*  sequence out of all possible sequences. (It is solving a complicated optimization problem, although in an efficient way.)
>
> As a trivial example, in addition to writing a reduction for
>
>      expression + expression
>
> that reduces
>
>      a + b
>
> to instructions like
>
>      push a
>      push b
>      add
>
> and
>
>      1 + 2
>
> to (inefficient) instructions like
>
>      push 1
>      push 2
>      add
>
> you can write a reduction for
>
>      constant + constant
>
> and assign it a lower "cost" so that
>
>      1 + 2
>
> reduces to
>
>      push 3
>
> In the case of JavaScript, I'll bet that today's JavaScript engines are good at doing various optimizations, so I don't see why an AS->JS cross-compiler needs to do them in advance using a BURM.
>
> - Gordon
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, December 14, 2012 10:34 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn
>
>
>
>
> On 12/14/12 10:04 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>> On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> Dude,
>>>>
>>>> "goog" it is.
>>>>
>>>> I just needed a little pep-talk, I guess ;-)
>>> Right now, I'm trying to get FalconJS to compile an MXML file and
>>> output the goog stuff.  That work got delayed because there were more
>>> distractions from the 4.9 release than I expected.  Then I will try
>>> to get the BURM/Reducer/Emitter to do the same.  Mike sent me what he
>>> tried to do in this area so I can reference it if needed.
>>>
>>> We are definitely in prototype/research mode and different angles
>>> should be investigated.  The key to the "Apache Way" is that if we
>>> have to make choices in deciding what to ship, it should be done on technical merit.
>> What context are you speaking from? compiler, js framework?
> In theory, everything in Apache is decided on technical merit.  If your version of AS to JS turns out to be faster and easier to maintain, it will win.
>
> It will be interesting to figure out what to do if the BURM version is significantly faster, but my gut says that won't be the case.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>

RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Gordon Smith <go...@adobe.com>]

I would be surprised if the BURM is faster than a simple top-down walk.

The main advantage of using a BURM is that it allows for optimizations to be easily coded as alternate reductions with lower cost. Typically there are many difference sequences of bottom-up reductions that could be applied to reduce the tree, and the BURM actually computes the *lowest-cost*  sequence out of all possible sequences. (It is solving a complicated optimization problem, although in an efficient way.) 

As a trivial example, in addition to writing a reduction for

    expression + expression

that reduces

    a + b

to instructions like

    push a
    push b
    add

and

    1 + 2

to (inefficient) instructions like

    push 1
    push 2
    add

you can write a reduction for

    constant + constant

and assign it a lower "cost" so that

    1 + 2

reduces to

    push 3

In the case of JavaScript, I'll bet that today's JavaScript engines are good at doing various optimizations, so I don't see why an AS->JS cross-compiler needs to do them in advance using a BURM.

- Gordon

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Friday, December 14, 2012 10:34 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn




On 12/14/12 10:04 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:

> 
> Quoting Alex Harui <ah...@adobe.com>:
> 
>> 
>> 
>> 
>> On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> 
>>> Dude,
>>> 
>>> "goog" it is.
>>> 
>>> I just needed a little pep-talk, I guess ;-)
>> Right now, I'm trying to get FalconJS to compile an MXML file and 
>> output the goog stuff.  That work got delayed because there were more 
>> distractions from the 4.9 release than I expected.  Then I will try 
>> to get the BURM/Reducer/Emitter to do the same.  Mike sent me what he 
>> tried to do in this area so I can reference it if needed.
>> 
>> We are definitely in prototype/research mode and different angles 
>> should be investigated.  The key to the "Apache Way" is that if we 
>> have to make choices in deciding what to ship, it should be done on technical merit.
> 
> What context are you speaking from? compiler, js framework?
In theory, everything in Apache is decided on technical merit.  If your version of AS to JS turns out to be faster and easier to maintain, it will win.

It will be interesting to figure out what to do if the BURM version is significantly faster, but my gut says that won't be the case.


--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Sorry I meant the prototype is a "top down walker", bottom down dosn't  
make any sense. :)

Mike

Quoting Michael Schmalle <ap...@teotigraphix.com>:

>
> Quoting Alex Harui <ah...@adobe.com>:
>
>
>>>>
>>>> We are definitely in prototype/research mode and different angles  
>>>> should be
>>>> investigated.  The key to the "Apache Way" is that if we have to make
>>>> choices in deciding what to ship, it should be done on technical merit.
>>>
>>> What context are you speaking from? compiler, js framework?
>> In theory, everything in Apache is decided on technical merit.  If your
>> version of AS to JS turns out to be faster and easier to maintain, it will
>> win.
>>
>> It will be interesting to figure out what to do if the BURM version is
>> significantly faster, but my gut says that won't be the case.
>>
>
> Here is my opinion. All compilers are recursive. The BURM uses  
> grammar to create a tree walker.
>
> That reducer is traversing the tree from the leaf nodes up. What I  
> have written is a bottom down traverse.
>
> What I am saying is that every node it visits in the walker, the  
> visit method knows EXACTLY what nodes are going to be traversed and  
> pushes the recursion down into the specific node.
>
> The before and after strategies may add weight to how fast it's  
> traversing but if it was really an issue, we would get rid of them  
> and use the primary handler and do the before and after logic in the  
> visitor method.
>
> As you can see right now, the before and after handlers are for code  
> clarity and convenience.
>
> Like I said, I don't have enough experience to contribute to the  
> BURM impl with all that ABC stuff intermingled so I guess it will be  
> interesting if the prototype is a dog.
>
> 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
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

FYI,

The design can create javascript at ANY leaf node. This is the way I  
designed it. I said bottom down, that is when compiling a compilation  
unit you would;

visitor.visitCompilationUnit(compilationUnit);

You could also go;

visitor.visitIf(ifNode);

It would only produce the javascript for that if(){} block.

You could do fancy things with offset saving in javascript output if  
you wanted incremental compiles, I don't see where you would need a  
BURM.

BTW, look at the unit tests I have and this is exactly how I am  
testing the visitors creating javascript.

Mike

Quoting Daniel Wasilewski <de...@gmail.com>:

> I can see one adventage of BURM.
>
> When you have an IDE and you expect to see changes in runtime live.  
> It will be always faster to go from particular leaf up to the root,  
> just to update small chunk, instead traversing entire tree. But in a  
> case when you just need to translate entire structure once... no way  
> BURM will be faster.
>
> On 12/14/2012 6:43 PM, Michael Schmalle wrote:
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>
>>>>>
>>>>> We are definitely in prototype/research mode and different  
>>>>> angles should be
>>>>> investigated.  The key to the "Apache Way" is that if we have to make
>>>>> choices in deciding what to ship, it should be done on technical merit.
>>>>
>>>> What context are you speaking from? compiler, js framework?
>>> In theory, everything in Apache is decided on technical merit. If your
>>> version of AS to JS turns out to be faster and easier to maintain, it will
>>> win.
>>>
>>> It will be interesting to figure out what to do if the BURM version is
>>> significantly faster, but my gut says that won't be the case.
>>>
>>
>> Here is my opinion. All compilers are recursive. The BURM uses  
>> grammar to create a tree walker.
>>
>> That reducer is traversing the tree from the leaf nodes up. What I  
>> have written is a bottom down traverse.
>>
>> What I am saying is that every node it visits in the walker, the  
>> visit method knows EXACTLY what nodes are going to be traversed and  
>> pushes the recursion down into the specific node.
>>
>> The before and after strategies may add weight to how fast it's  
>> traversing but if it was really an issue, we would get rid of them  
>> and use the primary handler and do the before and after logic in  
>> the visitor method.
>>
>> As you can see right now, the before and after handlers are for  
>> code clarity and convenience.
>>
>> Like I said, I don't have enough experience to contribute to the  
>> BURM impl with all that ABC stuff intermingled so I guess it will  
>> be interesting if the prototype is a dog.
>>
>> Mike
>>
>>
>>
>>> -- 
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

I can see one adventage of BURM.

When you have an IDE and you expect to see changes in runtime live. It 
will be always faster to go from particular leaf up to the root, just to 
update small chunk, instead traversing entire tree. But in a case when 
you just need to translate entire structure once... no way BURM will be 
faster.

On 12/14/2012 6:43 PM, Michael Schmalle wrote:
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>
>>>>
>>>> We are definitely in prototype/research mode and different angles 
>>>> should be
>>>> investigated.  The key to the "Apache Way" is that if we have to make
>>>> choices in deciding what to ship, it should be done on technical 
>>>> merit.
>>>
>>> What context are you speaking from? compiler, js framework?
>> In theory, everything in Apache is decided on technical merit. If your
>> version of AS to JS turns out to be faster and easier to maintain, it 
>> will
>> win.
>>
>> It will be interesting to figure out what to do if the BURM version is
>> significantly faster, but my gut says that won't be the case.
>>
>
> Here is my opinion. All compilers are recursive. The BURM uses grammar 
> to create a tree walker.
>
> That reducer is traversing the tree from the leaf nodes up. What I 
> have written is a bottom down traverse.
>
> What I am saying is that every node it visits in the walker, the visit 
> method knows EXACTLY what nodes are going to be traversed and pushes 
> the recursion down into the specific node.
>
> The before and after strategies may add weight to how fast it's 
> traversing but if it was really an issue, we would get rid of them and 
> use the primary handler and do the before and after logic in the 
> visitor method.
>
> As you can see right now, the before and after handlers are for code 
> clarity and convenience.
>
> Like I said, I don't have enough experience to contribute to the BURM 
> impl with all that ABC stuff intermingled so I guess it will be 
> interesting if the prototype is a dog.
>
> Mike
>
>
>
>> -- 
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Alex Harui <ah...@adobe.com>:


>>>
>>> We are definitely in prototype/research mode and different angles should be
>>> investigated.  The key to the "Apache Way" is that if we have to make
>>> choices in deciding what to ship, it should be done on technical merit.
>>
>> What context are you speaking from? compiler, js framework?
> In theory, everything in Apache is decided on technical merit.  If your
> version of AS to JS turns out to be faster and easier to maintain, it will
> win.
>
> It will be interesting to figure out what to do if the BURM version is
> significantly faster, but my gut says that won't be the case.
>

Here is my opinion. All compilers are recursive. The BURM uses grammar  
to create a tree walker.

That reducer is traversing the tree from the leaf nodes up. What I  
have written is a bottom down traverse.

What I am saying is that every node it visits in the walker, the visit  
method knows EXACTLY what nodes are going to be traversed and pushes  
the recursion down into the specific node.

The before and after strategies may add weight to how fast it's  
traversing but if it was really an issue, we would get rid of them and  
use the primary handler and do the before and after logic in the  
visitor method.

As you can see right now, the before and after handlers are for code  
clarity and convenience.

Like I said, I don't have enough experience to contribute to the BURM  
impl with all that ABC stuff intermingled so I guess it will be  
interesting if the prototype is a dog.

Mike



> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Alex Harui <ah...@adobe.com>]

On 12/14/12 10:04 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:

> 
> Quoting Alex Harui <ah...@adobe.com>:
> 
>> 
>> 
>> 
>> On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> 
>>> Dude,
>>> 
>>> "goog" it is.
>>> 
>>> I just needed a little pep-talk, I guess ;-)
>> Right now, I'm trying to get FalconJS to compile an MXML file and output the
>> goog stuff.  That work got delayed because there were more distractions from
>> the 4.9 release than I expected.  Then I will try to get the
>> BURM/Reducer/Emitter to do the same.  Mike sent me what he tried to do in
>> this area so I can reference it if needed.
>> 
>> We are definitely in prototype/research mode and different angles should be
>> investigated.  The key to the "Apache Way" is that if we have to make
>> choices in deciding what to ship, it should be done on technical merit.
> 
> What context are you speaking from? compiler, js framework?
In theory, everything in Apache is decided on technical merit.  If your
version of AS to JS turns out to be faster and easier to maintain, it will
win.

It will be interesting to figure out what to do if the BURM version is
significantly faster, but my gut says that won't be the case.


-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Alex Harui <ah...@adobe.com>:

>
>
>
> On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> Dude,
>>
>> "goog" it is.
>>
>> I just needed a little pep-talk, I guess ;-)
> Right now, I'm trying to get FalconJS to compile an MXML file and output the
> goog stuff.  That work got delayed because there were more distractions from
> the 4.9 release than I expected.  Then I will try to get the
> BURM/Reducer/Emitter to do the same.  Mike sent me what he tried to do in
> this area so I can reference it if needed.
>
> We are definitely in prototype/research mode and different angles should be
> investigated.  The key to the "Apache Way" is that if we have to make
> choices in deciding what to ship, it should be done on technical merit.

What context are you speaking from? compiler, js framework?

I have no doubt that what I am doing can traverse MXML data structures  
or even the AST to produce stuff. I don't know if I am  
misunderstanding what you are saying but, in my honest effort to  
change FalconJS, I realized I cannot do it the way it is based on my  
experience.

So either I can't contribute to javascript cross compiling or I can  
attempt a way that I have used before, which is in the current  
prototype.

Mike

>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Alex Harui <ah...@adobe.com>]

On 12/14/12 4:24 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

> Dude,
> 
> "goog" it is.
> 
> I just needed a little pep-talk, I guess ;-)
Right now, I'm trying to get FalconJS to compile an MXML file and output the
goog stuff.  That work got delayed because there were more distractions from
the 4.9 release than I expected.  Then I will try to get the
BURM/Reducer/Emitter to do the same.  Mike sent me what he tried to do in
this area so I can reference it if needed.

We are definitely in prototype/research mode and different angles should be
investigated.  The key to the "Apache Way" is that if we have to make
choices in deciding what to ship, it should be done on technical merit.


-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Erik de Bruin <er...@ixsoftware.nl>]

Dude,

"goog" it is.

I just needed a little pep-talk, I guess ;-)

EdB



On Fri, Dec 14, 2012 at 10:20 AM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Erik,
>
>
>> So, unless there's people out there that are willing to
>> contribute to Alex's (and now my) approach to getting from AS to JS,
>> my time is spend better helping out on another part of the project.
>
>
> Saying this kindof pisses me off. I just spent the last week writing a
> compiler that will allow us to do any type of cross compile we want.
>
> Dude, you gotta stick to your guns man! If what you decided on for the time
> being is goog, the use it! Frank can have his opinion but, you are doing
> something and that means you need answers which you sought out.
>
> If you research me a bit, I was a component developer since 2003. To say you
> will not get help with the component framework is bs. I'm right here, really
> how many people does it take to make something in the world. Right mow a
> bunch of people would muddle stuff up.
>
> I remember spouting the same crap back in January when I left the project
> for 8 months this year. What I realized is if there was one thing I wanted
> to do, it's allow AS3 to run on something other than the Flash Player. This
> is my main goal, why? I have no freaking reason other than I have to much
> experience in AS3 and the like to throw it away for some "new" language,
> blah blah.
>
> What I am trying to do here is make the lower level. You cannot expect a lot
> of people to help out here, they just don't have a clue what is going on.
> Your a leader, lead my friend and keep going, I will join up when I get the
> compiler working correctly in the prototype.
>
> Mike
>
>
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> I'm not sitting here feeling sorry for myself, I actually learned a
>> lot setting up the current approach. I'm just wondering if it is worth
>> my time to pursue this avenue when everyone else seems more interested
>> in going in a (as far as I understand) completely different direction.
>> Getting this "done" is a major project which I cannot get done on my
>> own. So, unless there's people out there that are willing to
>> contribute to Alex's (and now my) approach to getting from AS to JS,
>> my time is spend better helping out on another part of the project.
>>
>> EdB
>>
>>
>>
>> On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>
>>> So, basically, nobody loves the "goog" approach I spend the last weeks
>>> working on (based mostly on feedback from the various discussion on
>>> the list).
>>>
>>> Or, let me rephrase, nobody cares enough to contribute to it?
>>>
>>> EdB
>>>
>>>
>>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net>
>>> wrote:
>>>>
>>>> This is great news, Mike! I will also try to dig into your code this
>>>> weekend.
>>>> In the meantime, I've been busy figuring out the "essence" of a new
>>>> JavaScript runtime format that uses the principles described in my blog,
>>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>>>> more concise than the current Jangaroo Runtime. For IE8 and other
>>>> non-ES5
>>>> browsers, we would then use polyfills for all ES5 functions used.
>>>> Let's see if I can get an approval from my company to contribute; if it
>>>> takes too long, I'd blog about the concepts and you or someone else
>>>> would
>>>> have to implement them.
>>>> Greetings
>>>> -Frank-
>>>>
>>>>
>>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>>> <ap...@teotigraphix.com>wrote:
>>>>
>>>>> Not really,
>>>>>
>>>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>>>> pieces. I purposely put it all back together myself so I knew what was
>>>>> going on. So every class in the committed code was assembled by me, to
>>>>> figure out it's function if relevant to the new design.
>>>>>
>>>>> Besides most of it had either be deleted of changed because I am not
>>>>> targeting SWF what so ever.
>>>>>
>>>>> I tried to stick with the same base implementation so we kept the
>>>>> multi-threaded Falcon parsing.
>>>>>
>>>>> Take a look at the org.apache.flex.compiler.**internal.js.codegen
>>>>> package.
>>>>>
>>>>> Specifically ASBlockWalker from that class alone you should see that
>>>>> this
>>>>> is a completely different implementation.
>>>>>
>>>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>>>> some javascript emitting specific to the closure compiler. I want to
>>>>> change
>>>>> this and have a base class not dependent on anything but to be able to
>>>>> override it.
>>>>>
>>>>> Case in point, most expressions and statements map the same in AS to
>>>>> JS,
>>>>> so having a base implementation not tied to anything will be a positive
>>>>> thing. I also don't like mixing design specific things in the base
>>>>> traversing class, another reason why I want an abstract base or two.
>>>>>
>>>>> Anyway, very prototype code and I reserve the right to yank things
>>>>> around.
>>>>> :) I just wanted to get it up to show others there might be an easier
>>>>> and
>>>>> more flexible way to get to where we need to go without the BURM.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>
>>>>>  I will try to look this weekend.
>>>>>>
>>>>>>
>>>>>> Can you briefly describe the important files to look at?  Did you copy
>>>>>> the
>>>>>> FalconJS files then do most of your work in a few of them?
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>>>>>>
>>>>>>
>>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>>> something we all could start talking about.
>>>>>>>
>>>>>>> Is it viable?, I really think so. I have spent a lot of time
>>>>>>> tinkering
>>>>>>> with the framework, take a look. It's in my whiteboard for now under
>>>>>>> 2
>>>>>>> Eclipse projects.
>>>>>>>
>>>>>>> I know there was just a discussion about .project files but I
>>>>>>> committed the .project and .classpath for both application and test
>>>>>>> project, just like the rest of Falcon.
>>>>>>>
>>>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>>> later but, since I'm the one putting this together, that is what I
>>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>>> generating, we start overriding things for JavaScript specific
>>>>>>> implementations.
>>>>>>>
>>>>>>> Source [0]
>>>>>>>
>>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>>> statements. Its a good start.
>>>>>>>
>>>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>>>> Please, I hate them. :)
>>>>>>>
>>>>>>> Peace,
>>>>>>> Mike
>>>>>>>
>>>>>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>>>>>>
>>>>>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>>
>>
>>
>> --
>> 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: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Heh,

Dan, what you said below I could agree with 100%. The only reason I am  
writing a cross compiler is for an RIA platform to stand on it, using  
the as you put it "RIA platform, reuse  existing code base, don't dump  
the years of work, experience and  effort."

I will say this for the 4th time, I have an audio framework I am  
developing for Android Java developers that will use the same DSP  
engine found in the Caustic app for Android, take a look [0].

Why bring this up Mike? Adobe taught me one huge lesson in my naive  
business dealings in the past, don't put all your eggs in one basket.  
I already have about 4 different audio apps I will be releasing in the  
next year or two.

This just proves why I am putting time into the cross compiler, I  
"feel" something about it with my intuition. I have been with  
ActionScript since 2001 and Flash 5. Maybe I'm sentimental or maybe I  
have used ActionScript so long that I know how fast I can write  
programs with it. (BTW I don't even write in AS3 right now)

Anyway, we will see, I will keep plugging away at the two sides of my  
brain and see if I meet others along the path.

Mike

- [0] https://github.com/teotigraphix/caustic-core


Quoting Daniel Wasilewski <de...@gmail.com>:

> I am with you Mike on this in 100%.
>
> If I can add something to it.
>
> I would rather thing of Falcon/ FalconJS being contributed to Apache  
> as just a cool name. Code base? Does anybody do care these days of  
> quality of it?
> If possible to investigate a better way of doing it, why not?
>
> Equation was always like  Adobe != Quality-of-code, They've been  
> always trying to get stuff done quickly and monetise it. I don't  
> expect anything more from them.
> This is a corporation not quality control or W3C guardians. You have  
> opportunity to see how Flex source looks like on your own eyes.
>
> I had no plans from very beginning to contribute to Flex itself  
> because I am against of the framework that over the time contributed  
> heavily to the bad reputation of Action Script itself. Encouraged  
> developers to build on top of it and act in Adobe Corp style. Get it  
> done, monetise.
>
> Problem is, when comes to HTML5 Adobe is no longer in control of  
> their runtime. You facing much wider competition and trust me, there  
> is plenty of solutions out there trying to do the same thing from  
> several years. My favourite language-> JS/HTML5. We all know that  
> Flex has been designed by Adobe to attract many developers from  
> different platforms.
>
> Why would I use Flex->JS if can take C++,C#,Java,Python,whatever ->JS?
>
> The only way to make it happen is*not**only* to give you ability to  
> translate from one language to another, but offer RIA platform,  
> reuse existing code base, don't dump the years of work, experience  
> and effort. And make it *competitive*. If some day you will hear,  
> that people using Flex because HTML5 applications it produces are  
> robust, snappier and well performing it is the only reason why this  
> whole project is worth it. Otherwise if you just having plans to get  
> something done, you better put your energy into something else. Some  
> may be short sighted here but this very part FalconJS, that many  
> considering as little subset for now, is something that may even  
> keep the Flex project alive in near future.
>
> And just happened that here is few people capable of making it  
> happen, I would love to see them working together with the same goals.
>
> Dan
>
> On 12/14/2012 10:48 AM, Michael Schmalle wrote:
>> Hey,
>>
>> This is great to hear. I'm kind of a hard head myself. What we are  
>> doing is going against what the majority says is possible.
>>
>> I see petitions to kill the Flash Player, uninstall it from your  
>> browser stuff... You get where I am going with this?
>>
>> Ignorant developers associate ActionScript3 with the Flash Player  
>> and not with a very mature OOP language. With the new Falcon  
>> compiler we have a very powerful tool to transform ActionScript  
>> into something it has never been before, Flash Player independent.  
>> This is my vision.
>>
>> It just so happens that ActionScript and JavaScript share a lot of  
>> the same semantics on the AST level so we have a natural fit.
>>
>> Erik, we need people to bridge the language gap between AS and JS.  
>> You are acting as the translator right now. I know you are not  
>> going to get every translation correct in the start, but you need  
>> to realize this is going to take a few running starts to jump the  
>> divide!
>>
>> To others, I am pretty satisfied with my prototype being a viable  
>> solution to cross compile. That being said, I HAVE NO plans to work  
>> on the older FalconJS code, its just to much of a rats nest and  
>> Adobe left a 1/3 of code in there that has no relevance to our  
>> project.
>>
>> So in my pessimistic voice, if I can't get this prototype to  
>> eventually spit out what we need, that will be it for me. :) But,  
>> 103 granular unit tests prove I am on my way to succeeding with  
>> this design.
>>
>> Mike
>>
>>
>> Quoting Chema Balsas <jb...@gmail.com>:
>>
>>> Hi Erik, I'm with Mike on this one. Lead and others will follow.
>>>
>>> I for one plan to stick around the compiler and mostly the JS generation.
>>> I've still to find the time to dive deep into your approach, but I'll be
>>> working on it for sure. You can definitely count me in.
>>>
>>> Cheers,
>>> Chema
>>>
>>> 2012/12/14 Michael Schmalle <ap...@teotigraphix.com>
>>>
>>>> Erik,
>>>>
>>>>
>>>> So, unless there's people out there that are willing to
>>>>> contribute to Alex's (and now my) approach to getting from AS to JS,
>>>>> my time is spend better helping out on another part of the project.
>>>>>
>>>>
>>>> Saying this kindof pisses me off. I just spent the last week writing a
>>>> compiler that will allow us to do any type of cross compile we want.
>>>>
>>>> Dude, you gotta stick to your guns man! If what you decided on for the
>>>> time being is goog, the use it! Frank can have his opinion but, you are
>>>> doing something and that means you need answers which you sought out.
>>>>
>>>> If you research me a bit, I was a component developer since 2003. To say
>>>> you will not get help with the component framework is bs. I'm right here,
>>>> really how many people does it take to make something in the world. Right
>>>> mow a bunch of people would muddle stuff up.
>>>>
>>>> I remember spouting the same crap back in January when I left the project
>>>> for 8 months this year. What I realized is if there was one thing I wanted
>>>> to do, it's allow AS3 to run on something other than the Flash  
>>>> Player. This
>>>> is my main goal, why? I have no freaking reason other than I have to much
>>>> experience in AS3 and the like to throw it away for some "new" language,
>>>> blah blah.
>>>>
>>>> What I am trying to do here is make the lower level. You cannot expect a
>>>> lot of people to help out here, they just don't have a clue what is going
>>>> on. Your a leader, lead my friend and keep going, I will join up  
>>>> when I get
>>>> the compiler working correctly in the prototype.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>
>>>> I'm not sitting here feeling sorry for myself, I actually learned a
>>>>> lot setting up the current approach. I'm just wondering if it is worth
>>>>> my time to pursue this avenue when everyone else seems more interested
>>>>> in going in a (as far as I understand) completely different direction.
>>>>> Getting this "done" is a major project which I cannot get done on my
>>>>> own. So, unless there's people out there that are willing to
>>>>> contribute to Alex's (and now my) approach to getting from AS to JS,
>>>>> my time is spend better helping out on another part of the project.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>>> wrote:
>>>>>
>>>>>> So, basically, nobody loves the "goog" approach I spend the last weeks
>>>>>> working on (based mostly on feedback from the various discussion on
>>>>>> the list).
>>>>>>
>>>>>> Or, let me rephrase, nobody cares enough to contribute to it?
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net>
>>>>>> wrote:
>>>>>>
>>>>>>> This is great news, Mike! I will also try to dig into your code this
>>>>>>> weekend.
>>>>>>> In the meantime, I've been busy figuring out the "essence" of a new
>>>>>>> JavaScript runtime format that uses the principles described  
>>>>>>> in my blog,
>>>>>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>>>>>>> more concise than the current Jangaroo Runtime. For IE8 and other
>>>>>>> non-ES5
>>>>>>> browsers, we would then use polyfills for all ES5 functions used.
>>>>>>> Let's see if I can get an approval from my company to contribute; if it
>>>>>>> takes too long, I'd blog about the concepts and you or someone else
>>>>>>> would
>>>>>>> have to implement them.
>>>>>>> Greetings
>>>>>>> -Frank-
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>>>>>> <ap...@teotigraphix.com>**wrote:
>>>>>>>
>>>>>>> Not really,
>>>>>>>>
>>>>>>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>>>>>>> pieces. I purposely put it all back together myself so I knew what was
>>>>>>>> going on. So every class in the committed code was assembled by me, to
>>>>>>>> figure out it's function if relevant to the new design.
>>>>>>>>
>>>>>>>> Besides most of it had either be deleted of changed because I am not
>>>>>>>> targeting SWF what so ever.
>>>>>>>>
>>>>>>>> I tried to stick with the same base implementation so we kept the
>>>>>>>> multi-threaded Falcon parsing.
>>>>>>>>
>>>>>>>> Take a look at the org.apache.flex.compiler.****internal.js.codegen
>>>>>>>> package.
>>>>>>>>
>>>>>>>> Specifically ASBlockWalker from that class alone you should see that
>>>>>>>> this
>>>>>>>> is a completely different implementation.
>>>>>>>>
>>>>>>>> A note to others looking at the code, in the ASBlockWalker I  
>>>>>>>> have mixed
>>>>>>>> some javascript emitting specific to the closure compiler. I want to
>>>>>>>> change
>>>>>>>> this and have a base class not dependent on anything but to be able to
>>>>>>>> override it.
>>>>>>>>
>>>>>>>> Case in point, most expressions and statements map the same in AS to
>>>>>>>> JS,
>>>>>>>> so having a base implementation not tied to anything will be  
>>>>>>>> a positive
>>>>>>>> thing. I also don't like mixing design specific things in the base
>>>>>>>> traversing class, another reason why I want an abstract base or two.
>>>>>>>>
>>>>>>>> Anyway, very prototype code and I reserve the right to yank things
>>>>>>>> around.
>>>>>>>> :) I just wanted to get it up to show others there might be an easier
>>>>>>>> and
>>>>>>>> more flexible way to get to where we need to go without the BURM.
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>>>>
>>>>>>>> I will try to look this weekend.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can you briefly describe the important files to look at?  Did you
>>>>>>>>> copy the
>>>>>>>>> FalconJS files then do most of your work in a few of them?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>>>>>> something we all could start talking about.
>>>>>>>>>>
>>>>>>>>>> Is it viable?, I really think so. I have spent a lot of time
>>>>>>>>>> tinkering
>>>>>>>>>> with the framework, take a look. It's in my whiteboard for now under
>>>>>>>>>> 2
>>>>>>>>>> Eclipse projects.
>>>>>>>>>>
>>>>>>>>>> I know there was just a discussion about .project files but I
>>>>>>>>>> committed the .project and .classpath for both application and test
>>>>>>>>>> project, just like the rest of Falcon.
>>>>>>>>>>
>>>>>>>>>> I'm working on more documentation. A thing to note about  
>>>>>>>>>> the code, my
>>>>>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>>>>>> later but, since I'm the one putting this together, that is what I
>>>>>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>>>>>> generating, we start overriding things for JavaScript specific
>>>>>>>>>> implementations.
>>>>>>>>>>
>>>>>>>>>> Source [0]
>>>>>>>>>>
>>>>>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>>>>>> statements. Its a good start.
>>>>>>>>>>
>>>>>>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>>>>>>> Please, I hate them. :)
>>>>>>>>>>
>>>>>>>>>> Peace,
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>> - [0] https://svn.apache.org/repos/****asf/incubator/flex/**
>>>>>>>>>> whiteboard/**<https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**>  
>>>>>>>>>> mschmalle/<https://svn.apache.**org/repos/asf/incubator/flex/**
>>>>>>>>>> whiteboard/mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>  
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Ix Multimedia Software
>>>>>>
>>>>>> Jan Luykenstraat 27
>>>>>> 3521 VB Utrecht
>>>>>>
>>>>>> T. 06-51952295
>>>>>> I. www.ixsoftware.nl
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>>
>>>>>
>>>> -- 
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>>
>>
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

I am with you Mike on this in 100%.

If I can add something to it.

I would rather thing of Falcon/ FalconJS being contributed to Apache as 
just a cool name. Code base? Does anybody do care these days of quality 
of it?
If possible to investigate a better way of doing it, why not?

Equation was always like  Adobe != Quality-of-code, They've been always 
trying to get stuff done quickly and monetise it. I don't expect 
anything more from them.
This is a corporation not quality control or W3C guardians. You have 
opportunity to see how Flex source looks like on your own eyes.

I had no plans from very beginning to contribute to Flex itself because 
I am against of the framework that over the time contributed heavily to 
the bad reputation of Action Script itself. Encouraged developers to 
build on top of it and act in Adobe Corp style. Get it done, monetise.

Problem is, when comes to HTML5 Adobe is no longer in control of their 
runtime. You facing much wider competition and trust me, there is plenty 
of solutions out there trying to do the same thing from several years. 
My favourite language-> JS/HTML5. We all know that Flex has been 
designed by Adobe to attract many developers from different platforms.

Why would I use Flex->JS if can take C++,C#,Java,Python,whatever ->JS?

The only way to make it happen is*not**only* to give you ability to 
translate from one language to another, but offer RIA platform, reuse 
existing code base, don't dump the years of work, experience and effort. 
And make it *competitive*. If some day you will hear, that people using 
Flex because HTML5 applications it produces are robust, snappier and 
well performing it is the only reason why this whole project is worth 
it. Otherwise if you just having plans to get something done, you better 
put your energy into something else. Some may be short sighted here but 
this very part FalconJS, that many considering as little subset for now, 
is something that may even keep the Flex project alive in near future.

And just happened that here is few people capable of making it happen, I 
would love to see them working together with the same goals.

Dan

On 12/14/2012 10:48 AM, Michael Schmalle wrote:
> Hey,
>
> This is great to hear. I'm kind of a hard head myself. What we are 
> doing is going against what the majority says is possible.
>
> I see petitions to kill the Flash Player, uninstall it from your 
> browser stuff... You get where I am going with this?
>
> Ignorant developers associate ActionScript3 with the Flash Player and 
> not with a very mature OOP language. With the new Falcon compiler we 
> have a very powerful tool to transform ActionScript into something it 
> has never been before, Flash Player independent. This is my vision.
>
> It just so happens that ActionScript and JavaScript share a lot of the 
> same semantics on the AST level so we have a natural fit.
>
> Erik, we need people to bridge the language gap between AS and JS. You 
> are acting as the translator right now. I know you are not going to 
> get every translation correct in the start, but you need to realize 
> this is going to take a few running starts to jump the divide!
>
> To others, I am pretty satisfied with my prototype being a viable 
> solution to cross compile. That being said, I HAVE NO plans to work on 
> the older FalconJS code, its just to much of a rats nest and Adobe 
> left a 1/3 of code in there that has no relevance to our project.
>
> So in my pessimistic voice, if I can't get this prototype to 
> eventually spit out what we need, that will be it for me. :) But, 103 
> granular unit tests prove I am on my way to succeeding with this design.
>
> Mike
>
>
> Quoting Chema Balsas <jb...@gmail.com>:
>
>> Hi Erik, I'm with Mike on this one. Lead and others will follow.
>>
>> I for one plan to stick around the compiler and mostly the JS 
>> generation.
>> I've still to find the time to dive deep into your approach, but I'll be
>> working on it for sure. You can definitely count me in.
>>
>> Cheers,
>> Chema
>>
>> 2012/12/14 Michael Schmalle <ap...@teotigraphix.com>
>>
>>> Erik,
>>>
>>>
>>>  So, unless there's people out there that are willing to
>>>> contribute to Alex's (and now my) approach to getting from AS to JS,
>>>> my time is spend better helping out on another part of the project.
>>>>
>>>
>>> Saying this kindof pisses me off. I just spent the last week writing a
>>> compiler that will allow us to do any type of cross compile we want.
>>>
>>> Dude, you gotta stick to your guns man! If what you decided on for the
>>> time being is goog, the use it! Frank can have his opinion but, you are
>>> doing something and that means you need answers which you sought out.
>>>
>>> If you research me a bit, I was a component developer since 2003. To 
>>> say
>>> you will not get help with the component framework is bs. I'm right 
>>> here,
>>> really how many people does it take to make something in the world. 
>>> Right
>>> mow a bunch of people would muddle stuff up.
>>>
>>> I remember spouting the same crap back in January when I left the 
>>> project
>>> for 8 months this year. What I realized is if there was one thing I 
>>> wanted
>>> to do, it's allow AS3 to run on something other than the Flash 
>>> Player. This
>>> is my main goal, why? I have no freaking reason other than I have to 
>>> much
>>> experience in AS3 and the like to throw it away for some "new" 
>>> language,
>>> blah blah.
>>>
>>> What I am trying to do here is make the lower level. You cannot 
>>> expect a
>>> lot of people to help out here, they just don't have a clue what is 
>>> going
>>> on. Your a leader, lead my friend and keep going, I will join up 
>>> when I get
>>> the compiler working correctly in the prototype.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>
>>>  I'm not sitting here feeling sorry for myself, I actually learned a
>>>> lot setting up the current approach. I'm just wondering if it is worth
>>>> my time to pursue this avenue when everyone else seems more interested
>>>> in going in a (as far as I understand) completely different direction.
>>>> Getting this "done" is a major project which I cannot get done on my
>>>> own. So, unless there's people out there that are willing to
>>>> contribute to Alex's (and now my) approach to getting from AS to JS,
>>>> my time is spend better helping out on another part of the project.
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>> wrote:
>>>>
>>>>> So, basically, nobody loves the "goog" approach I spend the last 
>>>>> weeks
>>>>> working on (based mostly on feedback from the various discussion on
>>>>> the list).
>>>>>
>>>>> Or, let me rephrase, nobody cares enough to contribute to it?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net>
>>>>> wrote:
>>>>>
>>>>>> This is great news, Mike! I will also try to dig into your code this
>>>>>> weekend.
>>>>>> In the meantime, I've been busy figuring out the "essence" of a new
>>>>>> JavaScript runtime format that uses the principles described in 
>>>>>> my blog,
>>>>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making 
>>>>>> it way
>>>>>> more concise than the current Jangaroo Runtime. For IE8 and other
>>>>>> non-ES5
>>>>>> browsers, we would then use polyfills for all ES5 functions used.
>>>>>> Let's see if I can get an approval from my company to contribute; 
>>>>>> if it
>>>>>> takes too long, I'd blog about the concepts and you or someone else
>>>>>> would
>>>>>> have to implement them.
>>>>>> Greetings
>>>>>> -Frank-
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>>>>> <ap...@teotigraphix.com>**wrote:
>>>>>>
>>>>>>  Not really,
>>>>>>>
>>>>>>> I rebuilt everything from scratch. Yes I copied about half the 
>>>>>>> code in
>>>>>>> pieces. I purposely put it all back together myself so I knew 
>>>>>>> what was
>>>>>>> going on. So every class in the committed code was assembled by 
>>>>>>> me, to
>>>>>>> figure out it's function if relevant to the new design.
>>>>>>>
>>>>>>> Besides most of it had either be deleted of changed because I am 
>>>>>>> not
>>>>>>> targeting SWF what so ever.
>>>>>>>
>>>>>>> I tried to stick with the same base implementation so we kept the
>>>>>>> multi-threaded Falcon parsing.
>>>>>>>
>>>>>>> Take a look at the org.apache.flex.compiler.****internal.js.codegen
>>>>>>> package.
>>>>>>>
>>>>>>> Specifically ASBlockWalker from that class alone you should see 
>>>>>>> that
>>>>>>> this
>>>>>>> is a completely different implementation.
>>>>>>>
>>>>>>> A note to others looking at the code, in the ASBlockWalker I 
>>>>>>> have mixed
>>>>>>> some javascript emitting specific to the closure compiler. I 
>>>>>>> want to
>>>>>>> change
>>>>>>> this and have a base class not dependent on anything but to be 
>>>>>>> able to
>>>>>>> override it.
>>>>>>>
>>>>>>> Case in point, most expressions and statements map the same in 
>>>>>>> AS to
>>>>>>> JS,
>>>>>>> so having a base implementation not tied to anything will be a 
>>>>>>> positive
>>>>>>> thing. I also don't like mixing design specific things in the base
>>>>>>> traversing class, another reason why I want an abstract base or 
>>>>>>> two.
>>>>>>>
>>>>>>> Anyway, very prototype code and I reserve the right to yank things
>>>>>>> around.
>>>>>>> :) I just wanted to get it up to show others there might be an 
>>>>>>> easier
>>>>>>> and
>>>>>>> more flexible way to get to where we need to go without the BURM.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>>>
>>>>>>>  I will try to look this weekend.
>>>>>>>
>>>>>>>>
>>>>>>>> Can you briefly describe the important files to look at?  Did you
>>>>>>>> copy the
>>>>>>>> FalconJS files then do most of your work in a few of them?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>  Hi,
>>>>>>>>>
>>>>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>>>>> something we all could start talking about.
>>>>>>>>>
>>>>>>>>> Is it viable?, I really think so. I have spent a lot of time
>>>>>>>>> tinkering
>>>>>>>>> with the framework, take a look. It's in my whiteboard for now 
>>>>>>>>> under
>>>>>>>>> 2
>>>>>>>>> Eclipse projects.
>>>>>>>>>
>>>>>>>>> I know there was just a discussion about .project files but I
>>>>>>>>> committed the .project and .classpath for both application and 
>>>>>>>>> test
>>>>>>>>> project, just like the rest of Falcon.
>>>>>>>>>
>>>>>>>>> I'm working on more documentation. A thing to note about the 
>>>>>>>>> code, my
>>>>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>>>>> later but, since I'm the one putting this together, that is 
>>>>>>>>> what I
>>>>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>>>>> generating, we start overriding things for JavaScript specific
>>>>>>>>> implementations.
>>>>>>>>>
>>>>>>>>> Source [0]
>>>>>>>>>
>>>>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>>>>> statements. Its a good start.
>>>>>>>>>
>>>>>>>>> Note; I have not don't a build file, if anybody wants to go 
>>>>>>>>> for it.
>>>>>>>>> Please, I hate them. :)
>>>>>>>>>
>>>>>>>>> Peace,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> - [0] https://svn.apache.org/repos/****asf/incubator/flex/**
>>>>>>>>> whiteboard/**<https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**> 
>>>>>>>>>
>>>>>>>>> mschmalle/<https://svn.apache.**org/repos/asf/incubator/flex/**
>>>>>>>>> whiteboard/mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/> 
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>>
>>>>
>>> -- 
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>>
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Hey,

This is great to hear. I'm kind of a hard head myself. What we are  
doing is going against what the majority says is possible.

I see petitions to kill the Flash Player, uninstall it from your  
browser stuff... You get where I am going with this?

Ignorant developers associate ActionScript3 with the Flash Player and  
not with a very mature OOP language. With the new Falcon compiler we  
have a very powerful tool to transform ActionScript into something it  
has never been before, Flash Player independent. This is my vision.

It just so happens that ActionScript and JavaScript share a lot of the  
same semantics on the AST level so we have a natural fit.

Erik, we need people to bridge the language gap between AS and JS. You  
are acting as the translator right now. I know you are not going to  
get every translation correct in the start, but you need to realize  
this is going to take a few running starts to jump the divide!

To others, I am pretty satisfied with my prototype being a viable  
solution to cross compile. That being said, I HAVE NO plans to work on  
the older FalconJS code, its just to much of a rats nest and Adobe  
left a 1/3 of code in there that has no relevance to our project.

So in my pessimistic voice, if I can't get this prototype to  
eventually spit out what we need, that will be it for me. :) But, 103  
granular unit tests prove I am on my way to succeeding with this design.

Mike


Quoting Chema Balsas <jb...@gmail.com>:

> Hi Erik, I'm with Mike on this one. Lead and others will follow.
>
> I for one plan to stick around the compiler and mostly the JS generation.
> I've still to find the time to dive deep into your approach, but I'll be
> working on it for sure. You can definitely count me in.
>
> Cheers,
> Chema
>
> 2012/12/14 Michael Schmalle <ap...@teotigraphix.com>
>
>> Erik,
>>
>>
>>  So, unless there's people out there that are willing to
>>> contribute to Alex's (and now my) approach to getting from AS to JS,
>>> my time is spend better helping out on another part of the project.
>>>
>>
>> Saying this kindof pisses me off. I just spent the last week writing a
>> compiler that will allow us to do any type of cross compile we want.
>>
>> Dude, you gotta stick to your guns man! If what you decided on for the
>> time being is goog, the use it! Frank can have his opinion but, you are
>> doing something and that means you need answers which you sought out.
>>
>> If you research me a bit, I was a component developer since 2003. To say
>> you will not get help with the component framework is bs. I'm right here,
>> really how many people does it take to make something in the world. Right
>> mow a bunch of people would muddle stuff up.
>>
>> I remember spouting the same crap back in January when I left the project
>> for 8 months this year. What I realized is if there was one thing I wanted
>> to do, it's allow AS3 to run on something other than the Flash Player. This
>> is my main goal, why? I have no freaking reason other than I have to much
>> experience in AS3 and the like to throw it away for some "new" language,
>> blah blah.
>>
>> What I am trying to do here is make the lower level. You cannot expect a
>> lot of people to help out here, they just don't have a clue what is going
>> on. Your a leader, lead my friend and keep going, I will join up when I get
>> the compiler working correctly in the prototype.
>>
>> Mike
>>
>>
>>
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>  I'm not sitting here feeling sorry for myself, I actually learned a
>>> lot setting up the current approach. I'm just wondering if it is worth
>>> my time to pursue this avenue when everyone else seems more interested
>>> in going in a (as far as I understand) completely different direction.
>>> Getting this "done" is a major project which I cannot get done on my
>>> own. So, unless there's people out there that are willing to
>>> contribute to Alex's (and now my) approach to getting from AS to JS,
>>> my time is spend better helping out on another part of the project.
>>>
>>> EdB
>>>
>>>
>>>
>>> On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl>
>>> wrote:
>>>
>>>> So, basically, nobody loves the "goog" approach I spend the last weeks
>>>> working on (based mostly on feedback from the various discussion on
>>>> the list).
>>>>
>>>> Or, let me rephrase, nobody cares enough to contribute to it?
>>>>
>>>> EdB
>>>>
>>>>
>>>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net>
>>>> wrote:
>>>>
>>>>> This is great news, Mike! I will also try to dig into your code this
>>>>> weekend.
>>>>> In the meantime, I've been busy figuring out the "essence" of a new
>>>>> JavaScript runtime format that uses the principles described in my blog,
>>>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>>>>> more concise than the current Jangaroo Runtime. For IE8 and other
>>>>> non-ES5
>>>>> browsers, we would then use polyfills for all ES5 functions used.
>>>>> Let's see if I can get an approval from my company to contribute; if it
>>>>> takes too long, I'd blog about the concepts and you or someone else
>>>>> would
>>>>> have to implement them.
>>>>> Greetings
>>>>> -Frank-
>>>>>
>>>>>
>>>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>>>> <ap...@teotigraphix.com>**wrote:
>>>>>
>>>>>  Not really,
>>>>>>
>>>>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>>>>> pieces. I purposely put it all back together myself so I knew what was
>>>>>> going on. So every class in the committed code was assembled by me, to
>>>>>> figure out it's function if relevant to the new design.
>>>>>>
>>>>>> Besides most of it had either be deleted of changed because I am not
>>>>>> targeting SWF what so ever.
>>>>>>
>>>>>> I tried to stick with the same base implementation so we kept the
>>>>>> multi-threaded Falcon parsing.
>>>>>>
>>>>>> Take a look at the org.apache.flex.compiler.****internal.js.codegen
>>>>>> package.
>>>>>>
>>>>>> Specifically ASBlockWalker from that class alone you should see that
>>>>>> this
>>>>>> is a completely different implementation.
>>>>>>
>>>>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>>>>> some javascript emitting specific to the closure compiler. I want to
>>>>>> change
>>>>>> this and have a base class not dependent on anything but to be able to
>>>>>> override it.
>>>>>>
>>>>>> Case in point, most expressions and statements map the same in AS to
>>>>>> JS,
>>>>>> so having a base implementation not tied to anything will be a positive
>>>>>> thing. I also don't like mixing design specific things in the base
>>>>>> traversing class, another reason why I want an abstract base or two.
>>>>>>
>>>>>> Anyway, very prototype code and I reserve the right to yank things
>>>>>> around.
>>>>>> :) I just wanted to get it up to show others there might be an easier
>>>>>> and
>>>>>> more flexible way to get to where we need to go without the BURM.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>>
>>>>>>  I will try to look this weekend.
>>>>>>
>>>>>>>
>>>>>>> Can you briefly describe the important files to look at?  Did you
>>>>>>> copy the
>>>>>>> FalconJS files then do most of your work in a few of them?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Alex
>>>>>>>
>>>>>>>
>>>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>  Hi,
>>>>>>>>
>>>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>>>> something we all could start talking about.
>>>>>>>>
>>>>>>>> Is it viable?, I really think so. I have spent a lot of time
>>>>>>>> tinkering
>>>>>>>> with the framework, take a look. It's in my whiteboard for now under
>>>>>>>> 2
>>>>>>>> Eclipse projects.
>>>>>>>>
>>>>>>>> I know there was just a discussion about .project files but I
>>>>>>>> committed the .project and .classpath for both application and test
>>>>>>>> project, just like the rest of Falcon.
>>>>>>>>
>>>>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>>>> later but, since I'm the one putting this together, that is what I
>>>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>>>> generating, we start overriding things for JavaScript specific
>>>>>>>> implementations.
>>>>>>>>
>>>>>>>> Source [0]
>>>>>>>>
>>>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>>>> statements. Its a good start.
>>>>>>>>
>>>>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>>>>> Please, I hate them. :)
>>>>>>>>
>>>>>>>> Peace,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> - [0] https://svn.apache.org/repos/****asf/incubator/flex/**
>>>>>>>> whiteboard/**<https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**>
>>>>>>>> mschmalle/<https://svn.apache.**org/repos/asf/incubator/flex/**
>>>>>>>> whiteboard/mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Chema Balsas <jb...@gmail.com>]

Hi Erik, I'm with Mike on this one. Lead and others will follow.

I for one plan to stick around the compiler and mostly the JS generation.
I've still to find the time to dive deep into your approach, but I'll be
working on it for sure. You can definitely count me in.

Cheers,
Chema

2012/12/14 Michael Schmalle <ap...@teotigraphix.com>

> Erik,
>
>
>  So, unless there's people out there that are willing to
>> contribute to Alex's (and now my) approach to getting from AS to JS,
>> my time is spend better helping out on another part of the project.
>>
>
> Saying this kindof pisses me off. I just spent the last week writing a
> compiler that will allow us to do any type of cross compile we want.
>
> Dude, you gotta stick to your guns man! If what you decided on for the
> time being is goog, the use it! Frank can have his opinion but, you are
> doing something and that means you need answers which you sought out.
>
> If you research me a bit, I was a component developer since 2003. To say
> you will not get help with the component framework is bs. I'm right here,
> really how many people does it take to make something in the world. Right
> mow a bunch of people would muddle stuff up.
>
> I remember spouting the same crap back in January when I left the project
> for 8 months this year. What I realized is if there was one thing I wanted
> to do, it's allow AS3 to run on something other than the Flash Player. This
> is my main goal, why? I have no freaking reason other than I have to much
> experience in AS3 and the like to throw it away for some "new" language,
> blah blah.
>
> What I am trying to do here is make the lower level. You cannot expect a
> lot of people to help out here, they just don't have a clue what is going
> on. Your a leader, lead my friend and keep going, I will join up when I get
> the compiler working correctly in the prototype.
>
> Mike
>
>
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>  I'm not sitting here feeling sorry for myself, I actually learned a
>> lot setting up the current approach. I'm just wondering if it is worth
>> my time to pursue this avenue when everyone else seems more interested
>> in going in a (as far as I understand) completely different direction.
>> Getting this "done" is a major project which I cannot get done on my
>> own. So, unless there's people out there that are willing to
>> contribute to Alex's (and now my) approach to getting from AS to JS,
>> my time is spend better helping out on another part of the project.
>>
>> EdB
>>
>>
>>
>> On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl>
>> wrote:
>>
>>> So, basically, nobody loves the "goog" approach I spend the last weeks
>>> working on (based mostly on feedback from the various discussion on
>>> the list).
>>>
>>> Or, let me rephrase, nobody cares enough to contribute to it?
>>>
>>> EdB
>>>
>>>
>>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net>
>>> wrote:
>>>
>>>> This is great news, Mike! I will also try to dig into your code this
>>>> weekend.
>>>> In the meantime, I've been busy figuring out the "essence" of a new
>>>> JavaScript runtime format that uses the principles described in my blog,
>>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>>>> more concise than the current Jangaroo Runtime. For IE8 and other
>>>> non-ES5
>>>> browsers, we would then use polyfills for all ES5 functions used.
>>>> Let's see if I can get an approval from my company to contribute; if it
>>>> takes too long, I'd blog about the concepts and you or someone else
>>>> would
>>>> have to implement them.
>>>> Greetings
>>>> -Frank-
>>>>
>>>>
>>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>>> <ap...@teotigraphix.com>**wrote:
>>>>
>>>>  Not really,
>>>>>
>>>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>>>> pieces. I purposely put it all back together myself so I knew what was
>>>>> going on. So every class in the committed code was assembled by me, to
>>>>> figure out it's function if relevant to the new design.
>>>>>
>>>>> Besides most of it had either be deleted of changed because I am not
>>>>> targeting SWF what so ever.
>>>>>
>>>>> I tried to stick with the same base implementation so we kept the
>>>>> multi-threaded Falcon parsing.
>>>>>
>>>>> Take a look at the org.apache.flex.compiler.****internal.js.codegen
>>>>> package.
>>>>>
>>>>> Specifically ASBlockWalker from that class alone you should see that
>>>>> this
>>>>> is a completely different implementation.
>>>>>
>>>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>>>> some javascript emitting specific to the closure compiler. I want to
>>>>> change
>>>>> this and have a base class not dependent on anything but to be able to
>>>>> override it.
>>>>>
>>>>> Case in point, most expressions and statements map the same in AS to
>>>>> JS,
>>>>> so having a base implementation not tied to anything will be a positive
>>>>> thing. I also don't like mixing design specific things in the base
>>>>> traversing class, another reason why I want an abstract base or two.
>>>>>
>>>>> Anyway, very prototype code and I reserve the right to yank things
>>>>> around.
>>>>> :) I just wanted to get it up to show others there might be an easier
>>>>> and
>>>>> more flexible way to get to where we need to go without the BURM.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>
>>>>>  I will try to look this weekend.
>>>>>
>>>>>>
>>>>>> Can you briefly describe the important files to look at?  Did you
>>>>>> copy the
>>>>>> FalconJS files then do most of your work in a few of them?
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>>>>>>
>>>>>>
>>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>  Hi,
>>>>>>>
>>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>>> something we all could start talking about.
>>>>>>>
>>>>>>> Is it viable?, I really think so. I have spent a lot of time
>>>>>>> tinkering
>>>>>>> with the framework, take a look. It's in my whiteboard for now under
>>>>>>> 2
>>>>>>> Eclipse projects.
>>>>>>>
>>>>>>> I know there was just a discussion about .project files but I
>>>>>>> committed the .project and .classpath for both application and test
>>>>>>> project, just like the rest of Falcon.
>>>>>>>
>>>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>>> later but, since I'm the one putting this together, that is what I
>>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>>> generating, we start overriding things for JavaScript specific
>>>>>>> implementations.
>>>>>>>
>>>>>>> Source [0]
>>>>>>>
>>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>>> statements. Its a good start.
>>>>>>>
>>>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>>>> Please, I hate them. :)
>>>>>>>
>>>>>>> Peace,
>>>>>>> Mike
>>>>>>>
>>>>>>> - [0] https://svn.apache.org/repos/****asf/incubator/flex/**
>>>>>>> whiteboard/**<https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**>
>>>>>>> mschmalle/<https://svn.apache.**org/repos/asf/incubator/flex/**
>>>>>>> whiteboard/mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Erik,

> So, unless there's people out there that are willing to
> contribute to Alex's (and now my) approach to getting from AS to JS,
> my time is spend better helping out on another part of the project.

Saying this kindof pisses me off. I just spent the last week writing a  
compiler that will allow us to do any type of cross compile we want.

Dude, you gotta stick to your guns man! If what you decided on for the  
time being is goog, the use it! Frank can have his opinion but, you  
are doing something and that means you need answers which you sought  
out.

If you research me a bit, I was a component developer since 2003. To  
say you will not get help with the component framework is bs. I'm  
right here, really how many people does it take to make something in  
the world. Right mow a bunch of people would muddle stuff up.

I remember spouting the same crap back in January when I left the  
project for 8 months this year. What I realized is if there was one  
thing I wanted to do, it's allow AS3 to run on something other than  
the Flash Player. This is my main goal, why? I have no freaking reason  
other than I have to much experience in AS3 and the like to throw it  
away for some "new" language, blah blah.

What I am trying to do here is make the lower level. You cannot expect  
a lot of people to help out here, they just don't have a clue what is  
going on. Your a leader, lead my friend and keep going, I will join up  
when I get the compiler working correctly in the prototype.

Mike



Quoting Erik de Bruin <er...@ixsoftware.nl>:

> I'm not sitting here feeling sorry for myself, I actually learned a
> lot setting up the current approach. I'm just wondering if it is worth
> my time to pursue this avenue when everyone else seems more interested
> in going in a (as far as I understand) completely different direction.
> Getting this "done" is a major project which I cannot get done on my
> own. So, unless there's people out there that are willing to
> contribute to Alex's (and now my) approach to getting from AS to JS,
> my time is spend better helping out on another part of the project.
>
> EdB
>
>
>
> On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> So, basically, nobody loves the "goog" approach I spend the last weeks
>> working on (based mostly on feedback from the various discussion on
>> the list).
>>
>> Or, let me rephrase, nobody cares enough to contribute to it?
>>
>> EdB
>>
>>
>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
>>> This is great news, Mike! I will also try to dig into your code this
>>> weekend.
>>> In the meantime, I've been busy figuring out the "essence" of a new
>>> JavaScript runtime format that uses the principles described in my blog,
>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>>> more concise than the current Jangaroo Runtime. For IE8 and other non-ES5
>>> browsers, we would then use polyfills for all ES5 functions used.
>>> Let's see if I can get an approval from my company to contribute; if it
>>> takes too long, I'd blog about the concepts and you or someone else would
>>> have to implement them.
>>> Greetings
>>> -Frank-
>>>
>>>
>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>> <ap...@teotigraphix.com>wrote:
>>>
>>>> Not really,
>>>>
>>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>>> pieces. I purposely put it all back together myself so I knew what was
>>>> going on. So every class in the committed code was assembled by me, to
>>>> figure out it's function if relevant to the new design.
>>>>
>>>> Besides most of it had either be deleted of changed because I am not
>>>> targeting SWF what so ever.
>>>>
>>>> I tried to stick with the same base implementation so we kept the
>>>> multi-threaded Falcon parsing.
>>>>
>>>> Take a look at the org.apache.flex.compiler.**internal.js.codegen package.
>>>>
>>>> Specifically ASBlockWalker from that class alone you should see that this
>>>> is a completely different implementation.
>>>>
>>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>>> some javascript emitting specific to the closure compiler. I want  
>>>> to change
>>>> this and have a base class not dependent on anything but to be able to
>>>> override it.
>>>>
>>>> Case in point, most expressions and statements map the same in AS to JS,
>>>> so having a base implementation not tied to anything will be a positive
>>>> thing. I also don't like mixing design specific things in the base
>>>> traversing class, another reason why I want an abstract base or two.
>>>>
>>>> Anyway, very prototype code and I reserve the right to yank things around.
>>>> :) I just wanted to get it up to show others there might be an easier and
>>>> more flexible way to get to where we need to go without the BURM.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>
>>>>  I will try to look this weekend.
>>>>>
>>>>> Can you briefly describe the important files to look at?  Did  
>>>>> you copy the
>>>>> FalconJS files then do most of your work in a few of them?
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>>
>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>> something we all could start talking about.
>>>>>>
>>>>>> Is it viable?, I really think so. I have spent a lot of time tinkering
>>>>>> with the framework, take a look. It's in my whiteboard for now under 2
>>>>>> Eclipse projects.
>>>>>>
>>>>>> I know there was just a discussion about .project files but I
>>>>>> committed the .project and .classpath for both application and test
>>>>>> project, just like the rest of Falcon.
>>>>>>
>>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>> later but, since I'm the one putting this together, that is what I
>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>> generating, we start overriding things for JavaScript specific
>>>>>> implementations.
>>>>>>
>>>>>> Source [0]
>>>>>>
>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>> statements. Its a good start.
>>>>>>
>>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>>> Please, I hate them. :)
>>>>>>
>>>>>> Peace,
>>>>>> Mike
>>>>>>
>>>>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>>>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Erik de Bruin <er...@ixsoftware.nl>]

I'm not sitting here feeling sorry for myself, I actually learned a
lot setting up the current approach. I'm just wondering if it is worth
my time to pursue this avenue when everyone else seems more interested
in going in a (as far as I understand) completely different direction.
Getting this "done" is a major project which I cannot get done on my
own. So, unless there's people out there that are willing to
contribute to Alex's (and now my) approach to getting from AS to JS,
my time is spend better helping out on another part of the project.

EdB



On Fri, Dec 14, 2012 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> So, basically, nobody loves the "goog" approach I spend the last weeks
> working on (based mostly on feedback from the various discussion on
> the list).
>
> Or, let me rephrase, nobody cares enough to contribute to it?
>
> EdB
>
>
> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
>> This is great news, Mike! I will also try to dig into your code this
>> weekend.
>> In the meantime, I've been busy figuring out the "essence" of a new
>> JavaScript runtime format that uses the principles described in my blog,
>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>> more concise than the current Jangaroo Runtime. For IE8 and other non-ES5
>> browsers, we would then use polyfills for all ES5 functions used.
>> Let's see if I can get an approval from my company to contribute; if it
>> takes too long, I'd blog about the concepts and you or someone else would
>> have to implement them.
>> Greetings
>> -Frank-
>>
>>
>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>> <ap...@teotigraphix.com>wrote:
>>
>>> Not really,
>>>
>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>> pieces. I purposely put it all back together myself so I knew what was
>>> going on. So every class in the committed code was assembled by me, to
>>> figure out it's function if relevant to the new design.
>>>
>>> Besides most of it had either be deleted of changed because I am not
>>> targeting SWF what so ever.
>>>
>>> I tried to stick with the same base implementation so we kept the
>>> multi-threaded Falcon parsing.
>>>
>>> Take a look at the org.apache.flex.compiler.**internal.js.codegen package.
>>>
>>> Specifically ASBlockWalker from that class alone you should see that this
>>> is a completely different implementation.
>>>
>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>> some javascript emitting specific to the closure compiler. I want to change
>>> this and have a base class not dependent on anything but to be able to
>>> override it.
>>>
>>> Case in point, most expressions and statements map the same in AS to JS,
>>> so having a base implementation not tied to anything will be a positive
>>> thing. I also don't like mixing design specific things in the base
>>> traversing class, another reason why I want an abstract base or two.
>>>
>>> Anyway, very prototype code and I reserve the right to yank things around.
>>> :) I just wanted to get it up to show others there might be an easier and
>>> more flexible way to get to where we need to go without the BURM.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>> Quoting Alex Harui <ah...@adobe.com>:
>>>
>>>  I will try to look this weekend.
>>>>
>>>> Can you briefly describe the important files to look at?  Did you copy the
>>>> FalconJS files then do most of your work in a few of them?
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Well, I spent the last 4 days working on this to where it was
>>>>> something we all could start talking about.
>>>>>
>>>>> Is it viable?, I really think so. I have spent a lot of time tinkering
>>>>> with the framework, take a look. It's in my whiteboard for now under 2
>>>>> Eclipse projects.
>>>>>
>>>>> I know there was just a discussion about .project files but I
>>>>> committed the .project and .classpath for both application and test
>>>>> project, just like the rest of Falcon.
>>>>>
>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>> later but, since I'm the one putting this together, that is what I
>>>>> decided was best for testing first. Once we get all ActionScript
>>>>> generating, we start overriding things for JavaScript specific
>>>>> implementations.
>>>>>
>>>>> Source [0]
>>>>>
>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>> statements. Its a good start.
>>>>>
>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>> Please, I hate them. :)
>>>>>
>>>>> Peace,
>>>>> Mike
>>>>>
>>>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>
>>>>
>>>> --
>>>> 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
>>>
>>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Daniel Wasilewski <de...@gmail.com>:

> On 12/14/2012 11:49 AM, Michael Schmalle wrote:
>>
>> Isn't it the end of 2012 right now? ;-)
>>
>> Mike
>
> Nope, we have to survive end of the world first, then end of the  
> world sales and then... :D
>

Right, and the millions of other planets in the hundreds of galaxys we  
can see must meet their demise in the same fashion... on the news and  
twitter (oh I can't stand superficial hype).

It's a wonder how this machine keeps turning sometimes when the  
Universe could just as easily put a comment right through the middle  
of our little planet.

Mike

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

On 12/14/2012 11:49 AM, Michael Schmalle wrote:
>
> Isn't it the end of 2012 right now? ;-)
>
> Mike

Nope, we have to survive end of the world first, then end of the world 
sales and then... :D

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

Well, that's good news then :)

On 12/14/2012 12:30 PM, Erik de Bruin wrote:
>>> 'goog' seems to be the reasonable way to go. I would be a bit concern
>>> about name-space implementation yet.
>>> org.apache.data.blah.foo is the major bottleneck. And currently not that
>>> different from haxe approach. Even after closure compiler heavy lifting it
>>> is still
>>> a.b.c.d.e.f. It starts with "org.apache.data.blah.foo" as a string , so
>>> why not ns_orgApacheDataBlahFoo that will get complied to 'abcdef' ? Just an
>>> idea.
> Stop worrying: the Closure Compiler (which the "goog" approach uses)
> is specifically designed to handle stuff like those "deep" namespaces.
> It checks dependencies, so it knows what it can and cannot rename, and
> it checks for collisions when doing the renaming. The result of all
> this is that you can during development use namespaces however deep
> you like - "this.is.a.really.deep.namespace.dont.you.think - but if
> the Closure Compiler figures it can get away with it, it will
> ruthlessly refactor that to: "a".
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Right,

 From my experience with compilers, I guessed that is what Google did.  
And it turns out that is what they did.

So keep on your course Erik, nothing to worry about. Let's just get  
this thing rolling so #ApacheFlex #FalconJx tags are swimming in the  
Twitter atmosphere. ;-)

I'm not that arrogant, just know that unit tests prove software and  
also why I waited to commit code that had them, proving what we  
already know, this is a doable project.

Mike

Quoting Erik de Bruin <er...@ixsoftware.nl>:

>> Ok, then not to worry, we can even tests this sooner than later to see
>> exactly what the closure compiler does with our namespaces.
>
> Taking the example AS -> JS we worked with last week, let me show you:
>
> //============================**==============================**=======
>
> AS CODE
>
>
> package com.example.components
> {
>
> import flash.display.Sprite;
>
> public class MyTextButton extends Sprite
> {
>     public function MyTextButton()
>
>     {
>         super();
>      }
>
>     private var _privateVar:String = "do ";
>
>     public var publicProperty:Number = 100;
>
>     public function myFunction(value: String): String
>     {
>         return "Don't " + _privateVar + value;
>     }
> }
> }
>
>
>
> //============================**==============================**=======
>
> JS CODE (intended, maybe even current, output of FalconJx)
>
> /**
>  * CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-12-07 08:11:27
>  */
>
> goog.provide("com.example.components.MyTextButton");
>
> goog.require("flash.display.Sprite");
>
> /**
>  * @constructor
>  * @extends flash.display.Sprite
>  */
> com.example.components.MyTextButton = function()
> {
>     goog.base(this);
>
>     /**
>      * @private
>      * @type {string}
>      */
>      this._privateVar = "do ";
> }
> goog.inherits(com.example.components.MyTextButton, flash.display.Sprite);
>
> /**
>  * @type {number}
>  */
> com.example.components.MyTextButton.prototype.publicProperty = 100;
>
> /**
>  * @this {com.example.components.MyTextButton}
>  * @param {string} value
>  * @return {string}
>  */
> com.example.components.MyTextButton.prototype.myFunction = function(value)
> {
>     return (("Don't " + this._privateVar) + value);
> }
>
> // Ensures the symbol will be visible after compiler renaming (needed
> only for "application" level class)
> goog.exportSymbol('com.example.components.MyTextButton',
> com.example.components.MyTextButton);
>
>
>
> //============================**==============================**=======
>
> JS CODE (run through the Closure Builder)
>
> function a(){this.a="do "}function b(){}function
> c(){}c.prototype=b.prototype;a.b=b.prototype;a.prototype=new c;var
> d=["com","example","components","MyTextButton"],e=this;!(d[0]in
> e)&&e.execScript&&e.execScript("var "+d[0]);for(var
> f;d.length&&(f=d.shift());)!d.length&&void
> 0!==a?e[f]=a:e=e[f]?e[f]:e[f]={};
>
>
>
> Now, although we use stuff from the "goog" library ('provides',
> 'requires', 'base' and 'inherits'), the Closure Builder output is ALL
> THAT'S NEEDED for our JS to run in the browser. This means that all
> dependencies have been resolved and the code is compiled such that
> doesn't need the "goog" library to run... Pretty efficient and highly
> optimised, I'd say ;-)
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Erik de Bruin <er...@ixsoftware.nl>]

> Ok, then not to worry, we can even tests this sooner than later to see
> exactly what the closure compiler does with our namespaces.

Taking the example AS -> JS we worked with last week, let me show you:

//============================**==============================**=======

AS CODE


package com.example.components
{

import flash.display.Sprite;

public class MyTextButton extends Sprite
{
    public function MyTextButton()

    {
        super();
     }

    private var _privateVar:String = "do ";

    public var publicProperty:Number = 100;

    public function myFunction(value: String): String
    {
        return "Don't " + _privateVar + value;
    }
}
}



//============================**==============================**=======

JS CODE (intended, maybe even current, output of FalconJx)

/**
 * CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-12-07 08:11:27
 */

goog.provide("com.example.components.MyTextButton");

goog.require("flash.display.Sprite");

/**
 * @constructor
 * @extends flash.display.Sprite
 */
com.example.components.MyTextButton = function()
{
    goog.base(this);

    /**
     * @private
     * @type {string}
     */
     this._privateVar = "do ";
}
goog.inherits(com.example.components.MyTextButton, flash.display.Sprite);

/**
 * @type {number}
 */
com.example.components.MyTextButton.prototype.publicProperty = 100;

/**
 * @this {com.example.components.MyTextButton}
 * @param {string} value
 * @return {string}
 */
com.example.components.MyTextButton.prototype.myFunction = function(value)
{
    return (("Don't " + this._privateVar) + value);
}

// Ensures the symbol will be visible after compiler renaming (needed
only for "application" level class)
goog.exportSymbol('com.example.components.MyTextButton',
com.example.components.MyTextButton);



//============================**==============================**=======

JS CODE (run through the Closure Builder)

function a(){this.a="do "}function b(){}function
c(){}c.prototype=b.prototype;a.b=b.prototype;a.prototype=new c;var
d=["com","example","components","MyTextButton"],e=this;!(d[0]in
e)&&e.execScript&&e.execScript("var "+d[0]);for(var
f;d.length&&(f=d.shift());)!d.length&&void
0!==a?e[f]=a:e=e[f]?e[f]:e[f]={};



Now, although we use stuff from the "goog" library ('provides',
'requires', 'base' and 'inherits'), the Closure Builder output is ALL
THAT'S NEEDED for our JS to run in the browser. This means that all
dependencies have been resolved and the code is compiled such that
doesn't need the "goog" library to run... Pretty efficient and highly
optimised, I'd say ;-)

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

So then logic says that if all of our stuff is in org.apache.flex,  
that will always be reduced, at least from my compiler experience that  
is how I would do it.

Ok, then not to worry, we can even tests this sooner than later to see  
exactly what the closure compiler does with our namespaces.

Mike

Quoting Erik de Bruin <er...@ixsoftware.nl>:

>>> 'goog' seems to be the reasonable way to go. I would be a bit concern
>>> about name-space implementation yet.
>>> org.apache.data.blah.foo is the major bottleneck. And currently not that
>>> different from haxe approach. Even after closure compiler heavy lifting it
>>> is still
>>> a.b.c.d.e.f. It starts with "org.apache.data.blah.foo" as a string , so
>>> why not ns_orgApacheDataBlahFoo that will get complied to 'abcdef'  
>>> ? Just an
>>> idea.
>
> Stop worrying: the Closure Compiler (which the "goog" approach uses)
> is specifically designed to handle stuff like those "deep" namespaces.
> It checks dependencies, so it knows what it can and cannot rename, and
> it checks for collisions when doing the renaming. The result of all
> this is that you can during development use namespaces however deep
> you like - "this.is.a.really.deep.namespace.dont.you.think - but if
> the Closure Compiler figures it can get away with it, it will
> ruthlessly refactor that to: "a".
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Erik de Bruin <er...@ixsoftware.nl>]

>> 'goog' seems to be the reasonable way to go. I would be a bit concern
>> about name-space implementation yet.
>> org.apache.data.blah.foo is the major bottleneck. And currently not that
>> different from haxe approach. Even after closure compiler heavy lifting it
>> is still
>> a.b.c.d.e.f. It starts with "org.apache.data.blah.foo" as a string , so
>> why not ns_orgApacheDataBlahFoo that will get complied to 'abcdef' ? Just an
>> idea.

Stop worrying: the Closure Compiler (which the "goog" approach uses)
is specifically designed to handle stuff like those "deep" namespaces.
It checks dependencies, so it knows what it can and cannot rename, and
it checks for collisions when doing the renaming. The result of all
this is that you can during development use namespaces however deep
you like - "this.is.a.really.deep.namespace.dont.you.think - but if
the Closure Compiler figures it can get away with it, it will
ruthlessly refactor that to: "a".

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

I don't know why I didn't show you this before.
I have done some tests AS3 vs JS a while ago. Pretty much on the 
beginning of my journey with JS when started to investigate possibility 
of moving towards html5.

http://www.flaemo.com/bixbite/

you can also review about 86 different specs collected up there

http://flaemo.com/bixbite/gettable.php?id=*86*

Just change the id to review them all.

When comes to speed of execution of generic parts, raw loop iterations, 
object creations etc, Flash is no longer a king on desktop.
But still better in some crucial elements. Take a look at Object vs 
Class creation and speed of accessibility.
The only thing that Flash is 10x faster with, is the very last part of 
the test. Display List vs DOM. However is not true for Canvas or even 
svg could get closer if not better.

Number of iteration is quite small up there to see differences between 
Scope Object 2 and 3 lvl because this test has been tweaked to run on 
Android devices as well.
But it will give some picture of where we are.

Dan


On 12/14/2012 11:49 AM, Michael Schmalle wrote:
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> Well, thanks for clarification.
>>
>> And I love you keep AST abstract as it should be :)
>> Imagine in the future JS 2.0 will came out...
>
> Well any good design is not dependent on it's output. This design is 
> no different, the only thing it's dependent on is it's AST structure. ;-)
>
>> 'goog' seems to be the reasonable way to go. I would be a bit concern 
>> about name-space implementation yet.
>> org.apache.data.blah.foo is the major bottleneck. And currently not 
>> that different from haxe approach. Even after closure compiler heavy 
>> lifting it is still
>> a.b.c.d.e.f. It starts with "org.apache.data.blah.foo" as a string , 
>> so why not ns_orgApacheDataBlahFoo that will get complied to 'abcdef' 
>> ? Just an idea.
>
> You know, a week or two ago when this was brought up, I was going to 
> suggest doing the same thing?
>
> Why don't people do it in other frameworks? If it's a performance 
> issue to use nested object prototypes than;
>
> org_apache_flex_foo.MyClass.prototype should never get collisions. I 
> don't know enough JavaScript theory to be useful though. :)
>
>
>>>
>>> That is why I took a week of MY time to get up in svn a valid 
>>> alternate cross compiler, I want to give people hope in a new 
>>> direction so it can galvanize a new effort.
>> And I am glad people like you are here. I can step in at some point 
>> but I am ridiculously busy at the moment... and towards the end of 
>> 2012 :(
>>
>
> Isn't it the end of 2012 right now? ;-)
>
> Mike
>
>
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Daniel Wasilewski <de...@gmail.com>:

> Well, thanks for clarification.
>
> And I love you keep AST abstract as it should be :)
> Imagine in the future JS 2.0 will came out...

Well any good design is not dependent on it's output. This design is  
no different, the only thing it's dependent on is it's AST structure.  
;-)

> 'goog' seems to be the reasonable way to go. I would be a bit  
> concern about name-space implementation yet.
> org.apache.data.blah.foo is the major bottleneck. And currently not  
> that different from haxe approach. Even after closure compiler heavy  
> lifting it is still
> a.b.c.d.e.f. It starts with "org.apache.data.blah.foo" as a string ,  
> so why not ns_orgApacheDataBlahFoo that will get complied to  
> 'abcdef' ? Just an idea.

You know, a week or two ago when this was brought up, I was going to  
suggest doing the same thing?

Why don't people do it in other frameworks? If it's a performance  
issue to use nested object prototypes than;

org_apache_flex_foo.MyClass.prototype should never get collisions. I  
don't know enough JavaScript theory to be useful though. :)


>>
>> That is why I took a week of MY time to get up in svn a valid  
>> alternate cross compiler, I want to give people hope in a new  
>> direction so it can galvanize a new effort.
> And I am glad people like you are here. I can step in at some point  
> but I am ridiculously busy at the moment... and towards the end of  
> 2012 :(
>

Isn't it the end of 2012 right now? ;-)

Mike



-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

Well, thanks for clarification.

And I love you keep AST abstract as it should be :)
Imagine in the future JS 2.0 will came out...

'goog' seems to be the reasonable way to go. I would be a bit concern 
about name-space implementation yet.
org.apache.data.blah.foo is the major bottleneck. And currently not that 
different from haxe approach. Even after closure compiler heavy lifting 
it is still
a.b.c.d.e.f. It starts with "org.apache.data.blah.foo" as a string , so 
why not ns_orgApacheDataBlahFoo that will get complied to 'abcdef' ? 
Just an idea.

>
> That is why I took a week of MY time to get up in svn a valid 
> alternate cross compiler, I want to give people hope in a new 
> direction so it can galvanize a new effort.
And I am glad people like you are here. I can step in at some point but 
I am ridiculously busy at the moment... and towards the end of 2012 :(

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Harbs <ha...@gmail.com>]

That's great to hear!

I for one, am very happy to hear that you're still committed to this. The possibilities are incredible. You made some pretty strong arguments for the hybrid Randori kind of approach. Of course, the arguments are strongest when dealing with large teams so you have separate people working on the UI and business logic. I'm pretty encouraged over the prospect that there will be multiple ways of leveraging ActionScript / Flex in web applications. Having the option of choosing the Randori type of approach or cross-compiling actual components would really broaden the viability of Flex moving forward.

Things are definitely getting more and more interesting around here. :-)

Harbs

On Dec 16, 2012, at 10:31 PM, Michael A. Labriola wrote:

>> I've been following this whole discussion in the background with a lot of interest. I don't have much to contribute at this point, so I've been quiet. Mike L., I know you were somewhat disillusioned by the amount of >time it took Adobe to get Flacon/ Flacon JS contributed. Is there anything from your Randori work (very interesting by the way!) that would be useful for this project?
> 
> There is a ton. Actually, I have been watching Mike S.'s progress and am really excited by the prospects. When things are ready, I just need to make sure we have an appropriate extension hook in Falcon where we can hook the AST before code generation (that is what we are doing in Randori now for C#). Then we can port our extension to Falcon as well and Randori will work regardless of whether you are coding in C# or in AS, which was always the goal.
> 
> It's also not the I was necessarily disillusioned. Its more that, in the absence of having a compiler to work on here, I wanted to prove the concept and refine what I believe the be the right way to move forward in the browser. The C# compiler gave me a way to do that immediately and I was just more about doing than waiting. In no way have I abandoned what we are doing here. I think bug fixing and working on the existing framework is really important, but I personally don't see Flash Player as our way forward, so, for the hours I had, I felt that the best way I could help us all was to learn what it really takes to deploy an enterprise app in JS and how to get there.
> 
> Mike
> 
> 

RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

["Michael A. Labriola" <la...@digitalprimates.net>]

>I've been following this whole discussion in the background with a lot of interest. I don't have much to contribute at this point, so I've been quiet. Mike L., I know you were somewhat disillusioned by the amount of >time it took Adobe to get Flacon/ Flacon JS contributed. Is there anything from your Randori work (very interesting by the way!) that would be useful for this project?

There is a ton. Actually, I have been watching Mike S.'s progress and am really excited by the prospects. When things are ready, I just need to make sure we have an appropriate extension hook in Falcon where we can hook the AST before code generation (that is what we are doing in Randori now for C#). Then we can port our extension to Falcon as well and Randori will work regardless of whether you are coding in C# or in AS, which was always the goal.

It's also not the I was necessarily disillusioned. Its more that, in the absence of having a compiler to work on here, I wanted to prove the concept and refine what I believe the be the right way to move forward in the browser. The C# compiler gave me a way to do that immediately and I was just more about doing than waiting. In no way have I abandoned what we are doing here. I think bug fixing and working on the existing framework is really important, but I personally don't see Flash Player as our way forward, so, for the hours I had, I felt that the best way I could help us all was to learn what it really takes to deploy an enterprise app in JS and how to get there.

Mike

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Harbs <ha...@gmail.com>]

Funny: It did not click in my mind that there were two different Mikes here. In my mind Mike L. was the compiler guy from a year ago and I did not realize Mike S. was someone else. Is there somewhere that there's a list of contributors with their pictures? Faces make it much easier to remember people… ;-)

I've been following this whole discussion in the background with a lot of interest. I don't have much to contribute at this point, so I've been quiet. Mike L., I know you were somewhat disillusioned by the amount of time it took Adobe to get Flacon/ Flacon JS contributed. Is there anything from your Randori work (very interesting by the way!) that would be useful for this project?

Harbs

On Dec 14, 2012, at 7:37 PM, Michael A. Labriola wrote:

>> Eriks point I think was he is trying to write some of the js side that isn't for the time being going to be cross compiled. But as I see it, I don't think there will be a reason to hand write a lot >because we could even create a custom emitter that knows how to spit out our core js framework. Which then could be just one more abstraction layer.
> 
> In my work on Randori, I only found 2 places I absolutely needed to hand code pieces. The rough equivalent of a constructor apply and the work to do think like global eval, and really that was just non-sense around the differences in how browsers treat things.
> 
> Mike
> 

RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

["Michael A. Labriola" <la...@digitalprimates.net>]

>Eriks point I think was he is trying to write some of the js side that isn't for the time being going to be cross compiled. But as I see it, I don't think there will be a reason to hand write a lot >because we could even create a custom emitter that knows how to spit out our core js framework. Which then could be just one more abstraction layer.

In my work on Randori, I only found 2 places I absolutely needed to hand code pieces. The rough equivalent of a constructor apply and the work to do think like global eval, and really that was just non-sense around the differences in how browsers treat things.

Mike

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Well exclamation points aside, I think my base concept is I just  
wanted to get a compiler ready to output whatever mashup we prescribe.

I understand fully what you are saying, the end product is javascript  
and how we get there is all implementation details that for me as it  
stands are not a blocking force for what I have started developing.

That said, the design is completely composition based, so we can swap  
out about 4 different layers at any time to test different approaches.

Eriks point I think was he is trying to write some of the js side that  
isn't for the time being going to be cross compiled. But as I see it,  
I don't think there will be a reason to hand write a lot because we  
could even create a custom emitter that knows how to spit out our core  
js framework. Which then could be just one more abstraction layer.

Mike

Quoting Kevin Newman <Ca...@unFocus.com>:

> I understood Frank's approach as vanilla-js (ES5) - eg, no dependencies.
>
> JS is JS though - you can write Backbone.j models in Typescript,  
> wrap jQuery based views in coffee script, and lay everything out  
> using mustache with some Jangaroo games mixed in just for giggles.  
> At the end of the day it's all just javascript.
>
> Kevin N.
>
>
> On 12/14/12 6:17 AM, Michael Schmalle wrote:
>> I say stick with goog, if Frank wants to use something else he can.  
>> If in the future we find a better way, I will PERSONALLY help  
>> change every freaking line of code Erik. Just focus on goog!
>>
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Kevin Newman <Ca...@unFocus.com>]

I understood Frank's approach as vanilla-js (ES5) - eg, no dependencies.

JS is JS though - you can write Backbone.j models in Typescript, wrap 
jQuery based views in coffee script, and lay everything out using 
mustache with some Jangaroo games mixed in just for giggles. At the end 
of the day it's all just javascript.

Kevin N.


On 12/14/12 6:17 AM, Michael Schmalle wrote:
> I say stick with goog, if Frank wants to use something else he can. If 
> in the future we find a better way, I will PERSONALLY help change 
> every freaking line of code Erik. Just focus on goog!
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Daniel Wasilewski <de...@gmail.com>:

> Hi guys,
>
> I've lost a track on the Falcon JS for a while, (busy freelancing to  
> survive and pay my bills), but at time to time visiting the list.
> And don't quite understand the status. Is it like we have 3  
> different people working on their own/favourite implementation at  
> the same time?

No, We have the FlaconJS over bloated prototype as we call it. And we  
have what I just committed to svn. Erik is trying to work on the js  
framework level and actionscript component framework.

I know why he is getting upset, he needs to know what design pattern  
he is using because that determines how he has to "write" is js code.

I say stick with goog, if Frank wants to use something else he can. If  
in the future we find a better way, I will PERSONALLY help change  
every freaking line of code Erik. Just focus on goog!


> I've seen Michael done significant progress with his rewrite from scratch.
> But in my mind it wasn't excluding 'goog' approach for JS output  
> since he mentioned is not there yet.

Yes, I actually does spit out a bit of goog. I said I was changing  
that becasue I wanted and abstract class. Now that I think about it,  
Erik may have misinterpreted that as I was "refactoring" goog out,  
which is NOT what I said.

I said, I wanted the walker to be agnostic when it comes to javascript  
implementation. That is why I also said, this thing is going to spit  
out valid ActionScript code before JavaScript.


> I am sure bit and pieces of this puzzle can be put together. And  
> even if we have a prototype of Falcon in current form, Michael  
> decided to investigate different approach.

Yeah, this was out of survival. There is to much waste in this world  
because people half ass stuff, I am not one of those people. I take  
pride in my creation and design. If I'm wrong about the  
implementation, I don't even care, I will just learn new things. :)

> Some say it is not worth it, but I do appreciate his effort because  
> this project is on research state, not production ready. And this  
> very project needs solid foundations to start from. We don't want to  
> build on top of over-bloated solution only because it has been done.  
> I've seen many things done in my life, but quite useless as well.

Agreed, 2/3 of the things created these days are useless, just look at  
the millions of abandoned open source projects and this will prove  
that point.


> No effort in order to try out different solutions and approaches is wasted.
> And as I said, things can be put together especially by people have  
> learn something during research time and have more experience now.


That is why I took a week of MY time to get up in svn a valid  
alternate cross compiler, I want to give people hope in a new  
direction so it can galvanize a new effort.

What will be, will be.

Mike

> On 12/14/2012 8:33 AM, Erik de Bruin wrote:
>> So, basically, nobody loves the "goog" approach I spend the last weeks
>> working on (based mostly on feedback from the various discussion on
>> the list).
>>
>> Or, let me rephrase, nobody cares enough to contribute to it?
>>
>> EdB
>>
>>
>> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
>>> This is great news, Mike! I will also try to dig into your code this
>>> weekend.
>>> In the meantime, I've been busy figuring out the "essence" of a new
>>> JavaScript runtime format that uses the principles described in my blog,
>>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>>> more concise than the current Jangaroo Runtime. For IE8 and other non-ES5
>>> browsers, we would then use polyfills for all ES5 functions used.
>>> Let's see if I can get an approval from my company to contribute; if it
>>> takes too long, I'd blog about the concepts and you or someone else would
>>> have to implement them.
>>> Greetings
>>> -Frank-
>>>
>>>
>>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>>> <ap...@teotigraphix.com>wrote:
>>>
>>>> Not really,
>>>>
>>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>>> pieces. I purposely put it all back together myself so I knew what was
>>>> going on. So every class in the committed code was assembled by me, to
>>>> figure out it's function if relevant to the new design.
>>>>
>>>> Besides most of it had either be deleted of changed because I am not
>>>> targeting SWF what so ever.
>>>>
>>>> I tried to stick with the same base implementation so we kept the
>>>> multi-threaded Falcon parsing.
>>>>
>>>> Take a look at the org.apache.flex.compiler.**internal.js.codegen package.
>>>>
>>>> Specifically ASBlockWalker from that class alone you should see that this
>>>> is a completely different implementation.
>>>>
>>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>>> some javascript emitting specific to the closure compiler. I want  
>>>> to change
>>>> this and have a base class not dependent on anything but to be able to
>>>> override it.
>>>>
>>>> Case in point, most expressions and statements map the same in AS to JS,
>>>> so having a base implementation not tied to anything will be a positive
>>>> thing. I also don't like mixing design specific things in the base
>>>> traversing class, another reason why I want an abstract base or two.
>>>>
>>>> Anyway, very prototype code and I reserve the right to yank things around.
>>>> :) I just wanted to get it up to show others there might be an easier and
>>>> more flexible way to get to where we need to go without the BURM.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>
>>>>  I will try to look this weekend.
>>>>> Can you briefly describe the important files to look at?  Did  
>>>>> you copy the
>>>>> FalconJS files then do most of your work in a few of them?
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>>
>>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Well, I spent the last 4 days working on this to where it was
>>>>>> something we all could start talking about.
>>>>>>
>>>>>> Is it viable?, I really think so. I have spent a lot of time tinkering
>>>>>> with the framework, take a look. It's in my whiteboard for now under 2
>>>>>> Eclipse projects.
>>>>>>
>>>>>> I know there was just a discussion about .project files but I
>>>>>> committed the .project and .classpath for both application and test
>>>>>> project, just like the rest of Falcon.
>>>>>>
>>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>>> later but, since I'm the one putting this together, that is what I
>>>>>> decided was best for testing first. Once we get all ActionScript
>>>>>> generating, we start overriding things for JavaScript specific
>>>>>> implementations.
>>>>>>
>>>>>> Source [0]
>>>>>>
>>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>>> statements. Its a good start.
>>>>>>
>>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>>> Please, I hate them. :)
>>>>>>
>>>>>> Peace,
>>>>>> Mike
>>>>>>
>>>>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>>>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>>
>>>>> --
>>>>> 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: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Frank Wienberg <fr...@jangaroo.net>:

> Hi Dan,
>
> just to get things straight, I am not working on a different
> implementation, but discussion with Erik and Mike trying to find the
> optimal JavaScript output format. In my current experiments, I am trying an
> approach without the "goog" library, which does not mean you cannot use the
> Google Closure Compiler to optimize the output. For loading and linking
> classes, I use RequireJS, which is an implementation of the AMD module
> format like "goog", but in contrast, it only does that and not a bagful of
> other things. I think that concentrating on one thing at a time
> (loading/linking vs. code optimization) helps clarify the approach and
> minimizes dependencies of design decisions.
> What Mike builds fits my view on how to generate JS code like a glove.
> Mike, your latest refactoring makes perfectly sense, we can put the "goog"
> solution in one subclass and the RequireJS solution in another and compare
> the results!

Yes, this is exactly what I was designing for. I'm a component/tool  
developer are heart, my mind sees the world as a bunch of lego pieces  
that will fit together if assembled with the right interfaces. ;-)

The ASBlockWalker has some serious refactor ahead, but I want to get  
as many unit tests in before I go ripping it a part and making  
abstract super classes with expression and statement hooks.

Mike


> Greetings
> -Frank-
>
> On Fri, Dec 14, 2012 at 11:55 AM, Daniel Wasilewski  
> <de...@gmail.com>wrote:
>
>> And don't quite understand the status. Is it like we have 3 different
>> people working on their own/favourite implementation at the same time?
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Frank Wienberg <fr...@jangaroo.net>]

Hi Dan,

just to get things straight, I am not working on a different
implementation, but discussion with Erik and Mike trying to find the
optimal JavaScript output format. In my current experiments, I am trying an
approach without the "goog" library, which does not mean you cannot use the
Google Closure Compiler to optimize the output. For loading and linking
classes, I use RequireJS, which is an implementation of the AMD module
format like "goog", but in contrast, it only does that and not a bagful of
other things. I think that concentrating on one thing at a time
(loading/linking vs. code optimization) helps clarify the approach and
minimizes dependencies of design decisions.
What Mike builds fits my view on how to generate JS code like a glove.
Mike, your latest refactoring makes perfectly sense, we can put the "goog"
solution in one subclass and the RequireJS solution in another and compare
the results!

Greetings
-Frank-

On Fri, Dec 14, 2012 at 11:55 AM, Daniel Wasilewski <de...@gmail.com>wrote:

> And don't quite understand the status. Is it like we have 3 different
> people working on their own/favourite implementation at the same time?

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Daniel Wasilewski <de...@gmail.com>]

Hi guys,

I've lost a track on the Falcon JS for a while, (busy freelancing to 
survive and pay my bills), but at time to time visiting the list.
And don't quite understand the status. Is it like we have 3 different 
people working on their own/favourite implementation at the same time?

I've seen Michael done significant progress with his rewrite from scratch.
But in my mind it wasn't excluding 'goog' approach for JS output since 
he mentioned is not there yet.

I am sure bit and pieces of this puzzle can be put together. And even if 
we have a prototype of Falcon in current form, Michael decided to 
investigate different approach.
Some say it is not worth it, but I do appreciate his effort because this 
project is on research state, not production ready. And this very 
project needs solid foundations to start from. We don't want to build on 
top of over-bloated solution only because it has been done. I've seen 
many things done in my life, but quite useless as well.

No effort in order to try out different solutions and approaches is wasted.
And as I said, things can be put together especially by people have 
learn something during research time and have more experience now.

On 12/14/2012 8:33 AM, Erik de Bruin wrote:
> So, basically, nobody loves the "goog" approach I spend the last weeks
> working on (based mostly on feedback from the various discussion on
> the list).
>
> Or, let me rephrase, nobody cares enough to contribute to it?
>
> EdB
>
>
> On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
>> This is great news, Mike! I will also try to dig into your code this
>> weekend.
>> In the meantime, I've been busy figuring out the "essence" of a new
>> JavaScript runtime format that uses the principles described in my blog,
>> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
>> more concise than the current Jangaroo Runtime. For IE8 and other non-ES5
>> browsers, we would then use polyfills for all ES5 functions used.
>> Let's see if I can get an approval from my company to contribute; if it
>> takes too long, I'd blog about the concepts and you or someone else would
>> have to implement them.
>> Greetings
>> -Frank-
>>
>>
>> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
>> <ap...@teotigraphix.com>wrote:
>>
>>> Not really,
>>>
>>> I rebuilt everything from scratch. Yes I copied about half the code in
>>> pieces. I purposely put it all back together myself so I knew what was
>>> going on. So every class in the committed code was assembled by me, to
>>> figure out it's function if relevant to the new design.
>>>
>>> Besides most of it had either be deleted of changed because I am not
>>> targeting SWF what so ever.
>>>
>>> I tried to stick with the same base implementation so we kept the
>>> multi-threaded Falcon parsing.
>>>
>>> Take a look at the org.apache.flex.compiler.**internal.js.codegen package.
>>>
>>> Specifically ASBlockWalker from that class alone you should see that this
>>> is a completely different implementation.
>>>
>>> A note to others looking at the code, in the ASBlockWalker I have mixed
>>> some javascript emitting specific to the closure compiler. I want to change
>>> this and have a base class not dependent on anything but to be able to
>>> override it.
>>>
>>> Case in point, most expressions and statements map the same in AS to JS,
>>> so having a base implementation not tied to anything will be a positive
>>> thing. I also don't like mixing design specific things in the base
>>> traversing class, another reason why I want an abstract base or two.
>>>
>>> Anyway, very prototype code and I reserve the right to yank things around.
>>> :) I just wanted to get it up to show others there might be an easier and
>>> more flexible way to get to where we need to go without the BURM.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>> Quoting Alex Harui <ah...@adobe.com>:
>>>
>>>   I will try to look this weekend.
>>>> Can you briefly describe the important files to look at?  Did you copy the
>>>> FalconJS files then do most of your work in a few of them?
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Well, I spent the last 4 days working on this to where it was
>>>>> something we all could start talking about.
>>>>>
>>>>> Is it viable?, I really think so. I have spent a lot of time tinkering
>>>>> with the framework, take a look. It's in my whiteboard for now under 2
>>>>> Eclipse projects.
>>>>>
>>>>> I know there was just a discussion about .project files but I
>>>>> committed the .project and .classpath for both application and test
>>>>> project, just like the rest of Falcon.
>>>>>
>>>>> I'm working on more documentation. A thing to note about the code, my
>>>>> goal is to product ActionScript first, I will explain my thinking
>>>>> later but, since I'm the one putting this together, that is what I
>>>>> decided was best for testing first. Once we get all ActionScript
>>>>> generating, we start overriding things for JavaScript specific
>>>>> implementations.
>>>>>
>>>>> Source [0]
>>>>>
>>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>>> statements. Its a good start.
>>>>>
>>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>>> Please, I hate them. :)
>>>>>
>>>>> Peace,
>>>>> Mike
>>>>>
>>>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>>
>>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Erik de Bruin <er...@ixsoftware.nl>]

So, basically, nobody loves the "goog" approach I spend the last weeks
working on (based mostly on feedback from the various discussion on
the list).

Or, let me rephrase, nobody cares enough to contribute to it?

EdB


On Fri, Dec 14, 2012 at 9:20 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
> This is great news, Mike! I will also try to dig into your code this
> weekend.
> In the meantime, I've been busy figuring out the "essence" of a new
> JavaScript runtime format that uses the principles described in my blog,
> but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
> more concise than the current Jangaroo Runtime. For IE8 and other non-ES5
> browsers, we would then use polyfills for all ES5 functions used.
> Let's see if I can get an approval from my company to contribute; if it
> takes too long, I'd blog about the concepts and you or someone else would
> have to implement them.
> Greetings
> -Frank-
>
>
> On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> Not really,
>>
>> I rebuilt everything from scratch. Yes I copied about half the code in
>> pieces. I purposely put it all back together myself so I knew what was
>> going on. So every class in the committed code was assembled by me, to
>> figure out it's function if relevant to the new design.
>>
>> Besides most of it had either be deleted of changed because I am not
>> targeting SWF what so ever.
>>
>> I tried to stick with the same base implementation so we kept the
>> multi-threaded Falcon parsing.
>>
>> Take a look at the org.apache.flex.compiler.**internal.js.codegen package.
>>
>> Specifically ASBlockWalker from that class alone you should see that this
>> is a completely different implementation.
>>
>> A note to others looking at the code, in the ASBlockWalker I have mixed
>> some javascript emitting specific to the closure compiler. I want to change
>> this and have a base class not dependent on anything but to be able to
>> override it.
>>
>> Case in point, most expressions and statements map the same in AS to JS,
>> so having a base implementation not tied to anything will be a positive
>> thing. I also don't like mixing design specific things in the base
>> traversing class, another reason why I want an abstract base or two.
>>
>> Anyway, very prototype code and I reserve the right to yank things around.
>> :) I just wanted to get it up to show others there might be an easier and
>> more flexible way to get to where we need to go without the BURM.
>>
>> Mike
>>
>>
>>
>>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>  I will try to look this weekend.
>>>
>>> Can you briefly describe the important files to look at?  Did you copy the
>>> FalconJS files then do most of your work in a few of them?
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> Well, I spent the last 4 days working on this to where it was
>>>> something we all could start talking about.
>>>>
>>>> Is it viable?, I really think so. I have spent a lot of time tinkering
>>>> with the framework, take a look. It's in my whiteboard for now under 2
>>>> Eclipse projects.
>>>>
>>>> I know there was just a discussion about .project files but I
>>>> committed the .project and .classpath for both application and test
>>>> project, just like the rest of Falcon.
>>>>
>>>> I'm working on more documentation. A thing to note about the code, my
>>>> goal is to product ActionScript first, I will explain my thinking
>>>> later but, since I'm the one putting this together, that is what I
>>>> decided was best for testing first. Once we get all ActionScript
>>>> generating, we start overriding things for JavaScript specific
>>>> implementations.
>>>>
>>>> Source [0]
>>>>
>>>> Right now I have 103 unit tests ALL passing for expressions and
>>>> statements. Its a good start.
>>>>
>>>> Note; I have not don't a build file, if anybody wants to go for it.
>>>> Please, I hate them. :)
>>>>
>>>> Peace,
>>>> Mike
>>>>
>>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>>
>>>
>>> --
>>> 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
>>
>>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Frank Wienberg <fr...@jangaroo.net>]

This is great news, Mike! I will also try to dig into your code this
weekend.
In the meantime, I've been busy figuring out the "essence" of a new
JavaScript runtime format that uses the principles described in my blog,
but relies on RequireJS (not goog!) and ECMAScript 5 API, making it way
more concise than the current Jangaroo Runtime. For IE8 and other non-ES5
browsers, we would then use polyfills for all ES5 functions used.
Let's see if I can get an approval from my company to contribute; if it
takes too long, I'd blog about the concepts and you or someone else would
have to implement them.
Greetings
-Frank-


On Fri, Dec 14, 2012 at 1:31 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:

> Not really,
>
> I rebuilt everything from scratch. Yes I copied about half the code in
> pieces. I purposely put it all back together myself so I knew what was
> going on. So every class in the committed code was assembled by me, to
> figure out it's function if relevant to the new design.
>
> Besides most of it had either be deleted of changed because I am not
> targeting SWF what so ever.
>
> I tried to stick with the same base implementation so we kept the
> multi-threaded Falcon parsing.
>
> Take a look at the org.apache.flex.compiler.**internal.js.codegen package.
>
> Specifically ASBlockWalker from that class alone you should see that this
> is a completely different implementation.
>
> A note to others looking at the code, in the ASBlockWalker I have mixed
> some javascript emitting specific to the closure compiler. I want to change
> this and have a base class not dependent on anything but to be able to
> override it.
>
> Case in point, most expressions and statements map the same in AS to JS,
> so having a base implementation not tied to anything will be a positive
> thing. I also don't like mixing design specific things in the base
> traversing class, another reason why I want an abstract base or two.
>
> Anyway, very prototype code and I reserve the right to yank things around.
> :) I just wanted to get it up to show others there might be an easier and
> more flexible way to get to where we need to go without the BURM.
>
> Mike
>
>
>
>
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>  I will try to look this weekend.
>>
>> Can you briefly describe the important files to look at?  Did you copy the
>> FalconJS files then do most of your work in a few of them?
>>
>> Thanks,
>> -Alex
>>
>>
>> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>
>>> Hi,
>>>
>>> Well, I spent the last 4 days working on this to where it was
>>> something we all could start talking about.
>>>
>>> Is it viable?, I really think so. I have spent a lot of time tinkering
>>> with the framework, take a look. It's in my whiteboard for now under 2
>>> Eclipse projects.
>>>
>>> I know there was just a discussion about .project files but I
>>> committed the .project and .classpath for both application and test
>>> project, just like the rest of Falcon.
>>>
>>> I'm working on more documentation. A thing to note about the code, my
>>> goal is to product ActionScript first, I will explain my thinking
>>> later but, since I'm the one putting this together, that is what I
>>> decided was best for testing first. Once we get all ActionScript
>>> generating, we start overriding things for JavaScript specific
>>> implementations.
>>>
>>> Source [0]
>>>
>>> Right now I have 103 unit tests ALL passing for expressions and
>>> statements. Its a good start.
>>>
>>> Note; I have not don't a build file, if anybody wants to go for it.
>>> Please, I hate them. :)
>>>
>>> Peace,
>>> Mike
>>>
>>> - [0] https://svn.apache.org/repos/**asf/incubator/flex/whiteboard/**
>>> mschmalle/<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/>
>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Michael Schmalle <ap...@teotigraphix.com>]

Not really,

I rebuilt everything from scratch. Yes I copied about half the code in  
pieces. I purposely put it all back together myself so I knew what was  
going on. So every class in the committed code was assembled by me, to  
figure out it's function if relevant to the new design.

Besides most of it had either be deleted of changed because I am not  
targeting SWF what so ever.

I tried to stick with the same base implementation so we kept the  
multi-threaded Falcon parsing.

Take a look at the org.apache.flex.compiler.internal.js.codegen package.

Specifically ASBlockWalker from that class alone you should see that  
this is a completely different implementation.

A note to others looking at the code, in the ASBlockWalker I have  
mixed some javascript emitting specific to the closure compiler. I  
want to change this and have a base class not dependent on anything  
but to be able to override it.

Case in point, most expressions and statements map the same in AS to  
JS, so having a base implementation not tied to anything will be a  
positive thing. I also don't like mixing design specific things in the  
base traversing class, another reason why I want an abstract base or  
two.

Anyway, very prototype code and I reserve the right to yank things  
around. :) I just wanted to get it up to show others there might be an  
easier and more flexible way to get to where we need to go without the  
BURM.

Mike




Quoting Alex Harui <ah...@adobe.com>:

> I will try to look this weekend.
>
> Can you briefly describe the important files to look at?  Did you copy the
> FalconJS files then do most of your work in a few of them?
>
> Thanks,
> -Alex
>
>
> On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> Hi,
>>
>> Well, I spent the last 4 days working on this to where it was
>> something we all could start talking about.
>>
>> Is it viable?, I really think so. I have spent a lot of time tinkering
>> with the framework, take a look. It's in my whiteboard for now under 2
>> Eclipse projects.
>>
>> I know there was just a discussion about .project files but I
>> committed the .project and .classpath for both application and test
>> project, just like the rest of Falcon.
>>
>> I'm working on more documentation. A thing to note about the code, my
>> goal is to product ActionScript first, I will explain my thinking
>> later but, since I'm the one putting this together, that is what I
>> decided was best for testing first. Once we get all ActionScript
>> generating, we start overriding things for JavaScript specific
>> implementations.
>>
>> Source [0]
>>
>> Right now I have 103 unit tests ALL passing for expressions and
>> statements. Its a good start.
>>
>> Note; I have not don't a build file, if anybody wants to go for it.
>> Please, I hate them. :)
>>
>> Peace,
>> Mike
>>
>> - [0] https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn

[Alex Harui <ah...@adobe.com>]

I will try to look this weekend.

Can you briefly describe the important files to look at?  Did you copy the
FalconJS files then do most of your work in a few of them?

Thanks,
-Alex


On 12/13/12 3:37 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:

> 
> Hi,
> 
> Well, I spent the last 4 days working on this to where it was
> something we all could start talking about.
> 
> Is it viable?, I really think so. I have spent a lot of time tinkering
> with the framework, take a look. It's in my whiteboard for now under 2
> Eclipse projects.
> 
> I know there was just a discussion about .project files but I
> committed the .project and .classpath for both application and test
> project, just like the rest of Falcon.
> 
> I'm working on more documentation. A thing to note about the code, my
> goal is to product ActionScript first, I will explain my thinking
> later but, since I'm the one putting this together, that is what I
> decided was best for testing first. Once we get all ActionScript
> generating, we start overriding things for JavaScript specific
> implementations.
> 
> Source [0]
> 
> Right now I have 103 unit tests ALL passing for expressions and
> statements. Its a good start.
> 
> Note; I have not don't a build file, if anybody wants to go for it.
> Please, I hate them. :)
> 
> Peace,
> Mike
> 
> - [0] https://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui