Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (athena.apache.org: domain of aharui@adobe.com designates
 64.18.1.37 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Date: Fri, 29 Mar 2013 06:30:32 -0700
Subject: Re: [FalconJx] progress update
Thread-Topic: [FalconJx] progress update
Thread-Index: Ac4sT3bMsBrM5XOfRbuQ1ddh9ZFlDAAMh88U
Message-ID: <CD7AE588.5045E%aharui@adobe.com>
In-Reply-To: 
 <CAJs+wW1-CbfvwLqcCicHNJZSqdJF7uoaEhNmzqLdz61kr4quTw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.16.0.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

No worries.  Might be a good way for me to learn how it works by getting it
to work.


On 3/29/13 12:31 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:

> Uh oh... Turns out I was testing against an outdated ASJS lib
> (pre-fb614905ac), so FalconJx DOESN'T WORK against the current
> iteration of FlexJS. Sorry about that. I will work on that today, but
> I don't have a lot of time, so it might be a while before I can catch
> up, due to next week's travel to the land of golden opportunity.
>=20
> EdB
>=20
> On Thu, Mar 28, 2013 at 5:24 PM, Erik de Bruin <erik@ixsoftware.nl> wrote=
:
>> And another update (things are going much better than I expected):
>> FalconJx can now emit a fully functional version of the
>> FlexJSTest_again demo application. You can see it in action here
>> (provided you use Chrome or Firefox, I just noticed):
>>=20
>> http://people.apache.org/~erikdebruin/flexjs/
>>=20
>> Onwards and upwards ;-)
>>=20
>> EdB
>>=20
>>=20
>> On Wed, Mar 27, 2013 at 9:58 PM, Erik de Bruin <erik@ixsoftware.nl> wrot=
e:
>>> I'd have to look into it for specifics, but of the top of my head it
>>> seems that this most depends on the implementation in the FlexJS JS
>>> framework. Emitting the strings required by that framework should
>>> really be easy enough. If needed we can "look forward" into AST to
>>> look for binding information. I do this in several other places
>>> already. Even the binding expressions shouldn't be too much of a
>>> problem, again depending on how this will be handled by the JS
>>> framework.
>>>=20
>>> EdB
>>>=20
>>>=20
>>>=20
>>> On Wed, Mar 27, 2013 at 9:36 PM, Alex Harui <aharui@adobe.com> wrote:
>>>> [Bindable] results in extra codegen.  Binding expressions with {} is a
>>>> whole
>>>> other ball of work.
>>>>=20
>>>> I think in FalconJX you might have to modify the node tree in several
>>>> places
>>>> when you hit a [Bindable] node.
>>>>=20
>>>> It isn't working correctly in FalconJS either, but my "customer" needs=
 it
>>>> so
>>>> I'm hacking a fix.
>>>>=20
>>>>=20
>>>> On 3/27/13 1:28 PM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>>>=20
>>>>> No, not yet. How is this set up in FlexJS? I'm sure I can read Metada=
ta
>>>>> and
>>>>> Databinding information, so I guess it depends on the requirements fo=
r the
>>>>> emitted JS if I can easily implement this ;-)
>>>>>=20
>>>>> EdB
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Wednesday, March 27, 2013, Alex Harui wrote:
>>>>>=20
>>>>>> Does FalconJX handle [Bindable]?  My "customer" is using it.
>>>>>>=20
>>>>>>=20
>>>>>> On 3/27/13 11:56 AM, "Michael Schmalle" <apache@teotigraphix.com> wr=
ote:
>>>>>>=20
>>>>>>>=20
>>>>>>> Quoting Erik de Bruin <erik@ixsoftware.nl>:
>>>>>>>=20
>>>>>>>> Another one popped into my head just now: I have a gut feeling the=
re
>>>>>>>> is a bit of circular logic going on in the whole 'backend',
>>>>>>>> 'blockwalker' and 'emitter' construct. More specifically in the wa=
y
>>>>>>>> the references to them are passed around as arguments in the
>>>>>>>> constructors for the various classes. But I can't wrap around it w=
ell
>>>>>>>> enough to figure out whether it's wrong and if so, what might be d=
one
>>>>>>>> about it. Don't get me wrong, it works well, it's just that it som=
ehow
>>>>>>>> isn't "elegant". And that's in no way a comment on the effectivene=
ss
>>>>>>>> or quality of your code, just something I thought I'd share and se=
e
>>>>>>>> what you think.
>>>>>>>=20
>>>>>>> Actually I think it works fine. The problem you are facing is with =
the
>>>>>>> MXML emitter I am sure. This adds complexity to what you are trying=
 to
>>>>>>> accomplish and it is circular from the perspective of using AS with=
in
>>>>>>> MXML.
>>>>>>>=20
>>>>>>> There is a buffer writer(output stream), a writer, a visitor and
>>>>>>> emitter.
>>>>>>>=20
>>>>>>> Each one takes a dependency of its parent. Trust me, if there is a
>>>>>>> child that knows about its parent I am blind. Like I said, the bloc=
k
>>>>>>> walker is a visitor and the emitter is a visitor. You cannot escape
>>>>>>> the fact there is recursion.
>>>>>>>=20
>>>>>>> If you can think of a more elegant way to set it up, by  all means
>>>>>>> write a prototype. Remember, I wrote this with an atom bomb under m=
e
>>>>>>> and lighting in the sky, there may be parts that could be logicaliz=
ed.
>>>>>>>=20
>>>>>>> I have another full compiler in Randori that I am going to use as a
>>>>>>> proof of concept with compiler plugins and my ASDoc compiler I wrot=
e.
>>>>>>> So I guess we both can experiment, we can agree to leave the core
>>>>>>> alone for the time being.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> EdB
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Wed, Mar 27, 2013 at 7:41 PM, Erik de Bruin <erik@ixsoftware.nl=
>
>>>>>> wrote:
>>>>>>>>> Mike,
>>>>>>>>>=20
>>>>>>>>> Just kidding ;-)
>>>>>>>>>=20
>>>>>>>>> I'm really happy with FalconJx, once you get to know it it's a
>>>>>>>>> pleasure to work with. I hope my last commits didn't give you any
>>>>>>>>> additional work in your other projects? I did my best to leave al=
l the
>>>>>>>>> APIs alone.
>>>>>>>>>=20
>>>>>>>>> There are plenty of TODOs in the code, and I would also like to
>>>>>>>>> suggest some kind of code review or something (I'm not used to wo=
rking
>>>>>>>>> in groups, but that seems like a nice thing to do), since I've be=
en
>>>>>>>>> piling on stuff. I did my best to keep everything clean and in li=
ne
>>>>>>>>> with the spirit of the rest of the code, but there are some areas
>>>>>>>>> where I'd like to have a second opinion. Like with the code that =
is
>>>>>>>>> copied between the DOC and JS emitters, seems there might be room=
 for
>>>>>>>>> improvement there. Also of note is the way I've implemented the A=
S
>>>>>>>>> emitting within the MXML emitter, not really sure if I did the ri=
ght
>>>>>>>>> thing there. And finally (not really, but this is all I can think=
 of
>>>>>>>>> for now, after the marathon hacking I did today) there is the who=
le
>>>>>>>>> "programming to interfaces, not implementations" part that we nea=
rly
>>>>>>>>> adhere to, but not quite, we might have another look at that as w=
ell.
>>>>>>>>>=20
>>>>>>>>> EdB
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Wed, Mar 27, 2013 at 7:33 PM, Michael Schmalle
>>>>>>>>> <apache@teotigraphix.com> wrote:
>>>>>>>>>> No thats not what I meant.
>>>>>>>>>>=20
>>>>>>>>>> I am saying with the Randori project compiler, I have not had to
>>>>>> touch the
>>>>>>>>>> core framework for weeks and it is compiling 1000's of lines of =
code.
>>>>>> And
>>>>>>>>>> application code now.
>>>>>>>>>>=20
>>>>>>>>>> What I meant to say was, the design keeps people in the correct
>>>>>> spaces. :)
>>>>>>>>>>=20
>>>>>>>>>> Note; I AM SURE there are as3 bugs coming, its just nice not
>>>>>>>>>> having to chase
>>>>>>>>>> them right now.
>>>>>>>>>>=20
>>>>>>>>>> Mike
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>>>>=20
>>>>>>=20
>>>>=20
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Ix Multimedia Software
>>>=20
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>=20
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>=20
>>=20
>>=20
>> --
>> Ix Multimedia Software
>>=20
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>=20
>> T. 06-51952295
>> I. www.ixsoftware.nl
>=20
>=20

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