[antlr-interest] antlr-interest Digest, Vol 82, Issue 22

mandanna thekkada mandanna.thekkada at gmail.com
Tue Sep 27 10:27:48 PDT 2011


Hello Terence,

I am trying to make to C grammar work as an android project. I've created
the C target , but when building I've obtained most of the libraries from
the FishEye source website as mentioned in the downloads page of
antlr.orgexcept for "antlrconfig.h" . Any ideas on how to fix this??

Regards,
Mandanna

On Tue, Sep 27, 2011 at 8:10 PM, <antlr-interest-request at antlr.org> wrote:

> Send antlr-interest mailing list submissions to
>        antlr-interest at antlr.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://www.antlr.org/mailman/listinfo/antlr-interest
> or, via email, send a message with subject or body 'help' to
>        antlr-interest-request at antlr.org
>
> You can reach the person managing the list at
>        antlr-interest-owner at antlr.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of antlr-interest digest..."
>
>
> Today's Topics:
>
>   1. changes not reflecting in antlrWorks debugger (jame vaalet)
>   2. Re: ANTLRWorks 1.4.3: XYZParser.java:14: code too large
>      (public static final String[] tokenNames = new String[]   { ... } ;
>      ) (Vlad)
>   3. Re: ANTLRWorks 1.4.3: XYZParser.java:14: code too large
>      (public static final String[] tokenNames = new String[] { ... } ;
>      ) (Sam Barnett-Cormack)
>   4. Re: ANTLRWorks 1.4.3: XYZParser.java:14: code too large
>      (public static final String[] tokenNames = new String[] { ... } ;
>      ) (Udo Weik)
>   5. Re: [stringtemplate-interest] a logo design?      branding.
>      (Terence Parr)
>   6. Re: Fwd: ANTLRWorks bug: Remove Left Recursion with comments
>      in grammar (Kevin J. Cummings)
>   7. Re: Fwd: ANTLRWorks bug: Remove Left Recursion with comments
>      in grammar (Gary Miller)
>   8. Best practices to insert breakpoint when  generating code?
>      (Chan David)
>   9. [C] code to change Token type, use char* and loose data when
>      buffer destroyed (Ruslan Zasukhin)
>  10. Re: Fwd: ANTLRWorks bug: Remove Left Recursion with comments
>      in grammar (The Researcher)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 27 Sep 2011 00:32:43 +0530
> From: jame vaalet <jamevaalet at gmail.com>
> Subject: [antlr-interest] changes not reflecting in antlrWorks
>        debugger
> To: antlr-interest at antlr.org
> Message-ID:
>        <CAHGxz8a_WBT3xX2xdSvKu8BrS+hJOUp-tX6Yr_2-_dMaxetLWg at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> hi,
>  am using antlrWorks 1.4.3 with csharp2 as target language. but when i
> debug
> its using the old grammar.g rather than the latest grammar.g .
> can someone help me out in here  ??
>
> --
>
> -JAME
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Sep 2011 15:36:41 -0400
> From: Vlad <vlad at demoninsight.com>
> Subject: Re: [antlr-interest] ANTLRWorks 1.4.3: XYZParser.java:14:
>        code too        large (public static final String[] tokenNames = new
> String[]
>        { ... } ; )
> To: Udo Weik <WeikEngOff at aol.com>
> Cc: "Antlr-Interest Antlr.Org" <antlr-interest at antlr.org>
> Message-ID: <D7BA9C8E-F8A3-40E7-8C8E-0D57CE1FFC19 at demoninsight.com>
> Content-Type: text/plain; charset=us-ascii
>
> Java .class file format has a specification limit such that any bytecode
> method must not be more than 64k bytes. If this limit is violated (normally
> only happens with auto-generated code) you'll see the compiler error you
> have.
>
> Although it is not very common knowledge, any java code of the form
>
> ... static final SomeType SOME_FIELD = <some exp>
>
> is equivalent to the following:
>
> a declaration of
>
> ... static final SomeType SOME_FIELD;
>
> combined with bytecode to compute <some exp> and assign it to SOME_FIELD,
> performed inside a special method named '<clinit>' at class loading time. It
> is the same method that also collects anything you put in a static { }
> block. I had a look at the .java files you see generated from your grammer
> and there is absolutely a ton of public static finals that require such
> <clinit> code: some 1300 FOLLOW_... BitSets, tokenNames, ruleNames, etc.
>
> All of those static field init bytecodes end up in <clinit> and cause size
> overflow. It seems to me that hitting the 64K limit can happen for any
> reasonably large grammar ("large" defined not just in terms of token count,
> but also the number of rules, etc).
>
> To address this issue at the fundamental level, ANTLR need to alter its
> .java code emission strategy. Perhaps map rules to static methods of static
> nested classes instead of lumping everything into a single .class
> definition. Nested classes in Java are compiled into separate .class
> definitions, each with it own <clinit>.
>
> HTH,
> Vlad
>
> On Sep 26, 2011, at 1:06 PM, Udo Weik wrote:
>
> > Hello Terence,
> >
> >> Interesting. That's not that big.Only 162 strings should not merely be
> enough to blow out the 64k  static INIT method limit. hmm... perhaps the
> other arrays are the big as well.
> >> ter
> >
> > I just tried to delete 'static' but of course that doesn't work:
> > XYZParser.java:347: non-static variable tokenNames cannot be referenced
> from a static context
> > So the question is - any solution for that problem?
> >
> > Thanks and greetings
> > Udo
> >
> >
> >> On Sep 26, 2011, at 8:42 AM, Udo Weik wrote:
> >>
> >>> Hello Terence,
> >>>
> >>>> wow! how big is that grammar?
> >>>> Ter
> >>>
> >>> I'm trying to get the VHDL-grammar for the CSharp-target from
> >>> Mike Lodder working with Java:
> >>> http://www.antlr.org/grammar/1202750770887/vhdl.g
> >>>
> >>> Some first, very basic modifications see attachement.
> >>> First of all that grammar should work with ANTLRWorks 1.4.3.
> >>>
> >>> Many thanks for any support
> >>> Udo
> >>>
> >>>
> >>>> On Sep 26, 2011, at 6:50 AM, Udo Weik wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> the length of that line is 1647 chars (162 strings).
> >>>>> The grammar is an existing one. What can/must I do?
> >>>>>
> >>>>> [15:41:27] XYZParser.java:14: code too large
> >>>>> [15:41:27]     public static final String[] tokenNames = new String[]
> {
> >>>>> [15:41:27]                                  ^
> >>>>> [15:41:27] 1 error
> >>>>>
> >>>>>
> >>>>> Many thanks and greetings
> >>>>> Udo
> >>>>>
> >>>>>
> >>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >>>>> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >>>>
> >>>
> >>> <vhdl__UW1a.g>
> >>
> >
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Sep 2011 20:57:59 +0100
> From: Sam Barnett-Cormack <s.barnett-cormack at lancaster.ac.uk>
> Subject: Re: [antlr-interest] ANTLRWorks 1.4.3: XYZParser.java:14:
>        code too large (public static final String[] tokenNames = new
> String[]
>        { ... } ; )
> To: Vlad <vlad at demoninsight.com>
> Cc: "Antlr-Interest Antlr.Org" <antlr-interest at antlr.org>
> Message-ID: <4E80D947.7070305 at lancaster.ac.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The possibility of static nested classes had also occured to me as a way
> of breaking up the otherwise-huge static initialisation code being
> produced. For things like the followsets, it might be beneficial to look
> at the architecture of the generated code to see if there's any possible
> benefit to defining an abstract class these static nested classes could
> inherit from.
>
> Another possibility would be removing these large static data structures
> from the source entirely, and instead emitting some extra files that
> define them and that are read in by the generated code. Java resource
> loading semantics mean that files located with the class files are easy
> to load at run-time. A readable format could even be used to make it
> easier for humans to understand the code (and supporting data) that are
> generated.
>
> Sam
>
> On 26/09/2011 20:36, Vlad wrote:
> > Java .class file format has a specification limit such that any bytecode
> method must not be more than 64k bytes. If this limit is violated (normally
> only happens with auto-generated code) you'll see the compiler error you
> have.
> >
> > Although it is not very common knowledge, any java code of the form
> >
> > ... static final SomeType SOME_FIELD =<some exp>
> >
> > is equivalent to the following:
> >
> > a declaration of
> >
> > ... static final SomeType SOME_FIELD;
> >
> > combined with bytecode to compute<some exp>  and assign it to SOME_FIELD,
> performed inside a special method named '<clinit>' at class loading time. It
> is the same method that also collects anything you put in a static { }
> block. I had a look at the .java files you see generated from your grammer
> and there is absolutely a ton of public static finals that require
> such<clinit>  code: some 1300 FOLLOW_... BitSets, tokenNames, ruleNames,
> etc.
> >
> > All of those static field init bytecodes end up in<clinit>  and cause
> size overflow. It seems to me that hitting the 64K limit can happen for any
> reasonably large grammar ("large" defined not just in terms of token count,
> but also the number of rules, etc).
> >
> > To address this issue at the fundamental level, ANTLR need to alter its
> .java code emission strategy. Perhaps map rules to static methods of static
> nested classes instead of lumping everything into a single .class
> definition. Nested classes in Java are compiled into separate .class
> definitions, each with it own<clinit>.
> >
> > HTH,
> > Vlad
> >
> > On Sep 26, 2011, at 1:06 PM, Udo Weik wrote:
> >
> >> Hello Terence,
> >>
> >>> Interesting. That's not that big.Only 162 strings should not merely be
> enough to blow out the 64k  static INIT method limit. hmm... perhaps the
> other arrays are the big as well.
> >>> ter
> >>
> >> I just tried to delete 'static' but of course that doesn't work:
> >> XYZParser.java:347: non-static variable tokenNames cannot be referenced
> from a static context
> >> So the question is - any solution for that problem?
> >>
> >> Thanks and greetings
> >> Udo
> >>
> >>
> >>> On Sep 26, 2011, at 8:42 AM, Udo Weik wrote:
> >>>
> >>>> Hello Terence,
> >>>>
> >>>>> wow! how big is that grammar?
> >>>>> Ter
> >>>>
> >>>> I'm trying to get the VHDL-grammar for the CSharp-target from
> >>>> Mike Lodder working with Java:
> >>>> http://www.antlr.org/grammar/1202750770887/vhdl.g
> >>>>
> >>>> Some first, very basic modifications see attachement.
> >>>> First of all that grammar should work with ANTLRWorks 1.4.3.
> >>>>
> >>>> Many thanks for any support
> >>>> Udo
> >>>>
> >>>>
> >>>>> On Sep 26, 2011, at 6:50 AM, Udo Weik wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> the length of that line is 1647 chars (162 strings).
> >>>>>> The grammar is an existing one. What can/must I do?
> >>>>>>
> >>>>>> [15:41:27] XYZParser.java:14: code too large
> >>>>>> [15:41:27]     public static final String[] tokenNames = new
> String[] {
> >>>>>> [15:41:27]                                  ^
> >>>>>> [15:41:27] 1 error
> >>>>>>
> >>>>>>
> >>>>>> Many thanks and greetings
> >>>>>> Udo
> >>>>>>
> >>>>>>
> >>>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >>>>>> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >>>>>
> >>>>
> >>>> <vhdl__UW1a.g>
> >>>
> >>
> >>
> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 Sep 2011 22:07:45 +0200
> From: Udo Weik <WeikEngOff at aol.com>
> Subject: Re: [antlr-interest] ANTLRWorks 1.4.3: XYZParser.java:14:
>        code too large (public static final String[] tokenNames = new
> String[]
>        { ... } ; )
> To: Vlad <vlad at demoninsight.com>
> Cc: "Antlr-Interest Antlr.Org" <antlr-interest at antlr.org>
> Message-ID: <4E80DB91.4060209 at aol.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello Vlad,
>
> many thanks for your really valuable analysis.
>
> @Terence:
> The ball's in your court!
>
>
> Greetings
> Udo
>
> > Java .class file format has a specification limit such that any bytecode
> method must not be more than 64k bytes. If this limit is violated (normally
> only happens with auto-generated code) you'll see the compiler error you
> have.
> >
> > Although it is not very common knowledge, any java code of the form
> >
> > ... static final SomeType SOME_FIELD =<some exp>
> >
> > is equivalent to the following:
> >
> > a declaration of
> >
> > ... static final SomeType SOME_FIELD;
> >
> > combined with bytecode to compute<some exp>  and assign it to SOME_FIELD,
> performed inside a special method named '<clinit>' at class loading time. It
> is the same method that also collects anything you put in a static { }
> block. I had a look at the .java files you see generated from your grammer
> and there is absolutely a ton of public static finals that require
> such<clinit>  code: some 1300 FOLLOW_... BitSets, tokenNames, ruleNames,
> etc.
> >
> > All of those static field init bytecodes end up in<clinit>  and cause
> size overflow. It seems to me that hitting the 64K limit can happen for any
> reasonably large grammar ("large" defined not just in terms of token count,
> but also the number of rules, etc).
> >
> > To address this issue at the fundamental level, ANTLR need to alter its
> .java code emission strategy. Perhaps map rules to static methods of static
> nested classes instead of lumping everything into a single .class
> definition. Nested classes in Java are compiled into separate .class
> definitions, each with it own<clinit>.
> >
> > HTH,
> > Vlad
> >
> > On Sep 26, 2011, at 1:06 PM, Udo Weik wrote:
> >
> >> Hello Terence,
> >>
> >>> Interesting. That's not that big.Only 162 strings should not merely be
> enough to blow out the 64k  static INIT method limit. hmm... perhaps the
> other arrays are the big as well.
> >>> ter
> >>
> >> I just tried to delete 'static' but of course that doesn't work:
> >> XYZParser.java:347: non-static variable tokenNames cannot be referenced
> from a static context
> >> So the question is - any solution for that problem?
> >>
> >> Thanks and greetings
> >> Udo
> >>
> >>
> >>> On Sep 26, 2011, at 8:42 AM, Udo Weik wrote:
> >>>
> >>>> Hello Terence,
> >>>>
> >>>>> wow! how big is that grammar?
> >>>>> Ter
> >>>>
> >>>> I'm trying to get the VHDL-grammar for the CSharp-target from
> >>>> Mike Lodder working with Java:
> >>>> http://www.antlr.org/grammar/1202750770887/vhdl.g
> >>>>
> >>>> Some first, very basic modifications see attachement.
> >>>> First of all that grammar should work with ANTLRWorks 1.4.3.
> >>>>
> >>>> Many thanks for any support
> >>>> Udo
> >>>>
> >>>>
> >>>>> On Sep 26, 2011, at 6:50 AM, Udo Weik wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> the length of that line is 1647 chars (162 strings).
> >>>>>> The grammar is an existing one. What can/must I do?
> >>>>>>
> >>>>>> [15:41:27] XYZParser.java:14: code too large
> >>>>>> [15:41:27]     public static final String[] tokenNames = new
> String[] {
> >>>>>> [15:41:27]                                  ^
> >>>>>> [15:41:27] 1 error
> >>>>>>
> >>>>>>
> >>>>>> Many thanks and greetings
> >>>>>> Udo
> >>>>>>
> >>>>>>
> >>>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >>>>>> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >>>>>
> >>>>
> >>>> <vhdl__UW1a.g>
> >>>
> >>
> >>
> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 26 Sep 2011 15:50:11 -0700
> From: Terence Parr <parrt at cs.usfca.edu>
> Subject: Re: [antlr-interest] [stringtemplate-interest] a logo design?
>        branding.
> To: stringtemplate-interest List <stringtemplate-interest at antlr.org>,
>        antlr-interest Interest <antlr-interest at antlr.org>
> Message-ID: <93E1364E-AF32-4CF2-8E44-358BF9DB743B at cs.usfca.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Thanks for the feedback!
> Ter
> On Sep 25, 2011, at 10:12 PM, Michael Bedward wrote:
>
> > The correct answer is "you're the designer - you tell me".
> >
> > My fall back answers are:
> >
> >> 1. what existing logos do we like and why
> >
> > GeoTools: compass / spanner logo (http://geotools.org/) because it's a
> > simple and informative pun
> >
> > TED: big red letters (http://www.ted.com/) because it's obvious and
> memorable
> >
> > ScapeToad: toad logo (http://scapetoad.choros.ch/) because it's
> > ridiculous with a certain elegance
> >
> > R (http://www.r-project.org/) because you just say Rrrr...
> >
> >> 2.  what logos do we dislike and why
> >
> > Sonatype: horizontal bars and thin font (http://www.sonatype.com/)
> > because it looks corporate and boring
> >
> > ESRI globe in grid (http://www.esri.com/) because it looks like they
> > want to take the world prisoner
> >
> > Old Sun logo (as seen at:
> >
> http://java.sun.com/products/java-media/jai/forDevelopers/jai1_0_1guide-unc/JAITOC.fm.html
> )
> > because it's on the wrong side of the line between clever and wanky
> >
> > NetBeans: box figure and name (http://netbeans.org/) because what are
> > you supposed to do with an empty box ?
> >
> >> 3. Preferred typography
> >
> > Either elegant or in your face, but not script (usually lacks
> > immediacy) or very angular / geometric (e.g. the font used for the
> > Oracle logo which looks fascist - though perhaps that's just my
> > prejudice shining through).
> >
> > Michael
> >
> >
> > On 26 September 2011 00:59, Terence Parr <parrt at cs.usfca.edu> wrote:
> >> hi.  Sam Harwell had the great idea that I should commission a logo or
> logos for the ANTLR project. Perhaps there is a similar and consistent logo
> design for the individual tools. I'm also considering a new layout and
> design for the website. Basically v4 will have major new functionality and I
> want to do some nice branding for it. Sam also recommend someone that seems
> very good for doing the logo design. Questionnaire I have to fill out for
> this designer, however, asks questions that I don't really know how to
> answer exactly. I thought that I should appeal to you folks in the community
> so that we can  hone the answers for the designer to get something nice.
> Here are some questions that you might know the answer to or have opinions
> on:
> >>
> >> 1. what existing logos do we like and why
> >>
> >> 2.  what logos do we dislike and why
> >>
> >> 3. Preferred typography (heavy, light, modern, classic, handwritten
> etc.)  maybe we don't want text in the logo at all, but it seems like .g and
> .st could work in the individual tool logos. Microsoft logos for example:
> >>
> >>
> >> Here is the logo portfolio of the guy:
> >>
> >> http://www.logoholik.com/logo_portfolio/logo_portfolio.html
> >>
> >>  any and all thoughts about branding are welcome.
> >>
> >> Ter
> >>
> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >>
> > _______________________________________________
> > stringtemplate-interest mailing list
> > stringtemplate-interest at antlr.org
> > http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 26 Sep 2011 21:54:33 -0400
> From: "Kevin J. Cummings" <cummings at kjchome.homeip.net>
> Subject: Re: [antlr-interest] Fwd: ANTLRWorks bug: Remove Left
>        Recursion with comments in grammar
> To: antlr-interest at antlr.org
> Message-ID: <4E812CD9.3000008 at kjchome.homeip.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I'm confused.  If you have:
>
> string : string Plus string
>       | string Minus string
>       | Digit
>       ;
>
> and you remove left recursion, why don't you end up with:
>
> string : Digit ( Plus Digit | Minus Digit )*
>       ;
>
> And, yes, the error message with the ";" in it is amusing.
>
> On 09/26/2011 02:05 PM, The Researcher wrote:
> > I forgot to give credit where credit is due.
> >
> > This grammar is from
> >
> > Aho, A. V., Lam, M. S., Sethi, R., & Ullman, J. D. (2007) Compilers:
> > principles, techniques, & tools (2nd ed.). Boston: Pearson/Addison
> Wesley.
> > pg. 47, Example 2.5
> >
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: The Researcher <researcher0x00 at gmail.com>
> > Date: Mon, Sep 26, 2011 at 1:51 PM
> > Subject: ANTLRWorks bug: Remove Left Recursion with comments in grammar
> > To: antlr-interest at antlr.org
> >
> >
> > grammar Ambiguious001;
> >
> >
> >
> > string      : string Plus string
> >
> >             | string Minus string
> >
> >             | Digit
> >
> >             ;
> >
> >
> >
> > Digit       : '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
> >
> > Minus       : '-' ;
> >
> > Plus        : '+' ;
> >
> >
> >
> > Remove All Left Recursion or Remove Left Recursion produces
> >
> > grammar Ambiguious001;
> >
> >
> >
> > string      : (Digit) (Plus string | Minus string)*
> >
> >             ;
> >
> >
> >
> > Digit       : '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
> >
> > Minus       : '-' ;
> >
> > Plus        : '+' ;
> >
> >
> >
> > However
> >
> > grammar Ambiguious001;
> >
> >
> >
> > // Parser
> >
> >
> >
> > string      : string Plus string
> >
> >             | string Minus string
> >
> >             | Digit
> >
> >             ;
> >
> >
> >
> > // Lexer
> >
> >
> >
> > Digit       : '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
> >
> > Minus       : '-' ;
> >
> > Plus        : '+' ;
> >
> >
> >
> > Remove All Left Recursion or Remove Left Recursion produces
> >
> >
> >
> > grammar Ambiguious001;
> >
> >
> >
> > // Parser
> >
> >
> >
> > string      : (Digit
> >
> >             ;) (Plus string | Minus string)*
> >
> >
> >
> > // Lexer
> >
> >
> >
> > Digit       : '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
> >
> > Minus       : '-' ;
> >
> > Plus        : '+' ;
> >
> >   It's the first time I have ever had an error wink at me.
> >
> > Eric
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>
>
> --
> Kevin J. Cummings
> kjchome at verizon.net
> cummings at kjchome.homeip.net
> cummings at kjc386.framingham.ma.us
> Registered Linux User #1232 (http://www.xlinuxcounter.net/)
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 27 Sep 2011 12:53:17 +1000
> From: Gary Miller <gary at sumwise.com>
> Subject: Re: [antlr-interest] Fwd: ANTLRWorks bug: Remove Left
>        Recursion with comments in grammar
> To: researcher0x00 at gmail.com
> Cc: antlr-interest at antlr.org
> Message-ID:
>        <CAFCNb3hKcjXNfv9UyU-+-AXZN96OEfrukvYCmW-k_-KQwj27Aw at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> What version of are you using?
> I've tried with 3.2 and 3.4 and get very boring error messages.
>
> eg 3.2 gives
> 9:12: syntax error: antlr: <notsaved>:9:12: expecting RPAREN, found ';'
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 27 Sep 2011 11:38:46 +0800
> From: Chan David <lifesting at gmail.com>
> Subject: [antlr-interest] Best practices to insert breakpoint when
>        generating code?
> To: antlr-interest at antlr.org
> Message-ID:
>        <CAF_ThcLgLcgebMEYd+G5uWVSqoDFtyy-2w3NEhm62wxwjYaoiA at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi, Antlr fellows:
>
> I wrote a simple parser and a weak runtime to make a prototype of our DSL.
> I
> followed the de-facto definition steps:
>
>
>   1. Define a lex grammar to describe tokens.
>   2. Define a parser grammar to describe syntax and build an AST.
>   3. Define a tree grammar to genereate DSL source code via StringTemplate
>   which includes my hand-written execution code as runtime.
>
> Now I want to run this DSL code in Eclipse directly. So I must let DSL
> support debugging.  I must embbed a hook function in every start of a
> statement. I named this function 'breakpoint', it need a line number as
> argument.
>
> For example, there's a "x=1" statement in my DSL where AST is ^(ASSIGN, x,
> 1) . I insert a function like below:
>
> assignStmt @init{
>  breakpoint(Problem: how to get line number here?);
> } :  ^(ASSIGN, ID, INT) {
>  .....//Omitted
> }
>
> I don't know how to get line number at the start of a statement, further, I
> doubt whether this method is correct.
>
> Thank for you help!
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 27 Sep 2011 12:16:51 +0300
> From: Ruslan Zasukhin <ruslan_zasukhin at valentina-db.com>
> Subject: [antlr-interest] [C] code to change Token type, use char* and
>        loose data when buffer destroyed
> To: "antlr-interest at antlr.org" <antlr-interest at antlr.org>,      Jim Idle
>        <jimi at temporal-wave.com>
> Message-ID: <CAA76F33.F2983%ruslan_zasukhin at valentina-db.com>
> Content-Type: text/plain;       charset="US-ASCII"
>
> Hi All,
>
> ===== TASK ======
>
> In SQL we must be able write
>      SELECT 'aaa' 'bbbb'
>
> And this should be same as
>      SELECT 'aaabbbb'
>
> I.e. Parser must concatenate literals self.
> This was quite easy do in ANTLR 2,
> and I already have kill 5-6 hours in ANTLR 3.  :-((((((
>
>
> I have try many tricks for ANTLR3 itself trying to use its tokens and
> ANTLR_STRING class but no luck.
>
> Finally I have give up and have try to use simple code as in v2 using
> STD::string as place to accumulate literal.
>
> =================================
> character_string_literal
> @init{
>    STD::string st;
> }
>    :    ( STRING_LITERAL
>            {
>                st.append(
>                    (const char*) $STRING_LITERAL.text->chars,
>                    $STRING_LITERAL.text->len );
>            }
>        )+
>            -> ^( CONST_STR[ st.c_str() ] )
>    ;
> =================================
>
> But this not works, because new Token object stores just pointer
>
>        newToken->textState        = ANTLR3_TEXT_CHARP;
>        newToken->tokText.chars = (pANTLR3_UCHAR)text;
>
> And as only STD::string dies we get problem.
>
>
> Jim, how this simple task can be solved in the C TARGET ?
>
> Also I see that for Java code they can contruct dynamic text
> And produce token using that text. For example on this page
>
> http://www.antlr.org/wiki/display/ANTLR3/Tree+construction
>
>                            -> ^('+' $p INT[String.valueOf($a.int+$b.int)])
>
>
> But C target tryies to work only which char*
>
>
> I guess that ANTLR_STRING setText() can help me,
> But I cannot see how I can call that from my
>
>            -> ^( CONST_STR[ st.c_str() ] )
>
> ???
>
> Thank you for points ...
>
>
> --
> Best regards,
>
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
>
> Valentina - Joining Worlds of Information
> http://www.paradigmasoft.com
>
> [I feel the need: the need for speed]
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 27 Sep 2011 06:45:54 -0400
> From: The Researcher <researcher0x00 at gmail.com>
> Subject: Re: [antlr-interest] Fwd: ANTLRWorks bug: Remove Left
>        Recursion with comments in grammar
> To: antlr-interest at antlr.org
> Message-ID:
>        <CAN45N12sF0t7mfWaPy3ZB3OuBh-iJxswbPvtJOcgTozOdY4rFg at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Mon, Sep 26, 2011 at 10:53 PM, Gary Miller <gary at sumwise.com> wrote:
>
> > What version of are you using?
> > I've tried with 3.2 and 3.4 and get very boring error messages.
> >
> > eg 3.2 gives
> > 9:12: syntax error: antlr: <notsaved>:9:12: expecting RPAREN, found ';'
> >
>
> This is done using ANTLRWorks. See attached screenshots.
>
> Eric
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Left Recursion Refactor Bug ANTLRWorks 1.4.2.png
> Type: image/png
> Size: 101799 bytes
> Desc: not available
> Url :
> http://www.antlr.org/pipermail/antlr-interest/attachments/20110927/fa1e68c4/attachment.png
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Left Recursion Refactor Bug ANTLRWorks 1.4.3.png
> Type: image/png
> Size: 144985 bytes
> Desc: not available
> Url :
> http://www.antlr.org/pipermail/antlr-interest/attachments/20110927/fa1e68c4/attachment-0001.png
>
> ------------------------------
>
> _______________________________________________
> antlr-interest mailing list
> antlr-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/antlr-interest
>
> End of antlr-interest Digest, Vol 82, Issue 22
> **********************************************
>


More information about the antlr-interest mailing list