Hey Mario Yes, i am from Hong Kong. Why come here? Business trip? Thanks >From Peter ________________________________ From: Mario Schroeder <ma.schroe...@gmail.com> Sent: Thursday, October 10, 2019 3:48 PM To: dev@netbeans.apache.org <dev@netbeans.apache.org> Subject: Re: Can anyone give me a help about developing antlr formatter
Peter, you are from Hong Kong?! What a coincidence that I will be there within a week. Despite all the issues, I'm looking forward. Sorry for the off topic. Am Do., 10. Okt. 2019 um 08:35 Uhr schrieb Peter Cheung < mcheun...@hotmail.com>: > Dear Tim > You are a great people and full of passion. In my home town (Hong > Kong), people just "use" open source, not contributing it. > Thanks > From Peter > ________________________________ > From: Tim Boudreau <niftin...@gmail.com> > Sent: Wednesday, October 9, 2019 1:42 PM > To: dev@netbeans.apache.org <dev@netbeans.apache.org> > Subject: Re: Can anyone give me a help about developing antlr formatter > > Okay. If you'd like to try some stuff, I could hook you up with some > modules. Antlr support - syntax highlighting, navigator panels, syntax > tree views, has been working for a while; formatting is pretty solid now. > I've spent the last week stabilizing the "live preview" functionality, > which actually generates NetBeans language support with syntax highlighting > for *the grammar you are currently editing* - so you can have a syntax > highlighted preview, and associate a file extension with that grammar and > open those files and interact with them with full IDE support that is > updated whenever you edit the grammar. > > Basically the PITA with developing Antlr grammars is when you break some > rule that worked, change a whole bunch of other stuff before you know you > broke it, and then have to figure out which thing you did caused the > problem. So being able to visually, and instantly, see if something is > broken seems like a basic thing that's needed to make grammar development > much less painful. > > Here's a screen shot: > https://timboudreau.com/files/screen/10-09-2019_01-39-44.png > > All that gets a bit complex: > > - User edits the grammar file > - Listener on the grammar file notices and tells highlighters of documents > in the language of that grammar to request a reparse > - They ask for a new parse from a parser which > - Is actually going to run code in an isolated classloader that loads > from an in-memory filesystem where the grammar and generated analyzer code > was compiled > - Notices that the grammar file - whose document is mapped into that > in-memory filesystem - has changed > - Initiates a new run of Antlr generating parser and lexer > - Compiles them into that memory filesystem > - Generates the source for a thing that will call that parser with > document contents, and retrieve the tokens, parse tree, etc. copied into > proxy objects so the classloader does not leak types > - Creates a new isolated classloader over the class output for all that > - Replaces that classloader in the proxy parser > - Passes the document text into that parser, extracts the proxied parse > tree and wraps that in a NetBeans Parser.Result > > The good news is all that can happen in < 100ms. It works, but I've been > chasing bugs in the choreography of that process to ensure the new parse > runs against the right version of the grammar - each layer of that will use > the previous result if nothing has changed but the input text, and it works > out to being a big chain of lists of weakly referenced susbscribers to > things that subscribe to other things (i.e. the parser subscribes to > replacement of the classloader environment; the highlighters subscribe to > changes on the parser). > > It requires a few hacks that will probably get turned into patches - > there's no way via API to get the cache for Source objects for the > in-language document to invalidate its cached parser results because *some > other document* changed, so that has to be done via reflection; and > similarly, there is no direct way to force a Language instance to be > discarded by its LanguageHierarchy, but if you don't, it will keep a cache > of token ids that will be completely wrong (particularly if the grammar is > unparseable and you get a lexer with a dummy set of token ids with one > token, flip back to a valid language, and back again, which is the normal > state of life in an IDE). > > But for basic doing-stuff-with-Antlr it's in decent shape, and it's all > factored into many separate modules, so perhaps I could get some out there. > > -Tim > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 2:08 AM Peter Cheung <mcheun...@hotmail.com> wrote: > > > Dear Tim > > Sorry i am doing my own antlr plugin > > https://gitlab.com/mcheung63/netbeans-antlr to support my compiler > > development which using antlr. If you plugin can well format antlr, then > i > > can focus my compiler rather than antlr in netbeans. > > thanks > > Peter > > > > > > -- > http://timboudreau.com >
