Nearly there... EdB
On Fri, Mar 29, 2013 at 2:30 PM, Alex Harui <aha...@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" <e...@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 <e...@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 <e...@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 <aha...@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" <e...@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" <apa...@teotigraphix.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> Quoting Erik de Bruin <e...@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 <e...@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 >>>>>>>>>> <apa...@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
