CEDET

[CEDET-devel] One more patch for Java SRecode templating From: Vladimir Kazanov <vkazanov@in...> - 2013-01-30 12:48 Attachments: Message as HTML      etc-srecode-java-srt.patch

Re: [CEDET-devel] One more patch for Java SRecode templating From: Eric M. Ludlam <eric@si...> - 2013-01-31 02:02 On 01/30/2013 07:48 AM, Vladimir Kazanov wrote: > Hi all! > > Here goes another small patch for your consideration. It a) fixes a > banal typo in a neighbouring template, b) adds another template for > filling in an empty java file. The latter differs from a template > already available in only one way - it includes the static "main" > method, which can be quite handy in cases where one has to write a small > utility program, which happens to be a usual case for me and many of my > coworkers. Thanks. This seems like a fine change, so I checked it in. > Apart from that, I checked current Java grammars, looking for ways to > fix known bugs and TODOs, and have a question. There are two grammars > currently: java-tags and java. What is the difference between these two? > Is there a serious reason to use java-tags.el instead of java.el? java-tags is a tagging grammar for Java. The java parser parses everything, including all the code within methods, etc for Java. They both produce the roughly the same tag tables. The java parser has a couple features absent from the tagging parser. The tagging parser is faster than the full parser, and more robust to coding errors than the full parser due to the way the iterative parser works. They are the first parsers David Ponce wrote when he implemented the wisent parser, and the full parser was part of the process of getting the tagging parser system working. Eric

Re: [CEDET-devel] One more patch for Java SRecode templating From: Vladimir Kazanov <vkazanov@in...> - 2013-01-31 18:46 Attachments: Message as HTML      On Thu, Jan 31, 2013 at 9:02 AM, Eric M. Ludlam <eric@...: > On 01/30/2013 07:48 AM, Vladimir Kazanov wrote: > >> Hi all! >> >> Here goes another small patch for your consideration. It a) fixes a >> banal typo in a neighbouring template, b) adds another template for >> filling in an empty java file. The latter differs from a template >> already available in only one way - it includes the static "main" >> method, which can be quite handy in cases where one has to write a small >> utility program, which happens to be a usual case for me and many of my >> coworkers. >> > > Thanks. This seems like a fine change, so I checked it in. > > > Apart from that, I checked current Java grammars, looking for ways to >> fix known bugs and TODOs, and have a question. There are two grammars >> currently: java-tags and java. What is the difference between these two? >> Is there a serious reason to use java-tags.el instead of java.el? >> > > java-tags is a tagging grammar for Java. The java parser parses > everything, including all the code within methods, etc for Java. They both > produce the roughly the same tag tables. The java parser has a couple > features absent from the tagging parser. The tagging parser is faster than > the full parser, and more robust to coding errors than the full parser due > to the way the iterative parser works. > > They are the first parsers David Ponce wrote when he implemented the > wisent parser, and the full parser was part of the process of getting the > tagging parser system working. > > Eric > > Hm. Right now I am studying the iterative grammar, and trying to get to know wisent better along the way. Should I switch to the tagging grammar and improve it instead? What was the big plan on the topic? -- Yours sincerely, Vladimir Kazanov -- С уважением, Владимир Казанов

Re: [CEDET-devel] One more patch for Java SRecode templating From: Eric M. Ludlam <eric@si...> - 2013-02-01 01:32 On 01/31/2013 01:46 PM, Vladimir Kazanov wrote: > > Hm. Right now I am studying the iterative grammar, and trying to get to > know wisent better along the way. Should I switch to the tagging grammar > and improve it instead? What was the big plan on the topic? There is no big plan. I'm not familiar with the improvements your propose to guess which is best. To have the broadest effect, changes should be made to the tagging grammar. If you change some output however, you would also need to update the full grammar to keep them in sync. The full grammar is useful to update if you have some tool that wants to operate on the code or methods for some reason. The full grammar also supports some Java feature I don't recall (generics?). Thus improvements in support there would have to go into that grammar, unless the whole feature were ported over to the tagging grammar. Does that help? Eric

Re: [CEDET-devel] One more patch for Java SRecode templating From: Vladimir Kazanov <vkazanov@in...> - 2013-02-01 09:44 Attachments: semantic-wisent-java.patch      On Fri, Feb 1, 2013 at 8:32 AM, Eric M. Ludlam <eric@...> wrote: > > On 01/31/2013 01:46 PM, Vladimir Kazanov wrote: >> >> >> Hm. Right now I am studying the iterative grammar, and trying to get to >> know wisent better along the way. Should I switch to the tagging grammar >> and improve it instead? What was the big plan on the topic? > > > There is no big plan. I'm not familiar with the improvements your propose to guess which is best. > > To have the broadest effect, changes should be made to the tagging grammar. If you change some output however, you would also need to update the full grammar to keep them in sync. > > The full grammar is useful to update if you have some tool that wants to operate on the code or methods for some reason. The full grammar also supports some Java feature I don't recall (generics?). Thus improvements in support there would have to go into that grammar, unless the whole feature were ported over to the tagging grammar. > > Does that help? > Eric > Okay, I got the point. By the way, I have solved that issue with tag generation. The whole point was that "block_statement" just nilled all results from "statement". Thanks! I am trying to get variables from "for" and "foreach" states into local scope: for (String iWantThisToBeSeen: args) { iWant_ // should autocomplete with iWantThisToBeSeen } Anyway, after getting a bit deeper into java.wy, I realized why that block had to be skipped and tried a different approach: add "statement" itself as one of the start productions and extend semantic-get-local-variables in wisent/java.el to get that var into business. The patch is in the attachment. Could you take a look, Eric? Does that look acceptable? Note, that this is a dirty proof-of-concept patch, definitely not for inclusion. I also plan to get into that unit test system of CEDET and write all the tests required to cover the case. -- Yours sincerely, Vladimir Kazanov -- С уважением, Владимир Казанов

Re: [CEDET-devel] One more patch for Java SRecode templating From: Eric M. Ludlam <eric@si...> - 2013-02-05 02:46 On 02/01/2013 04:43 AM, Vladimir Kazanov wrote: > On Fri, Feb 1, 2013 at 8:32 AM, Eric M. Ludlam<eric@...> wrote: >> >> On 01/31/2013 01:46 PM, Vladimir Kazanov wrote: >>> >>> >>> Hm. Right now I am studying the iterative grammar, and trying to get to >>> know wisent better along the way. Should I switch to the tagging grammar >>> and improve it instead? What was the big plan on the topic? >> >> >> There is no big plan. I'm not familiar with the improvements your propose to guess which is best. >> >> To have the broadest effect, changes should be made to the tagging grammar. If you change some output however, you would also need to update the full grammar to keep them in sync. >> >> The full grammar is useful to update if you have some tool that wants to operate on the code or methods for some reason. The full grammar also supports some Java feature I don't recall (generics?). Thus improvements in support there would have to go into that grammar, unless the whole feature were ported over to the tagging grammar. >> >> Does that help? >> Eric >> > > Okay, I got the point. > > By the way, I have solved that issue with tag generation. The whole > point was that "block_statement" just nilled all results from > "statement". Thanks! > > I am trying to get variables from "for" and "foreach" states into local scope: > > for (String iWantThisToBeSeen: args) { > iWant_ // should autocomplete with iWantThisToBeSeen > } > > Anyway, after getting a bit deeper into java.wy, I realized why that > block had to be skipped and tried a different approach: add > "statement" itself as one of the start productions and extend > semantic-get-local-variables in wisent/java.el to get that var into > business. The patch is in the attachment. Could you take a look, Eric? > Does that look acceptable? Note, that this is a dirty proof-of-concept > patch, definitely not for inclusion. I also plan to get into that unit > test system of CEDET and write all the tests required to cover the > case. Your patch is a bit puzzling for me. On one side, it seems wrong since there should be a nice arrangements between contexts and what gets parsed, except that the for loop is outside said context. I can't think of a better way to do it off the top of my head. Seems like a reasonable idea. It could probably be used for C too. Local variable parsing has always been a bit of a hack, particularly since it wanders through your code backward. It would be nice to fix that someday. Eric

1 message has been excluded from this view by a project administrator.