You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2012/11/17 13:47:48 UTC
Current compiler question
As a complete compiler noob, but can somebody answer this:
Can we not build a 'mxmlcJS'? I understand that Falcon was specifically
designed to have a 'variable backend' that allows for FalconJS to be hooked
in. Is something like that feasible with the 'previous generation'
compiler(s)?
The advantage would be that we have a fully fledged MXML/AS compiler that
works with the current framework, so no need to rewrite the framework, nor
invest heavily in finishing the remaining 20% of the Falcon MXML parsing
and finish FalconJS. We would 'only' have to rewrite the part of the
compiler that currently outputs 'abc' and the browser side player
(HTML/CSS/JS) :-)
Thoughts?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Current compiler question
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
That's a lot of good information to start with!
Thanks a lot.
Personally, after reading Alex thoughts about the Flex rewrite and watching
Michael Labriola Randori slides I see a future for current work done.
I am very enthusiastic about this new vision and I'll try to give arguments
in its favour when more detailed information is disclosed and am even more
convinced.
We'll see where the river ends up flowing.
Thanks again.
Cheers!
--
Joan Llenas Masó
CEO/CTO Garnet Works SL
T. 93 848 57 27
--
@joangarnet (es)
@joanllenas (en)
http://joan.garnet.io
http://www.garnetworks.com
On Sun, Nov 18, 2012 at 6:42 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> One other thing, I know I have siad this before but I have about 2 years
> of work with AS3 and Java parsers/AST from the following projects of mine;
>
> see; [0]
>
> - AS3 ANTLR implementation of an AS3 DOM.
>
> see; [1]
>
> - Java ANTLR implementation of an AS3 DOM
>
> They aren't perfect projects(The AS3 language is a very hard grammar in
> ANTLR) but I did have my ASDoc clone working with those projects. Also
> created and AS3 AIR application on the desktop for editing asdoc comments
> visually.
>
> see; [2]
>
> The screen shot full size is an AIR app with the asblocks project.
>
> Was a bunch of wasted time but I learned a lot.
>
> Mike
>
> - [0] https://github.com/**teotigraphix/as3-commons-**asblocks<https://github.com/teotigraphix/as3-commons-asblocks>
> - [1] https://github.com/**teotigraphix/as3-commons-**jasblocks<https://github.com/teotigraphix/as3-commons-jasblocks>
> - [2] http://blog.teotigraphix.com/**2012/01/05/apache-flex-asdoc-**
> and-compiler-tooling/<http://blog.teotigraphix.com/2012/01/05/apache-flex-asdoc-and-compiler-tooling/>
>
>
>
> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
> Quoting Joan Llenas Masó <jo...@garnetworks.com>:
>>
>> Michael, (nothing to do with last discussion).
>>> It's obvious that you have knowledge about the compiler so let me ask you
>>> some things...
>>> Aside from what's here (
>>> https://cwiki.apache.org/**confluence/display/FLEX/**Falcon+Overview<https://cwiki.apache.org/confluence/display/FLEX/Falcon+Overview>) what
>>> would you recommend to someone who is curious about the compiler
>>> architecture? (thinking on the possibility of future contributions)
>>> i.e.
>>> Is the compiler built on top of another technology (aside from Java,
>>> obviously) that I'd have to learn about?
>>>
>>
>> No, the lexer/parser implementation is Antrl grammar (creates the AS3 and
>> CSS parsers, CSS lexer), JFlex grammar(creates the AS3, MXML tokenizer),
>> JBurg grammar creates the ABC byte code, CSS emitter.
>>
>> These implementations are pretty tested from the work previous to the
>> donation by Adobe. If we needed to fix bugs in either of the above,
>> knowledge in ANTlr, JFlex and JBurg is needed.
>>
>>
>> Is Eclipse knowledge required (when you are not interested in the Eclipse
>>> plugin)?
>>>
>>
>> No, as in anything Java, I'm sure other IDEs handle editing fine and ANT
>> builds everything, calling parser, tokenizer and emitter generators in the
>> above mentioned.
>>
>> Any known design patterns (compiler specific) that should be known prior
>>> to
>>> start looking at the compiler code / documentation?
>>>
>>
>> No, you need to learn the IDefinition API, that is where any IDE that has
>> a type hierarchy comes in. :) It's not even necessary to understand the
>> parser node framework to understand what is going on.
>>
>> Is the compiler 100% Java based or we need some C / C++ knowledge?
>>>
>>
>> 100% Java.
>>
>> One other thing to note here, with all this talk of rewriting the
>> framework and Haxe, etc. I have been weary of starting anything because if
>> the baby is thrown out with the bath water on a project level. All my work
>> and Gordon's just gets flushed down the drain.
>>
>> I don't have this time to burn. SO I am patiently waiting to see where
>> the masses are migrating to. While working on my other projects in Android
>> mobile.
>>
>> Also note, I was just about to do a lot on the wiki trying to give deeper
>> understanding to the IDefinition framework, but all this talk last week has
>> me worried about wasted time and effort again.
>>
>>
>> Mike
>>
>> Thank you in advanced!
>>>
>>> Cheers
>>>
>>>
>>>
>>> On Sun, Nov 18, 2012 at 5:34 PM, Michael Schmalle
>>> <ap...@teotigraphix.com>**wrote:
>>>
>>> I don't quite understand what you are saying but, I have said 100 times
>>>> I
>>>> do not like the Flash Player in many threads, read it on my blog etc.
>>>>
>>>> What I said below means, I would bet on AS3 language for the time being
>>>> NOT the SWF format. The compilers are lexers/parsers first and parse
>>>> AS3,
>>>> MXML and CSS into AST which from there we can do anything with, the ABC
>>>> bytecode emitter is at the end of the chain and has nothing to do with
>>>> what
>>>> I want to fiddle with.
>>>>
>>>> So please do not think I want anything to do with the current or future
>>>> Flash Player AVM, I don't.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Quoting Stefan Horochovec <st...@gmail.com>:
>>>>
>>>> I think a little differently, the only answer we have now is that we
>>>> move
>>>>
>>>>> from dependence on runtime from Adobe. This lack of information and
>>>>> changing business plans involving the VM is terrible for the future of
>>>>> Apache Flex.
>>>>>
>>>>> Or are we an independent solution for RIA development, or we will live
>>>>> forever in this situation.
>>>>>
>>>>> For me it is completely impractical to bet on a framework based on a VM
>>>>> that who develops the framework, completely unaware of his future
>>>>> runtime.
>>>>>
>>>>> Regards
>>>>>
>>>>> Stefan Horochovec
>>>>>
>>>>>
>>>>>
>>>>> 2012/11/17 Hordur Thordarson <ho...@lausn.is>
>>>>>
>>>>> > The last two days proves that know one has any real answers to
>>>>> anything
>>>>>
>>>>>> right now. The only way to get answers is the scientific method of
>>>>>> limit
>>>>>> your variables and test the crap out the ideas.
>>>>>>
>>>>>> Well said, I totally agree with this :-)
>>>>>>
>>>>>> On 17.11.2012, at 19:00, Michael Schmalle wrote:
>>>>>>
>>>>>> Before I commit to anything that is in Haxe land or total rewriting
>>>>>>>
>>>>>> etc,
>>>>>> I am going to experiment with FalconAS, FalconJS and the MXML compiler
>>>>>> for
>>>>>> fun.
>>>>>>
>>>>>>>
>>>>>>> To me as you just said, experimenting at the moment with something we
>>>>>>>
>>>>>> have is going to be an experiment for me. Unless some chariot flies
>>>>>> from
>>>>>> the sky and lifts Apache Flex into the heavens, I think there is just
>>>>>> going
>>>>>> to be a lot of experimenting with all angles until some one starts
>>>>>> actually
>>>>>> making progress on something.
>>>>>>
>>>>>>>
>>>>>>> The last two days proves that know one has any real answers to
>>>>>>> anything
>>>>>>>
>>>>>> right now. The only way to get answers is the scientific method of
>>>>>> limit
>>>>>> your variables and test the crap out the ideas.
>>>>>>
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>>>>
>>>>>>> I understand and I agree. I was just reacting to an email by Gordon
>>>>>>>> explaining that MXML 'coverage' in Falcon is at 80%, but that the
>>>>>>>> last
>>>>>>>>
>>>>>>> 20%
>>>>>>
>>>>>>> will take many man-months to finish, something Gordon on his own is
>>>>>>>> obviously not capable of contributing. And then there's FalconJS,
>>>>>>>>
>>>>>>> which
>>>>>>
>>>>>>> from the few things I was able to find with a little help from
>>>>>>>> Google,
>>>>>>>>
>>>>>>> is
>>>>>>
>>>>>>> awesome, but only a research project. That means that it has the
>>>>>>>>
>>>>>>> promise to
>>>>>>
>>>>>>> be great, but also that it will require a lot of work to get done.
>>>>>>>>
>>>>>>>> Now, I'm not (very) impatient, so if you can only get into details
>>>>>>>>
>>>>>>> after
>>>>>>
>>>>>>> the donation clears, I understand, but meanwhile the conversation
>>>>>>>> seem
>>>>>>>>
>>>>>>> to
>>>>>>
>>>>>>> be about re-writing this and using that, anything but what we
>>>>>>>> actually
>>>>>>>>
>>>>>>> have
>>>>>>
>>>>>>> available at the moment. I was looking at our resources and thinking
>>>>>>>>
>>>>>>> about
>>>>>>
>>>>>>> alternatives… and thought we should consider this as an option, or at
>>>>>>>>
>>>>>>> least
>>>>>>
>>>>>>> discuss using what we have and know to work.
>>>>>>>>
>>>>>>>> EdB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>>>>>
>>>>>>>>> > As a complete compiler noob, but can somebody answer this:
>>>>>>>>> >
>>>>>>>>> > Can we not build a 'mxmlcJS'? I understand that Falcon was
>>>>>>>>>
>>>>>>>> specifically
>>>>>>
>>>>>>> > designed to have a 'variable backend' that allows for FalconJS to
>>>>>>>>>
>>>>>>>> be
>>>>>>
>>>>>>> hooked
>>>>>>>>> > in. Is something like that feasible with the 'previous
>>>>>>>>> generation'
>>>>>>>>> > compiler(s)?
>>>>>>>>> >
>>>>>>>>> > The advantage would be that we have a fully fledged MXML/AS
>>>>>>>>>
>>>>>>>> compiler
>>>>>> that
>>>>>>
>>>>>>> > works with the current framework, so no need to rewrite the
>>>>>>>>>
>>>>>>>> framework,
>>>>>>
>>>>>>> nor
>>>>>>>>> > invest heavily in finishing the remaining 20% of the Falcon MXML
>>>>>>>>>
>>>>>>>> parsing
>>>>>>
>>>>>>> > and finish FalconJS. We would 'only' have to rewrite the part of
>>>>>>>>>
>>>>>>>> the
>>>>>>
>>>>>>> > compiler that currently outputs 'abc' and the browser side player
>>>>>>>>> > (HTML/CSS/JS) :-)
>>>>>>>>> >
>>>>>>>>> > Thoughts?
>>>>>>>>> >
>>>>>>>>> In theory, Falcon should also be faster. And, IMO, the code is
>>>>>>>>>
>>>>>>>> cleaner and
>>>>>>
>>>>>>> has fewer SDK dependencies which will be to our advantage when trying
>>>>>>>>>
>>>>>>>> to
>>>>>>
>>>>>>> get
>>>>>>>>> to other targets.
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>
>>>>
>>>>
>>>
>> --
>> 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
>
>
Re: Current compiler question
Posted by Michael Schmalle <ap...@teotigraphix.com>.
One other thing, I know I have siad this before but I have about 2
years of work with AS3 and Java parsers/AST from the following
projects of mine;
see; [0]
- AS3 ANTLR implementation of an AS3 DOM.
see; [1]
- Java ANTLR implementation of an AS3 DOM
They aren't perfect projects(The AS3 language is a very hard grammar
in ANTLR) but I did have my ASDoc clone working with those projects.
Also created and AS3 AIR application on the desktop for editing asdoc
comments visually.
see; [2]
The screen shot full size is an AIR app with the asblocks project.
Was a bunch of wasted time but I learned a lot.
Mike
- [0] https://github.com/teotigraphix/as3-commons-asblocks
- [1] https://github.com/teotigraphix/as3-commons-jasblocks
- [2]
http://blog.teotigraphix.com/2012/01/05/apache-flex-asdoc-and-compiler-tooling/
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> Quoting Joan Llenas Masó <jo...@garnetworks.com>:
>
>> Michael, (nothing to do with last discussion).
>> It's obvious that you have knowledge about the compiler so let me ask you
>> some things...
>> Aside from what's here (
>> https://cwiki.apache.org/confluence/display/FLEX/Falcon+Overview ) what
>> would you recommend to someone who is curious about the compiler
>> architecture? (thinking on the possibility of future contributions)
>> i.e.
>> Is the compiler built on top of another technology (aside from Java,
>> obviously) that I'd have to learn about?
>
> No, the lexer/parser implementation is Antrl grammar (creates the
> AS3 and CSS parsers, CSS lexer), JFlex grammar(creates the AS3, MXML
> tokenizer), JBurg grammar creates the ABC byte code, CSS emitter.
>
> These implementations are pretty tested from the work previous to
> the donation by Adobe. If we needed to fix bugs in either of the
> above, knowledge in ANTlr, JFlex and JBurg is needed.
>
>
>> Is Eclipse knowledge required (when you are not interested in the Eclipse
>> plugin)?
>
> No, as in anything Java, I'm sure other IDEs handle editing fine and
> ANT builds everything, calling parser, tokenizer and emitter
> generators in the above mentioned.
>
>> Any known design patterns (compiler specific) that should be known prior to
>> start looking at the compiler code / documentation?
>
> No, you need to learn the IDefinition API, that is where any IDE
> that has a type hierarchy comes in. :) It's not even necessary to
> understand the parser node framework to understand what is going on.
>
>> Is the compiler 100% Java based or we need some C / C++ knowledge?
>
> 100% Java.
>
> One other thing to note here, with all this talk of rewriting the
> framework and Haxe, etc. I have been weary of starting anything
> because if the baby is thrown out with the bath water on a project
> level. All my work and Gordon's just gets flushed down the drain.
>
> I don't have this time to burn. SO I am patiently waiting to see
> where the masses are migrating to. While working on my other
> projects in Android mobile.
>
> Also note, I was just about to do a lot on the wiki trying to give
> deeper understanding to the IDefinition framework, but all this talk
> last week has me worried about wasted time and effort again.
>
>
> Mike
>
>> Thank you in advanced!
>>
>> Cheers
>>
>>
>>
>> On Sun, Nov 18, 2012 at 5:34 PM, Michael Schmalle
>> <ap...@teotigraphix.com>wrote:
>>
>>> I don't quite understand what you are saying but, I have said 100 times I
>>> do not like the Flash Player in many threads, read it on my blog etc.
>>>
>>> What I said below means, I would bet on AS3 language for the time being
>>> NOT the SWF format. The compilers are lexers/parsers first and parse AS3,
>>> MXML and CSS into AST which from there we can do anything with, the ABC
>>> bytecode emitter is at the end of the chain and has nothing to do with what
>>> I want to fiddle with.
>>>
>>> So please do not think I want anything to do with the current or future
>>> Flash Player AVM, I don't.
>>>
>>> Mike
>>>
>>>
>>>
>>> Quoting Stefan Horochovec <st...@gmail.com>:
>>>
>>> I think a little differently, the only answer we have now is that we move
>>>> from dependence on runtime from Adobe. This lack of information and
>>>> changing business plans involving the VM is terrible for the future of
>>>> Apache Flex.
>>>>
>>>> Or are we an independent solution for RIA development, or we will live
>>>> forever in this situation.
>>>>
>>>> For me it is completely impractical to bet on a framework based on a VM
>>>> that who develops the framework, completely unaware of his future runtime.
>>>>
>>>> Regards
>>>>
>>>> Stefan Horochovec
>>>>
>>>>
>>>>
>>>> 2012/11/17 Hordur Thordarson <ho...@lausn.is>
>>>>
>>>> > The last two days proves that know one has any real answers to anything
>>>>> right now. The only way to get answers is the scientific method of limit
>>>>> your variables and test the crap out the ideas.
>>>>>
>>>>> Well said, I totally agree with this :-)
>>>>>
>>>>> On 17.11.2012, at 19:00, Michael Schmalle wrote:
>>>>>
>>>>>> Before I commit to anything that is in Haxe land or total rewriting
>>>>> etc,
>>>>> I am going to experiment with FalconAS, FalconJS and the MXML compiler
>>>>> for
>>>>> fun.
>>>>>>
>>>>>> To me as you just said, experimenting at the moment with something we
>>>>> have is going to be an experiment for me. Unless some chariot flies from
>>>>> the sky and lifts Apache Flex into the heavens, I think there is just
>>>>> going
>>>>> to be a lot of experimenting with all angles until some one starts
>>>>> actually
>>>>> making progress on something.
>>>>>>
>>>>>> The last two days proves that know one has any real answers to anything
>>>>> right now. The only way to get answers is the scientific method of limit
>>>>> your variables and test the crap out the ideas.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>>>
>>>>>>> I understand and I agree. I was just reacting to an email by Gordon
>>>>>>> explaining that MXML 'coverage' in Falcon is at 80%, but that the last
>>>>> 20%
>>>>>>> will take many man-months to finish, something Gordon on his own is
>>>>>>> obviously not capable of contributing. And then there's FalconJS,
>>>>> which
>>>>>>> from the few things I was able to find with a little help from Google,
>>>>> is
>>>>>>> awesome, but only a research project. That means that it has the
>>>>> promise to
>>>>>>> be great, but also that it will require a lot of work to get done.
>>>>>>>
>>>>>>> Now, I'm not (very) impatient, so if you can only get into details
>>>>> after
>>>>>>> the donation clears, I understand, but meanwhile the conversation seem
>>>>> to
>>>>>>> be about re-writing this and using that, anything but what we actually
>>>>> have
>>>>>>> available at the moment. I was looking at our resources and thinking
>>>>> about
>>>>>>> alternatives… and thought we should consider this as an option, or at
>>>>> least
>>>>>>> discuss using what we have and know to work.
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>>>>
>>>>>>>> > As a complete compiler noob, but can somebody answer this:
>>>>>>>> >
>>>>>>>> > Can we not build a 'mxmlcJS'? I understand that Falcon was
>>>>> specifically
>>>>>>>> > designed to have a 'variable backend' that allows for FalconJS to
>>>>> be
>>>>>>>> hooked
>>>>>>>> > in. Is something like that feasible with the 'previous generation'
>>>>>>>> > compiler(s)?
>>>>>>>> >
>>>>>>>> > The advantage would be that we have a fully fledged MXML/AS
>>>>> compiler
>>>>> that
>>>>>>>> > works with the current framework, so no need to rewrite the
>>>>> framework,
>>>>>>>> nor
>>>>>>>> > invest heavily in finishing the remaining 20% of the Falcon MXML
>>>>> parsing
>>>>>>>> > and finish FalconJS. We would 'only' have to rewrite the part of
>>>>> the
>>>>>>>> > compiler that currently outputs 'abc' and the browser side player
>>>>>>>> > (HTML/CSS/JS) :-)
>>>>>>>> >
>>>>>>>> > Thoughts?
>>>>>>>> >
>>>>>>>> In theory, Falcon should also be faster. And, IMO, the code is
>>>>> cleaner and
>>>>>>>> has fewer SDK dependencies which will be to our advantage when trying
>>>>> to
>>>>>>>> get
>>>>>>>> to other targets.
>>>>>>>>
>>>>>>>> -
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>
>>>
>>
>
> --
> 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
Re: Current compiler question
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Joan Llenas Masó <jo...@garnetworks.com>:
> Michael, (nothing to do with last discussion).
> It's obvious that you have knowledge about the compiler so let me ask you
> some things...
> Aside from what's here (
> https://cwiki.apache.org/confluence/display/FLEX/Falcon+Overview ) what
> would you recommend to someone who is curious about the compiler
> architecture? (thinking on the possibility of future contributions)
> i.e.
> Is the compiler built on top of another technology (aside from Java,
> obviously) that I'd have to learn about?
No, the lexer/parser implementation is Antrl grammar (creates the AS3
and CSS parsers, CSS lexer), JFlex grammar(creates the AS3, MXML
tokenizer), JBurg grammar creates the ABC byte code, CSS emitter.
These implementations are pretty tested from the work previous to the
donation by Adobe. If we needed to fix bugs in either of the above,
knowledge in ANTlr, JFlex and JBurg is needed.
> Is Eclipse knowledge required (when you are not interested in the Eclipse
> plugin)?
No, as in anything Java, I'm sure other IDEs handle editing fine and
ANT builds everything, calling parser, tokenizer and emitter
generators in the above mentioned.
> Any known design patterns (compiler specific) that should be known prior to
> start looking at the compiler code / documentation?
No, you need to learn the IDefinition API, that is where any IDE that
has a type hierarchy comes in. :) It's not even necessary to
understand the parser node framework to understand what is going on.
> Is the compiler 100% Java based or we need some C / C++ knowledge?
100% Java.
One other thing to note here, with all this talk of rewriting the
framework and Haxe, etc. I have been weary of starting anything
because if the baby is thrown out with the bath water on a project
level. All my work and Gordon's just gets flushed down the drain.
I don't have this time to burn. SO I am patiently waiting to see where
the masses are migrating to. While working on my other projects in
Android mobile.
Also note, I was just about to do a lot on the wiki trying to give
deeper understanding to the IDefinition framework, but all this talk
last week has me worried about wasted time and effort again.
Mike
> Thank you in advanced!
>
> Cheers
>
>
>
> On Sun, Nov 18, 2012 at 5:34 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> I don't quite understand what you are saying but, I have said 100 times I
>> do not like the Flash Player in many threads, read it on my blog etc.
>>
>> What I said below means, I would bet on AS3 language for the time being
>> NOT the SWF format. The compilers are lexers/parsers first and parse AS3,
>> MXML and CSS into AST which from there we can do anything with, the ABC
>> bytecode emitter is at the end of the chain and has nothing to do with what
>> I want to fiddle with.
>>
>> So please do not think I want anything to do with the current or future
>> Flash Player AVM, I don't.
>>
>> Mike
>>
>>
>>
>> Quoting Stefan Horochovec <st...@gmail.com>:
>>
>> I think a little differently, the only answer we have now is that we move
>>> from dependence on runtime from Adobe. This lack of information and
>>> changing business plans involving the VM is terrible for the future of
>>> Apache Flex.
>>>
>>> Or are we an independent solution for RIA development, or we will live
>>> forever in this situation.
>>>
>>> For me it is completely impractical to bet on a framework based on a VM
>>> that who develops the framework, completely unaware of his future runtime.
>>>
>>> Regards
>>>
>>> Stefan Horochovec
>>>
>>>
>>>
>>> 2012/11/17 Hordur Thordarson <ho...@lausn.is>
>>>
>>> > The last two days proves that know one has any real answers to anything
>>>> right now. The only way to get answers is the scientific method of limit
>>>> your variables and test the crap out the ideas.
>>>>
>>>> Well said, I totally agree with this :-)
>>>>
>>>> On 17.11.2012, at 19:00, Michael Schmalle wrote:
>>>>
>>>> > Before I commit to anything that is in Haxe land or total rewriting
>>>> etc,
>>>> I am going to experiment with FalconAS, FalconJS and the MXML compiler
>>>> for
>>>> fun.
>>>> >
>>>> > To me as you just said, experimenting at the moment with something we
>>>> have is going to be an experiment for me. Unless some chariot flies from
>>>> the sky and lifts Apache Flex into the heavens, I think there is just
>>>> going
>>>> to be a lot of experimenting with all angles until some one starts
>>>> actually
>>>> making progress on something.
>>>> >
>>>> > The last two days proves that know one has any real answers to anything
>>>> right now. The only way to get answers is the scientific method of limit
>>>> your variables and test the crap out the ideas.
>>>> >
>>>> > Mike
>>>> >
>>>> >
>>>> > Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>> >
>>>> >> I understand and I agree. I was just reacting to an email by Gordon
>>>> >> explaining that MXML 'coverage' in Falcon is at 80%, but that the last
>>>> 20%
>>>> >> will take many man-months to finish, something Gordon on his own is
>>>> >> obviously not capable of contributing. And then there's FalconJS,
>>>> which
>>>> >> from the few things I was able to find with a little help from Google,
>>>> is
>>>> >> awesome, but only a research project. That means that it has the
>>>> promise to
>>>> >> be great, but also that it will require a lot of work to get done.
>>>> >>
>>>> >> Now, I'm not (very) impatient, so if you can only get into details
>>>> after
>>>> >> the donation clears, I understand, but meanwhile the conversation seem
>>>> to
>>>> >> be about re-writing this and using that, anything but what we actually
>>>> have
>>>> >> available at the moment. I was looking at our resources and thinking
>>>> about
>>>> >> alternatives… and thought we should consider this as an option, or at
>>>> least
>>>> >> discuss using what we have and know to work.
>>>> >>
>>>> >> EdB
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>> >>>
>>>> >>> > As a complete compiler noob, but can somebody answer this:
>>>> >>> >
>>>> >>> > Can we not build a 'mxmlcJS'? I understand that Falcon was
>>>> specifically
>>>> >>> > designed to have a 'variable backend' that allows for FalconJS to
>>>> be
>>>> >>> hooked
>>>> >>> > in. Is something like that feasible with the 'previous generation'
>>>> >>> > compiler(s)?
>>>> >>> >
>>>> >>> > The advantage would be that we have a fully fledged MXML/AS
>>>> compiler
>>>> that
>>>> >>> > works with the current framework, so no need to rewrite the
>>>> framework,
>>>> >>> nor
>>>> >>> > invest heavily in finishing the remaining 20% of the Falcon MXML
>>>> parsing
>>>> >>> > and finish FalconJS. We would 'only' have to rewrite the part of
>>>> the
>>>> >>> > compiler that currently outputs 'abc' and the browser side player
>>>> >>> > (HTML/CSS/JS) :-)
>>>> >>> >
>>>> >>> > Thoughts?
>>>> >>> >
>>>> >>> In theory, Falcon should also be faster. And, IMO, the code is
>>>> cleaner and
>>>> >>> has fewer SDK dependencies which will be to our advantage when trying
>>>> to
>>>> >>> get
>>>> >>> to other targets.
>>>> >>>
>>>> >>> -
>>>> >>> 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
>>>> >>
>>>> >
>>>> > --
>>>> > 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
>>
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: Current compiler question
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
Michael, (nothing to do with last discussion).
It's obvious that you have knowledge about the compiler so let me ask you
some things...
Aside from what's here (
https://cwiki.apache.org/confluence/display/FLEX/Falcon+Overview ) what
would you recommend to someone who is curious about the compiler
architecture? (thinking on the possibility of future contributions)
i.e.
Is the compiler built on top of another technology (aside from Java,
obviously) that I'd have to learn about?
Is Eclipse knowledge required (when you are not interested in the Eclipse
plugin)?
Any known design patterns (compiler specific) that should be known prior to
start looking at the compiler code / documentation?
Is the compiler 100% Java based or we need some C / C++ knowledge?
Thank you in advanced!
Cheers
On Sun, Nov 18, 2012 at 5:34 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> I don't quite understand what you are saying but, I have said 100 times I
> do not like the Flash Player in many threads, read it on my blog etc.
>
> What I said below means, I would bet on AS3 language for the time being
> NOT the SWF format. The compilers are lexers/parsers first and parse AS3,
> MXML and CSS into AST which from there we can do anything with, the ABC
> bytecode emitter is at the end of the chain and has nothing to do with what
> I want to fiddle with.
>
> So please do not think I want anything to do with the current or future
> Flash Player AVM, I don't.
>
> Mike
>
>
>
> Quoting Stefan Horochovec <st...@gmail.com>:
>
> I think a little differently, the only answer we have now is that we move
>> from dependence on runtime from Adobe. This lack of information and
>> changing business plans involving the VM is terrible for the future of
>> Apache Flex.
>>
>> Or are we an independent solution for RIA development, or we will live
>> forever in this situation.
>>
>> For me it is completely impractical to bet on a framework based on a VM
>> that who develops the framework, completely unaware of his future runtime.
>>
>> Regards
>>
>> Stefan Horochovec
>>
>>
>>
>> 2012/11/17 Hordur Thordarson <ho...@lausn.is>
>>
>> > The last two days proves that know one has any real answers to anything
>>> right now. The only way to get answers is the scientific method of limit
>>> your variables and test the crap out the ideas.
>>>
>>> Well said, I totally agree with this :-)
>>>
>>> On 17.11.2012, at 19:00, Michael Schmalle wrote:
>>>
>>> > Before I commit to anything that is in Haxe land or total rewriting
>>> etc,
>>> I am going to experiment with FalconAS, FalconJS and the MXML compiler
>>> for
>>> fun.
>>> >
>>> > To me as you just said, experimenting at the moment with something we
>>> have is going to be an experiment for me. Unless some chariot flies from
>>> the sky and lifts Apache Flex into the heavens, I think there is just
>>> going
>>> to be a lot of experimenting with all angles until some one starts
>>> actually
>>> making progress on something.
>>> >
>>> > The last two days proves that know one has any real answers to anything
>>> right now. The only way to get answers is the scientific method of limit
>>> your variables and test the crap out the ideas.
>>> >
>>> > Mike
>>> >
>>> >
>>> > Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>> >
>>> >> I understand and I agree. I was just reacting to an email by Gordon
>>> >> explaining that MXML 'coverage' in Falcon is at 80%, but that the last
>>> 20%
>>> >> will take many man-months to finish, something Gordon on his own is
>>> >> obviously not capable of contributing. And then there's FalconJS,
>>> which
>>> >> from the few things I was able to find with a little help from Google,
>>> is
>>> >> awesome, but only a research project. That means that it has the
>>> promise to
>>> >> be great, but also that it will require a lot of work to get done.
>>> >>
>>> >> Now, I'm not (very) impatient, so if you can only get into details
>>> after
>>> >> the donation clears, I understand, but meanwhile the conversation seem
>>> to
>>> >> be about re-writing this and using that, anything but what we actually
>>> have
>>> >> available at the moment. I was looking at our resources and thinking
>>> about
>>> >> alternatives… and thought we should consider this as an option, or at
>>> least
>>> >> discuss using what we have and know to work.
>>> >>
>>> >> EdB
>>> >>
>>> >>
>>> >>
>>> >> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>> >>>
>>> >>> > As a complete compiler noob, but can somebody answer this:
>>> >>> >
>>> >>> > Can we not build a 'mxmlcJS'? I understand that Falcon was
>>> specifically
>>> >>> > designed to have a 'variable backend' that allows for FalconJS to
>>> be
>>> >>> hooked
>>> >>> > in. Is something like that feasible with the 'previous generation'
>>> >>> > compiler(s)?
>>> >>> >
>>> >>> > The advantage would be that we have a fully fledged MXML/AS
>>> compiler
>>> that
>>> >>> > works with the current framework, so no need to rewrite the
>>> framework,
>>> >>> nor
>>> >>> > invest heavily in finishing the remaining 20% of the Falcon MXML
>>> parsing
>>> >>> > and finish FalconJS. We would 'only' have to rewrite the part of
>>> the
>>> >>> > compiler that currently outputs 'abc' and the browser side player
>>> >>> > (HTML/CSS/JS) :-)
>>> >>> >
>>> >>> > Thoughts?
>>> >>> >
>>> >>> In theory, Falcon should also be faster. And, IMO, the code is
>>> cleaner and
>>> >>> has fewer SDK dependencies which will be to our advantage when trying
>>> to
>>> >>> get
>>> >>> to other targets.
>>> >>>
>>> >>> -
>>> >>> 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
>>> >>
>>> >
>>> > --
>>> > 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
>
>
Re: Current compiler question
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I don't quite understand what you are saying but, I have said 100
times I do not like the Flash Player in many threads, read it on my
blog etc.
What I said below means, I would bet on AS3 language for the time
being NOT the SWF format. The compilers are lexers/parsers first and
parse AS3, MXML and CSS into AST which from there we can do anything
with, the ABC bytecode emitter is at the end of the chain and has
nothing to do with what I want to fiddle with.
So please do not think I want anything to do with the current or
future Flash Player AVM, I don't.
Mike
Quoting Stefan Horochovec <st...@gmail.com>:
> I think a little differently, the only answer we have now is that we move
> from dependence on runtime from Adobe. This lack of information and
> changing business plans involving the VM is terrible for the future of
> Apache Flex.
>
> Or are we an independent solution for RIA development, or we will live
> forever in this situation.
>
> For me it is completely impractical to bet on a framework based on a VM
> that who develops the framework, completely unaware of his future runtime.
>
> Regards
>
> Stefan Horochovec
>
>
>
> 2012/11/17 Hordur Thordarson <ho...@lausn.is>
>
>> > The last two days proves that know one has any real answers to anything
>> right now. The only way to get answers is the scientific method of limit
>> your variables and test the crap out the ideas.
>>
>> Well said, I totally agree with this :-)
>>
>> On 17.11.2012, at 19:00, Michael Schmalle wrote:
>>
>> > Before I commit to anything that is in Haxe land or total rewriting etc,
>> I am going to experiment with FalconAS, FalconJS and the MXML compiler for
>> fun.
>> >
>> > To me as you just said, experimenting at the moment with something we
>> have is going to be an experiment for me. Unless some chariot flies from
>> the sky and lifts Apache Flex into the heavens, I think there is just going
>> to be a lot of experimenting with all angles until some one starts actually
>> making progress on something.
>> >
>> > The last two days proves that know one has any real answers to anything
>> right now. The only way to get answers is the scientific method of limit
>> your variables and test the crap out the ideas.
>> >
>> > Mike
>> >
>> >
>> > Quoting Erik de Bruin <er...@ixsoftware.nl>:
>> >
>> >> I understand and I agree. I was just reacting to an email by Gordon
>> >> explaining that MXML 'coverage' in Falcon is at 80%, but that the last
>> 20%
>> >> will take many man-months to finish, something Gordon on his own is
>> >> obviously not capable of contributing. And then there's FalconJS, which
>> >> from the few things I was able to find with a little help from Google,
>> is
>> >> awesome, but only a research project. That means that it has the
>> promise to
>> >> be great, but also that it will require a lot of work to get done.
>> >>
>> >> Now, I'm not (very) impatient, so if you can only get into details after
>> >> the donation clears, I understand, but meanwhile the conversation seem
>> to
>> >> be about re-writing this and using that, anything but what we actually
>> have
>> >> available at the moment. I was looking at our resources and thinking
>> about
>> >> alternatives… and thought we should consider this as an option, or at
>> least
>> >> discuss using what we have and know to work.
>> >>
>> >> EdB
>> >>
>> >>
>> >>
>> >> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> >>>
>> >>> > As a complete compiler noob, but can somebody answer this:
>> >>> >
>> >>> > Can we not build a 'mxmlcJS'? I understand that Falcon was
>> specifically
>> >>> > designed to have a 'variable backend' that allows for FalconJS to be
>> >>> hooked
>> >>> > in. Is something like that feasible with the 'previous generation'
>> >>> > compiler(s)?
>> >>> >
>> >>> > The advantage would be that we have a fully fledged MXML/AS compiler
>> that
>> >>> > works with the current framework, so no need to rewrite the
>> framework,
>> >>> nor
>> >>> > invest heavily in finishing the remaining 20% of the Falcon MXML
>> parsing
>> >>> > and finish FalconJS. We would 'only' have to rewrite the part of the
>> >>> > compiler that currently outputs 'abc' and the browser side player
>> >>> > (HTML/CSS/JS) :-)
>> >>> >
>> >>> > Thoughts?
>> >>> >
>> >>> In theory, Falcon should also be faster. And, IMO, the code is
>> cleaner and
>> >>> has fewer SDK dependencies which will be to our advantage when trying
>> to
>> >>> get
>> >>> to other targets.
>> >>>
>> >>> -
>> >>> 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
>> >>
>> >
>> > --
>> > 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
Re: Current compiler question
Posted by Stefan Horochovec <st...@gmail.com>.
I think a little differently, the only answer we have now is that we move
from dependence on runtime from Adobe. This lack of information and
changing business plans involving the VM is terrible for the future of
Apache Flex.
Or are we an independent solution for RIA development, or we will live
forever in this situation.
For me it is completely impractical to bet on a framework based on a VM
that who develops the framework, completely unaware of his future runtime.
Regards
Stefan Horochovec
2012/11/17 Hordur Thordarson <ho...@lausn.is>
> > The last two days proves that know one has any real answers to anything
> right now. The only way to get answers is the scientific method of limit
> your variables and test the crap out the ideas.
>
> Well said, I totally agree with this :-)
>
> On 17.11.2012, at 19:00, Michael Schmalle wrote:
>
> > Before I commit to anything that is in Haxe land or total rewriting etc,
> I am going to experiment with FalconAS, FalconJS and the MXML compiler for
> fun.
> >
> > To me as you just said, experimenting at the moment with something we
> have is going to be an experiment for me. Unless some chariot flies from
> the sky and lifts Apache Flex into the heavens, I think there is just going
> to be a lot of experimenting with all angles until some one starts actually
> making progress on something.
> >
> > The last two days proves that know one has any real answers to anything
> right now. The only way to get answers is the scientific method of limit
> your variables and test the crap out the ideas.
> >
> > Mike
> >
> >
> > Quoting Erik de Bruin <er...@ixsoftware.nl>:
> >
> >> I understand and I agree. I was just reacting to an email by Gordon
> >> explaining that MXML 'coverage' in Falcon is at 80%, but that the last
> 20%
> >> will take many man-months to finish, something Gordon on his own is
> >> obviously not capable of contributing. And then there's FalconJS, which
> >> from the few things I was able to find with a little help from Google,
> is
> >> awesome, but only a research project. That means that it has the
> promise to
> >> be great, but also that it will require a lot of work to get done.
> >>
> >> Now, I'm not (very) impatient, so if you can only get into details after
> >> the donation clears, I understand, but meanwhile the conversation seem
> to
> >> be about re-writing this and using that, anything but what we actually
> have
> >> available at the moment. I was looking at our resources and thinking
> about
> >> alternatives… and thought we should consider this as an option, or at
> least
> >> discuss using what we have and know to work.
> >>
> >> EdB
> >>
> >>
> >>
> >> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>>
> >>>
> >>>
> >>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>>
> >>> > As a complete compiler noob, but can somebody answer this:
> >>> >
> >>> > Can we not build a 'mxmlcJS'? I understand that Falcon was
> specifically
> >>> > designed to have a 'variable backend' that allows for FalconJS to be
> >>> hooked
> >>> > in. Is something like that feasible with the 'previous generation'
> >>> > compiler(s)?
> >>> >
> >>> > The advantage would be that we have a fully fledged MXML/AS compiler
> that
> >>> > works with the current framework, so no need to rewrite the
> framework,
> >>> nor
> >>> > invest heavily in finishing the remaining 20% of the Falcon MXML
> parsing
> >>> > and finish FalconJS. We would 'only' have to rewrite the part of the
> >>> > compiler that currently outputs 'abc' and the browser side player
> >>> > (HTML/CSS/JS) :-)
> >>> >
> >>> > Thoughts?
> >>> >
> >>> In theory, Falcon should also be faster. And, IMO, the code is
> cleaner and
> >>> has fewer SDK dependencies which will be to our advantage when trying
> to
> >>> get
> >>> to other targets.
> >>>
> >>> -
> >>> 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
> >>
> >
> > --
> > Michael Schmalle - Teoti Graphix, LLC
> > http://www.teotigraphix.com
> > http://blog.teotigraphix.com
> >
>
>
Re: Current compiler question
Posted by Hordur Thordarson <ho...@lausn.is>.
> The last two days proves that know one has any real answers to anything right now. The only way to get answers is the scientific method of limit your variables and test the crap out the ideas.
Well said, I totally agree with this :-)
On 17.11.2012, at 19:00, Michael Schmalle wrote:
> Before I commit to anything that is in Haxe land or total rewriting etc, I am going to experiment with FalconAS, FalconJS and the MXML compiler for fun.
>
> To me as you just said, experimenting at the moment with something we have is going to be an experiment for me. Unless some chariot flies from the sky and lifts Apache Flex into the heavens, I think there is just going to be a lot of experimenting with all angles until some one starts actually making progress on something.
>
> The last two days proves that know one has any real answers to anything right now. The only way to get answers is the scientific method of limit your variables and test the crap out the ideas.
>
> Mike
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> I understand and I agree. I was just reacting to an email by Gordon
>> explaining that MXML 'coverage' in Falcon is at 80%, but that the last 20%
>> will take many man-months to finish, something Gordon on his own is
>> obviously not capable of contributing. And then there's FalconJS, which
>> from the few things I was able to find with a little help from Google, is
>> awesome, but only a research project. That means that it has the promise to
>> be great, but also that it will require a lot of work to get done.
>>
>> Now, I'm not (very) impatient, so if you can only get into details after
>> the donation clears, I understand, but meanwhile the conversation seem to
>> be about re-writing this and using that, anything but what we actually have
>> available at the moment. I was looking at our resources and thinking about
>> alternatives… and thought we should consider this as an option, or at least
>> discuss using what we have and know to work.
>>
>> EdB
>>
>>
>>
>> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>>
>>>
>>>
>>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>> > As a complete compiler noob, but can somebody answer this:
>>> >
>>> > Can we not build a 'mxmlcJS'? I understand that Falcon was specifically
>>> > designed to have a 'variable backend' that allows for FalconJS to be
>>> hooked
>>> > in. Is something like that feasible with the 'previous generation'
>>> > compiler(s)?
>>> >
>>> > The advantage would be that we have a fully fledged MXML/AS compiler that
>>> > works with the current framework, so no need to rewrite the framework,
>>> nor
>>> > invest heavily in finishing the remaining 20% of the Falcon MXML parsing
>>> > and finish FalconJS. We would 'only' have to rewrite the part of the
>>> > compiler that currently outputs 'abc' and the browser side player
>>> > (HTML/CSS/JS) :-)
>>> >
>>> > Thoughts?
>>> >
>>> In theory, Falcon should also be faster. And, IMO, the code is cleaner and
>>> has fewer SDK dependencies which will be to our advantage when trying to
>>> get
>>> to other targets.
>>>
>>> -
>>> 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
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
Re: Current compiler question
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Before I commit to anything that is in Haxe land or total rewriting
etc, I am going to experiment with FalconAS, FalconJS and the MXML
compiler for fun.
To me as you just said, experimenting at the moment with something we
have is going to be an experiment for me. Unless some chariot flies
from the sky and lifts Apache Flex into the heavens, I think there is
just going to be a lot of experimenting with all angles until some one
starts actually making progress on something.
The last two days proves that know one has any real answers to
anything right now. The only way to get answers is the scientific
method of limit your variables and test the crap out the ideas.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> I understand and I agree. I was just reacting to an email by Gordon
> explaining that MXML 'coverage' in Falcon is at 80%, but that the last 20%
> will take many man-months to finish, something Gordon on his own is
> obviously not capable of contributing. And then there's FalconJS, which
> from the few things I was able to find with a little help from Google, is
> awesome, but only a research project. That means that it has the promise to
> be great, but also that it will require a lot of work to get done.
>
> Now, I'm not (very) impatient, so if you can only get into details after
> the donation clears, I understand, but meanwhile the conversation seem to
> be about re-writing this and using that, anything but what we actually have
> available at the moment. I was looking at our resources and thinking about
> alternatives… and thought we should consider this as an option, or at least
> discuss using what we have and know to work.
>
> EdB
>
>
>
> On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> > As a complete compiler noob, but can somebody answer this:
>> >
>> > Can we not build a 'mxmlcJS'? I understand that Falcon was specifically
>> > designed to have a 'variable backend' that allows for FalconJS to be
>> hooked
>> > in. Is something like that feasible with the 'previous generation'
>> > compiler(s)?
>> >
>> > The advantage would be that we have a fully fledged MXML/AS compiler that
>> > works with the current framework, so no need to rewrite the framework,
>> nor
>> > invest heavily in finishing the remaining 20% of the Falcon MXML parsing
>> > and finish FalconJS. We would 'only' have to rewrite the part of the
>> > compiler that currently outputs 'abc' and the browser side player
>> > (HTML/CSS/JS) :-)
>> >
>> > Thoughts?
>> >
>> In theory, Falcon should also be faster. And, IMO, the code is cleaner and
>> has fewer SDK dependencies which will be to our advantage when trying to
>> get
>> to other targets.
>>
>> -
>> 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
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: Current compiler question
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I understand and I agree. I was just reacting to an email by Gordon
explaining that MXML 'coverage' in Falcon is at 80%, but that the last 20%
will take many man-months to finish, something Gordon on his own is
obviously not capable of contributing. And then there's FalconJS, which
from the few things I was able to find with a little help from Google, is
awesome, but only a research project. That means that it has the promise to
be great, but also that it will require a lot of work to get done.
Now, I'm not (very) impatient, so if you can only get into details after
the donation clears, I understand, but meanwhile the conversation seem to
be about re-writing this and using that, anything but what we actually have
available at the moment. I was looking at our resources and thinking about
alternatives… and thought we should consider this as an option, or at least
discuss using what we have and know to work.
EdB
On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> > As a complete compiler noob, but can somebody answer this:
> >
> > Can we not build a 'mxmlcJS'? I understand that Falcon was specifically
> > designed to have a 'variable backend' that allows for FalconJS to be
> hooked
> > in. Is something like that feasible with the 'previous generation'
> > compiler(s)?
> >
> > The advantage would be that we have a fully fledged MXML/AS compiler that
> > works with the current framework, so no need to rewrite the framework,
> nor
> > invest heavily in finishing the remaining 20% of the Falcon MXML parsing
> > and finish FalconJS. We would 'only' have to rewrite the part of the
> > compiler that currently outputs 'abc' and the browser side player
> > (HTML/CSS/JS) :-)
> >
> > Thoughts?
> >
> In theory, Falcon should also be faster. And, IMO, the code is cleaner and
> has fewer SDK dependencies which will be to our advantage when trying to
> get
> to other targets.
>
> -
> 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
Re: Current compiler question
Posted by Alex Harui <ah...@adobe.com>.
On 11/17/12 4:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> As a complete compiler noob, but can somebody answer this:
>
> Can we not build a 'mxmlcJS'? I understand that Falcon was specifically
> designed to have a 'variable backend' that allows for FalconJS to be hooked
> in. Is something like that feasible with the 'previous generation'
> compiler(s)?
>
> The advantage would be that we have a fully fledged MXML/AS compiler that
> works with the current framework, so no need to rewrite the framework, nor
> invest heavily in finishing the remaining 20% of the Falcon MXML parsing
> and finish FalconJS. We would 'only' have to rewrite the part of the
> compiler that currently outputs 'abc' and the browser side player
> (HTML/CSS/JS) :-)
>
> Thoughts?
>
In theory, Falcon should also be faster. And, IMO, the code is cleaner and
has fewer SDK dependencies which will be to our advantage when trying to get
to other targets.
-
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui