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? -Alex On 7/22/14 5:01 AM, "Christofer Dutz" <christofer.d...@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 :-( > >Chris > >________________________________________ >Von: Christofer Dutz <christofer.d...@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. > >Chris > > >________________________________________ >Von: Gordon Smith <gsmit...@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 >>thing > >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.d...@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:gsmit...@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" <aha...@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.d...@c-ware.de> >>>>wrote: >>>> >>>> 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 >>>>"enter{ruleneme}" >>>> and "exit{rulename}" as well as a base-class implementing this >>>>interface. >>>> 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 >>>>CSSBaseListener. >>>> 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 >>>
