flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: Falcon and Antlr4
Date Tue, 22 Jul 2014 15:23:19 GMT
Interesting.  I did not know that Jburg used Antlr.

Another option is to remove Jburg as well and see if a simple AST walk
like FalconJX uses is faster or not.  I know for sure it would be easier
to understand.

Also, IIRC, there compile-time dependencies and run-time dependencies.
Jburg is not used at run-time, IIRC. Would it totally defeat your goals to
use Antlr2 for Jburg during the build?


On 7/22/14 5:01 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Ok ... so it seems that in order to procede here, I have to get in touch
>with the JBurg guys.
>Currently JBurg is linked against Antlr2 and 3 but is incompatable with
>Antlr4. So in order to safely use JBurg as code generator, I would have
>to update JBurg to support Antlr4 :-(
>The project doesn't look that complex, but I think I should concentrate
>on Flexmojos falcon support first :-(
>Von: Christofer Dutz <christofer.dutz@c-ware.de>
>Gesendet: Dienstag, 22. Juli 2014 10:06
>An: dev@flex.apache.org
>Betreff: AW: AW: Falcon and Antlr4
>Ok ... so I created a "falcon-antlr4" branch (Haven't comitted/pushed
>that yet so don't look for it yet ;-) ).
>I am now trying to setup the compiler modules structure as a native maven
>project and will try to get everything up and running with Antlr4
>One thing I did notice is that the parsers seem to consist of some Antlr
>grammar files as well as JFlex .lex files. Is it possible that both are
>actually doing the same thing?
>You said in a previous post that JFlex was used to make the Eclipse
>suppot more responsive, but if it is only used for that I would like to
>concentrate an an Anltr4 based parser and throwing out the JFlex stuff
>making Eclipse use the Antlr4 parser instead after finishing the parser
>itself ... would that be a valid approach?
>In recent projects I have had a lot of trouble and strange effects when
>not using the standard maven directory layout because some third party
>tools make assumptions that might not apply in non-maven-structures. On
>the other hand making an Ant buildscript run with a maven directory
>strucure is as easy as adjusting a few paths. So I would go that path
>instead. Would that be ok for you?
>Currently this would result in the sources being placed in:
>src/main/java (Java Sources)
>src/main/antlr4 (Antlr Grammar Files)
>src/main/resources (Static Resources such as i18n property files, and
>other static stuff)
>After reading the source, the ant build script and a lot of googling at
>least I think I now know how to approach this task and I think I's
>absolutely manageable ... really looking forward to this.
>Von: Gordon Smith <gsmithsf@hotmail.com>
>Gesendet: Donnerstag, 17. Juli 2014 17:11
>An: dev@flex.apache.org
>Betreff: Re: AW: Falcon and Antlr4
>> why are we mixing up several tools that all seem to be doing similar
>Falcon's lexer and parser were borrowed from the Flash Builder code base,
>where they supported various edit-time code intelligence features, but
>not compilation. I think the Flash Builder team had determined that JFlex
>could tokenize faster than Antlr 2 could. But I don't know whether that
>is still the case with Antlr 3 and 4.
>- Gordon
>Sent from my iPad
>> On Jul 16, 2014, at 3:14 PM, "Christofer Dutz"
>><christofer.dutz@c-ware.de> wrote:
>> Ok so that would have been my second question ... why are we mixing up
>>several tools that all seem to be doing similar things :-)
>> I definitely like to do some cleaning up. But depending on if any or
>>which talks are accepter for the ApacheCon I might have to finish some
>>other things first ;-)
>> Chris
>> PS: Will be offline for a few days ...
>> -----Urspr√ľngliche Nachricht-----
>> Von: Gordon Smith [mailto:gsmithsf@hotmail.com]
>> Gesendet: Mittwoch, 16. Juli 2014 17:19
>> An: dev@flex.apache.org
>> Betreff: Re: Falcon and Antlr4
>> You might also want to look into eliminating JFlex and have Antlr
>>handle tokenization as well.
>> - Gordon
>> Sent from my iPad
>>> On Jul 16, 2014, at 8:06 AM, "Alex Harui" <aharui@adobe.com> wrote:
>>> Good luck.  I'm interested in anything that would speed up Falcon.
>>> Please work in a branch.
>>>> On 7/16/14 2:44 AM, "Christofer Dutz" <christofer.dutz@c-ware.de>
>>>> Hi,
>>>> while I was havin a first look at the internals of Falcon, I was
>>>> surprized to find a mixture of Antlr2 & Antlr3 grammars for creating
>>>> the parsers.
>>>> In a first moment I thought it would be a good idea to migrate the
>>>> Antlr2 grammars ASParser.g and MetadataParser.g to Antlr3 but after
>>>> finding out that IntelliJ now has a neat Antlr4 plugin and reading a
>>>> bit about the differences from 2 and 3 to 4 it sounded like a good
>>>> idea to migrate all to Antlr4. To me it looks as if the way things
>>>> are processed in Antlr4 would make the grammars a lot easier as well
>>>> as implementing the rule logic. My gut-feeling tells me that an
>>>> Antlr4 parser should need less processing and be quite a bit faster.
>>>> I did experiment a little on the CSS grammar and successfully created
>>>> an Antlr4 version of that ... so I guess it should be possible and it
>>>> would clean up things quite dramatically.
>>>> What I particularly liked, was that Antlr4 automatically generates a
>>>> Listener interface for any rule it finds generating an
>>>> and "exit{rulename}" as well as a base-class implementing this
>>>> Now all of the java code we had to enter in the rule-document can now
>>>> be defined in a FalconCssListener class that extends this
>>>> This is where the Java code can be added to handle the rules and we
>>>> can easily debug it (I know you could set breakpoints in the
>>>> generated code, but I allways disliked that).
>>>> What do you think? ... Would it be a good idea to give something like
>>>> that a try? After all ... it's just 3 grammars (CSS, ASParser and
>>>> MetadataParser). But I have to admit that the ASParser grammar looks
>>>> way more complex than the CSS and the MetadataParser grammar.
>>>> Chris

View raw message