flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [FalconJx] progress update
Date Fri, 29 Mar 2013 18:58:47 GMT
Ok, we're back in business! I think this time I have been working with
the right version of FlexJS (the one with the timer and the drop down
list?) and it looks to work as advertised:

http://people.apache.org/~erikdebruin/flexjs/

Time to get packing for the long flight ;-)

EdB



On Fri, Mar 29, 2013 at 3:15 PM, Erik de Bruin <erik@ixsoftware.nl> wrote:
> Ah, and there's plenty left for you to "learn" from :-)
>
> EdB
>
>
>
> On Fri, Mar 29, 2013 at 2:30 PM, Alex Harui <aharui@adobe.com> wrote:
>> 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.
>>>
>>> EdB
>>>
>>> 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):
>>>>
>>>> http://people.apache.org/~erikdebruin/flexjs/
>>>>
>>>> Onwards and upwards ;-)
>>>>
>>>> EdB
>>>>
>>>>
>>>> On Wed, Mar 27, 2013 at 9:58 PM, Erik de Bruin <erik@ixsoftware.nl>
wrote:
>>>>> 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.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>>
>>>>>> I think in FalconJX you might have to modify the node tree in several
>>>>>> places
>>>>>> when you hit a [Bindable] node.
>>>>>>
>>>>>> It isn't working correctly in FalconJS either, but my "customer"
needs it
>>>>>> so
>>>>>> I'm hacking a fix.
>>>>>>
>>>>>>
>>>>>> On 3/27/13 1:28 PM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>>>>>
>>>>>>> No, not yet. How is this set up in FlexJS? I'm sure I can read
Metadata
>>>>>>> and
>>>>>>> Databinding information, so I guess it depends on the requirements
for the
>>>>>>> emitted JS if I can easily implement this ;-)
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, March 27, 2013, Alex Harui wrote:
>>>>>>>
>>>>>>>> Does FalconJX handle [Bindable]?  My "customer" is using
it.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/27/13 11:56 AM, "Michael Schmalle" <apache@teotigraphix.com>
wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Quoting Erik de Bruin <erik@ixsoftware.nl>:
>>>>>>>>>
>>>>>>>>>> Another one popped into my head just now: I have
a gut feeling there
>>>>>>>>>> is a bit of circular logic going on in the whole
'backend',
>>>>>>>>>> 'blockwalker' and 'emitter' construct. More specifically
in the way
>>>>>>>>>> the references to them are passed around as arguments
in the
>>>>>>>>>> constructors for the various classes. But I can't
wrap around it well
>>>>>>>>>> enough to figure out whether it's wrong and if so,
what might be done
>>>>>>>>>> about it. Don't get me wrong, it works well, it's
just that it somehow
>>>>>>>>>> isn't "elegant". And that's in no way a comment on
the effectiveness
>>>>>>>>>> or quality of your code, just something I thought
I'd share and see
>>>>>>>>>> what you think.
>>>>>>>>>
>>>>>>>>> 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 within
>>>>>>>>> MXML.
>>>>>>>>>
>>>>>>>>> There is a buffer writer(output stream), a writer, a
visitor and
>>>>>>>>> emitter.
>>>>>>>>>
>>>>>>>>> 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 block
>>>>>>>>> walker is a visitor and the emitter is a visitor. You
cannot escape
>>>>>>>>> the fact there is recursion.
>>>>>>>>>
>>>>>>>>> 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 me
>>>>>>>>> and lighting in the sky, there may be parts that could
be logicalized.
>>>>>>>>>
>>>>>>>>> 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 wrote.
>>>>>>>>> So I guess we both can experiment, we can agree to leave
the core
>>>>>>>>> alone for the time being.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> EdB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 27, 2013 at 7:41 PM, Erik de Bruin <erik@ixsoftware.nl>
>>>>>>>> wrote:
>>>>>>>>>>> Mike,
>>>>>>>>>>>
>>>>>>>>>>> Just kidding ;-)
>>>>>>>>>>>
>>>>>>>>>>> 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 all the
>>>>>>>>>>> APIs alone.
>>>>>>>>>>>
>>>>>>>>>>> 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 working
>>>>>>>>>>> in groups, but that seems like a nice thing to
do), since I've been
>>>>>>>>>>> piling on stuff. I did my best to keep everything
clean and in line
>>>>>>>>>>> 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 AS
>>>>>>>>>>> emitting within the MXML emitter, not really
sure if I did the right
>>>>>>>>>>> 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 whole
>>>>>>>>>>> "programming to interfaces, not implementations"
part that we nearly
>>>>>>>>>>> adhere to, but not quite, we might have another
look at that as well.
>>>>>>>>>>>
>>>>>>>>>>> EdB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 27, 2013 at 7:33 PM, Michael Schmalle
>>>>>>>>>>> <apache@teotigraphix.com> wrote:
>>>>>>>>>>>> No thats not what I meant.
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> What I meant to say was, the design keeps
people in the correct
>>>>>>>> spaces. :)
>>>>>>>>>>>>
>>>>>>>>>>>> Note; I AM SURE there are as3 bugs coming,
its just nice not
>>>>>>>>>>>> having to chase
>>>>>>>>>>>> them right now.
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>> Alex Harui
>>>>>>>> Flex SDK Team
>>>>>>>> Adobe Systems, Inc.
>>>>>>>> http://blogs.adobe.com/aharui
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>
>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Mime
View raw message