incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: Current compiler question
Date Sun, 18 Nov 2012 17:42:01 GMT
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 <apache@teotigraphix.com>:

> Quoting Joan Llenas Masó <joan@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
>> <apache@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 <stefan.horochovec@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 <hordur@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 <erik@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 <aharui@adobe.com>
wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/17/12 4:47 AM, "Erik de Bruin" <erik@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


Mime
View raw message