Quoting Daniel Wasilewski <devudes...@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
<apa...@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 <aha...@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" <apa...@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
