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 Sat, 30 Mar 2013 16:16:42 GMT
Did you try to put the flash.*.* thing back (revert your latest commit)?

EdB



On Sat, Mar 30, 2013 at 4:20 PM, Erik de Bruin <erik@ixsoftware.nl> wrote:
> Or, it might have something to do with your last ASJS commit... remove
> flash.*.* from implicit imports... If you revert that locally, does
> FalconJx work? It wasn't there yesterday, so that's the only
> difference in code between you and me.
>
> We need to set up functional testing for Falcon/FlexJS soon!
>
> EdB
>
>
>
> On Sat, Mar 30, 2013 at 4:15 PM, Erik de Bruin <erik@ixsoftware.nl> wrote:
>> Nope, Safari works well for me, and there doesn't need to be the extra
>> method in the main HTML anymore, I remember. Weird.
>>
>> EdB
>>
>>
>>
>> On Sat, Mar 30, 2013 at 4:13 PM, Erik de Bruin <erik@ixsoftware.nl> wrote:
>>> Maybe I'm doing something wrong... the example on my p.a.o works for you?
>>>
>>> http://people.apache.org/~erikdebruin/flexjs/
>>>
>>> Maybe try Chrome?
>>>
>>> EdB
>>>
>>>
>>>
>>> On Sat, Mar 30, 2013 at 4:01 PM, Alex Harui <aharui@adobe.com> wrote:
>>>> I'm not seeing anything like that in the HTML wrapper.  Safari is definitely
>>>> throwing on exception on "new Event".  Any idea what I'm doing wrong?
>>>>
>>>>
>>>> On 3/30/13 7:54 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>>>
>>>>> I left out FlexGlobals on purpose, I plan to bring the Google Closure
>>>>> way of dealing with events to FlexJS. The GC way is not dependent on
>>>>> DOM based events and fits very snugly with the way Flex handles
>>>>> events.
>>>>>
>>>>> In the mean time I've a method in the "main" HTML that is called Event
>>>>> and that passes the event through to FlexGlobals for now.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 30, 2013 at 3:47 PM, Alex Harui <aharui@adobe.com>
wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>> I finally got time to try to switch over to FalconJX.  It produces
js files
>>>>>> and the app shows up, but the console shows an exception and the
>>>>>> interactivity of the application is mostly broken because the generated
js
>>>>>> code has snippets like this:
>>>>>>
>>>>>> models.MyModel.prototype.set_labelText = function(value) {
>>>>>>     var self = this;
>>>>>>     if (value != self._labelText) {
>>>>>>         self._labelText = value;
>>>>>>         self.dispatchEvent(new Event("labelTextChanged"));
>>>>>>     }
>>>>>> };
>>>>>>
>>>>>> In the FalconJS output, we are calling FlexGlobals.newObject because
Event
>>>>>> is a special class in the browser that can't be instantiated via
"new" and
>>>>>> FlexJS is using these DOM Events.
>>>>>>
>>>>>> Did I miss a flag, or can I go about trying to intercept these calls
and
>>>>>> have them call FlexGlobals.newObject instead?
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>>
>>>>>> On 3/29/13 11:58 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>
>
>
> --
> 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