I'm available to help out with the 'grunt' work. Writing tests, doing repetitive stuff etc. I'm not familiar with the inner workings of a real compiler, though I have done 'some' work on FalconJX. I'm willing to learn though!
EdB On Thu, Jul 17, 2014 at 12:14 AM, 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 > > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
