From parrt at cs.usfca.edu Wed Sep 3 12:55:06 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 3 Sep 2008 12:55:06 -0700 Subject: [antlr-dev] set REV Number for daily builds Message-ID: <46E17981-A89C-4E06-B200-B5C371EF347B@cs.usfca.edu> Howdy, i added an awk script to set the public static final String REV = "-beta"; variable inside Tool.java Now the daily builds will print out the date as part of the banner. Ter From parrt at cs.usfca.edu Wed Sep 3 12:58:28 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 3 Sep 2008 12:58:28 -0700 Subject: [antlr-dev] \uFFFF Message-ID: <70614ED6-DDC3-466A-ADC6-70624D0AF61F@cs.usfca.edu> Hi, I designed everything to be 32 bit clean in terms of token types and character input so, while \uFFFF is not about character, there is no reason we can't allow that is input. currently we do not. I set the maximum to \uFFFE but I am changing it to: public static final int MAX_CHAR_VALUE = '\uFFFF'; My unit tests and examples directory seemed to work okay. The Java.g grammar for Sun needs to mimic what the javac compiler does; it allow us '\uFFFF' and more importantly converts that to the single Unicode character code point BEFORE the compiler sees it. it is done in the character string. anyway, ANTLR says that is an invalid character at the moment. I don't think we will have a problem... can anyone think of an issue? I do all of my checks using -1 not '\uFFFF' for EOF...we *should* be okay... Ter From jaluber at gmx.de Wed Sep 3 13:31:23 2008 From: jaluber at gmx.de (Johannes Luber) Date: Wed, 03 Sep 2008 22:31:23 +0200 Subject: [antlr-dev] \uFFFF In-Reply-To: <70614ED6-DDC3-466A-ADC6-70624D0AF61F@cs.usfca.edu> References: <70614ED6-DDC3-466A-ADC6-70624D0AF61F@cs.usfca.edu> Message-ID: <48BEF41B.2050102@gmx.de> Terence Parr schrieb: > Hi, I designed everything to be 32 bit clean in terms of token types > and character input so, while \uFFFF is not about character, there is > no reason we can't allow that is input. currently we do not. I set the > maximum to \uFFFE but I am changing it to: > > public static final int MAX_CHAR_VALUE = '\uFFFF'; > > My unit tests and examples directory seemed to work okay. The Java.g > grammar for Sun needs to mimic what the javac compiler does; it allow > us '\uFFFF' and more importantly converts that to the single Unicode > character code point BEFORE the compiler sees it. it is done in the > character string. anyway, ANTLR says that is an invalid character at > the moment. I don't think we will have a problem... can anyone think > of an issue? I do all of my checks using -1 not '\uFFFF' for EOF...we > *should* be okay... > > Ter Does unicode restrict the use \uffff? Will you sometime add handling for chars bigger than \uffff natively in ANTLR, even if you need some translation functions to make things work in JAva? Johannes From parrt at cs.usfca.edu Wed Sep 3 13:33:24 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 3 Sep 2008 13:33:24 -0700 Subject: [antlr-dev] \uFFFF In-Reply-To: <48BEF41B.2050102@gmx.de> References: <70614ED6-DDC3-466A-ADC6-70624D0AF61F@cs.usfca.edu> <48BEF41B.2050102@gmx.de> Message-ID: <7FA72D5C-D987-46F3-BAFB-FC329F8CDDBC@cs.usfca.edu> On Sep 3, 2008, at 1:31 PM, Johannes Luber wrote: > Terence Parr schrieb: >> Hi, I designed everything to be 32 bit clean in terms of token types >> and character input so, while \uFFFF is not about character, there is >> no reason we can't allow that is input. currently we do not. I set >> the >> maximum to \uFFFE but I am changing it to: >> >> public static final int MAX_CHAR_VALUE = '\uFFFF'; >> >> My unit tests and examples directory seemed to work okay. The Java.g >> grammar for Sun needs to mimic what the javac compiler does; it allow >> us '\uFFFF' and more importantly converts that to the single Unicode >> character code point BEFORE the compiler sees it. it is done in the >> character string. anyway, ANTLR says that is an invalid character at >> the moment. I don't think we will have a problem... can anyone think >> of an issue? I do all of my checks using -1 not '\uFFFF' for EOF...we >> *should* be okay... >> >> Ter > > Does unicode restrict the use \uffff? Will you sometime add handling > for > chars bigger than \uffff natively in ANTLR, even if you need some > translation functions to make things work in JAva? I haveTo figure out what all the 32bit character stuff means... The machinery of ANTLR should be able to handle 32-bit signed integers as characters or token types... representing them in a Java string for the Java target is another matter ;) Ter From jimi at temporal-wave.com Wed Sep 3 13:42:13 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Wed, 03 Sep 2008 13:42:13 -0700 Subject: [antlr-dev] \uFFFF In-Reply-To: <7FA72D5C-D987-46F3-BAFB-FC329F8CDDBC@cs.usfca.edu> References: <70614ED6-DDC3-466A-ADC6-70624D0AF61F@cs.usfca.edu> <48BEF41B.2050102@gmx.de> <7FA72D5C-D987-46F3-BAFB-FC329F8CDDBC@cs.usfca.edu> Message-ID: <1220474533.7778.302.camel@jimi> On Wed, 2008-09-03 at 13:33 -0700, Terence Parr wrote: > On Sep 3, 2008, at 1:31 PM, Johannes Luber wrote: > > > Terence Parr schrieb: > >> Hi, I designed everything to be 32 bit clean in terms of token types > >> and character input so, while \uFFFF is not about character, there is > >> no reason we can't allow that is input. currently we do not. I set > >> the > >> maximum to \uFFFE but I am changing it to: > >> > >> public static final int MAX_CHAR_VALUE = '\uFFFF'; > >> > >> My unit tests and examples directory seemed to work okay. The Java.g > >> grammar for Sun needs to mimic what the javac compiler does; it allow > >> us '\uFFFF' and more importantly converts that to the single Unicode > >> character code point BEFORE the compiler sees it. it is done in the > >> character string. anyway, ANTLR says that is an invalid character at > >> the moment. I don't think we will have a problem... can anyone think > >> of an issue? I do all of my checks using -1 not '\uFFFF' for EOF...we > >> *should* be okay... > >> > >> Ter > > > > Does unicode restrict the use \uffff? Will you sometime add handling > > for > > chars bigger than \uffff natively in ANTLR, even if you need some > > translation functions to make things work in JAva? > > I haveTo figure out what all the 32bit character stuff means... The > machinery of ANTLR should be able to handle 32-bit signed integers as > characters or token types That's how the C runtime deals with it. > ... representing them in a Java string for > the Java target is another matter ;) Ah, well now ;-) Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080903/a6adce85/attachment.html From jaluber at gmx.de Wed Sep 3 13:50:52 2008 From: jaluber at gmx.de (Johannes Luber) Date: Wed, 03 Sep 2008 22:50:52 +0200 Subject: [antlr-dev] \uFFFF In-Reply-To: <7FA72D5C-D987-46F3-BAFB-FC329F8CDDBC@cs.usfca.edu> References: <70614ED6-DDC3-466A-ADC6-70624D0AF61F@cs.usfca.edu> <48BEF41B.2050102@gmx.de> <7FA72D5C-D987-46F3-BAFB-FC329F8CDDBC@cs.usfca.edu> Message-ID: <48BEF8AC.4010607@gmx.de> Terence Parr schrieb: > > On Sep 3, 2008, at 1:31 PM, Johannes Luber wrote: > >> Terence Parr schrieb: >>> Hi, I designed everything to be 32 bit clean in terms of token types >>> and character input so, while \uFFFF is not about character, there is >>> no reason we can't allow that is input. currently we do not. I set the >>> maximum to \uFFFE but I am changing it to: >>> >>> public static final int MAX_CHAR_VALUE = '\uFFFF'; >>> >>> My unit tests and examples directory seemed to work okay. The Java.g >>> grammar for Sun needs to mimic what the javac compiler does; it allow >>> us '\uFFFF' and more importantly converts that to the single Unicode >>> character code point BEFORE the compiler sees it. it is done in the >>> character string. anyway, ANTLR says that is an invalid character at >>> the moment. I don't think we will have a problem... can anyone think >>> of an issue? I do all of my checks using -1 not '\uFFFF' for EOF...we >>> *should* be okay... >>> >>> Ter >> >> Does unicode restrict the use \uffff? Will you sometime add handling for >> chars bigger than \uffff natively in ANTLR, even if you need some >> translation functions to make things work in JAva? > > I haveTo figure out what all the 32bit character stuff means... The > machinery of ANTLR should be able to handle 32-bit signed integers as > characters or token types... representing them in a Java string for the > Java target is another matter ;) > > Ter > Unicode assigns codepoints to each defined characters. UTF-x defines the way, which encodes a particular codepoint. For UTF-16 this means that the integers from '\uD800'..'\uDBFF' and '\uDC00'..'\uDFFF' are considered surrogate code points. These SCPs require 2 chars/4 bytes in Java (and C#/.NET) and can be transformed from and to the UTF-32 encoding, which is the 1:1 representation of code point numbers. I'd prefer it if you add to '\uxxxx' also '\Uxxxxxxxx', which is the way in C# to encode big unicodes. I've created some functions to deal with this for my own lexer in some earlier stage. You may find them useful, even if you have to change it to the JRE workings. While my file is under the MIT license, you can license snippets under BSD. Johannes -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CSharp3Lexer.g Url: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080903/541eeec9/attachment.pl From parrt at cs.usfca.edu Mon Sep 8 17:28:50 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Mon, 8 Sep 2008 17:28:50 -0700 Subject: [antlr-dev] labels carried into synpreds now Message-ID: * Labels on tokens, rules carry into synpreds now so semantic predicates work. This didn't work since labels were stripped in the synpred and they weren't defined in the generated method. a : x=A z=a {$x.text.equals($z.text)}? A | y=A a A A ; edit //depot/code/antlr/main/CHANGES.txt#96 edit //depot/code/antlr/main/src/org/antlr/codegen/templates/Java/ Java.stg#138 edit //depot/code/antlr/main/src/org/antlr/tool/GrammarAST.java#47 Change 5256 submitted. Ter From sharwell at pixelminegames.com Mon Sep 8 18:08:26 2008 From: sharwell at pixelminegames.com (Sam Harwell) Date: Mon, 8 Sep 2008 20:08:26 -0500 Subject: [antlr-dev] labels carried into synpreds now In-Reply-To: References: Message-ID: <86403CA0939415448BCCB83855EFE09A64E31B@Bloodymary.ironwillgames.com> I have run into this issue before and it'll simplify some of my rules now that it's fixed. I believe the other thing that didn't carry into synpreds was parameterized rules: a[bool b] : {b}? c | d ; x : (a[true])? => a[true] | y ; Sam -----Original Message----- From: antlr-dev-bounces at antlr.org [mailto:antlr-dev-bounces at antlr.org] On Behalf Of Terence Parr Sent: Monday, September 08, 2008 7:29 PM To: ANTLR-dev Dev Cc: Leon Su Subject: [antlr-dev] labels carried into synpreds now * Labels on tokens, rules carry into synpreds now so semantic predicates work. This didn't work since labels were stripped in the synpred and they weren't defined in the generated method. a : x=A z=a {$x.text.equals($z.text)}? A | y=A a A A ; edit //depot/code/antlr/main/CHANGES.txt#96 edit //depot/code/antlr/main/src/org/antlr/codegen/templates/Java/ Java.stg#138 edit //depot/code/antlr/main/src/org/antlr/tool/GrammarAST.java#47 Change 5256 submitted. Ter _______________________________________________ antlr-dev mailing list antlr-dev at antlr.org http://www.antlr.org:8080/mailman/listinfo/antlr-dev From jaluber at gmx.de Tue Sep 9 00:44:46 2008 From: jaluber at gmx.de (Johannes Luber) Date: Tue, 09 Sep 2008 09:44:46 +0200 Subject: [antlr-dev] labels carried into synpreds now In-Reply-To: <86403CA0939415448BCCB83855EFE09A64E31B@Bloodymary.ironwillgames.com> References: <86403CA0939415448BCCB83855EFE09A64E31B@Bloodymary.ironwillgames.com> Message-ID: <48C6296E.7030809@gmx.de> Sam Harwell schrieb: > I have run into this issue before and it'll simplify some of my rules > now that it's fixed. I believe the other thing that didn't carry into > synpreds was parameterized rules: > > a[bool b] > : {b}? c > | d > ; > > x : (a[true])? => a[true] > | y > ; That's actually due to hoisting a bad design - in certain contexts b won't be available. ANTLR should generate an error here. Johannes > > Sam > > -----Original Message----- > From: antlr-dev-bounces at antlr.org [mailto:antlr-dev-bounces at antlr.org] > On Behalf Of Terence Parr > Sent: Monday, September 08, 2008 7:29 PM > To: ANTLR-dev Dev > Cc: Leon Su > Subject: [antlr-dev] labels carried into synpreds now > > * Labels on tokens, rules carry into synpreds now so semantic > predicates work. > This didn't work since labels were stripped in the synpred and they > weren't > defined in the generated method. > > a : x=A z=a {$x.text.equals($z.text)}? A > | y=A a A A > ; > > edit //depot/code/antlr/main/CHANGES.txt#96 > edit //depot/code/antlr/main/src/org/antlr/codegen/templates/Java/ > Java.stg#138 > edit //depot/code/antlr/main/src/org/antlr/tool/GrammarAST.java#47 > Change 5256 submitted. > > Ter > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev > From jimi at temporal-wave.com Tue Sep 9 10:02:36 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Tue, 09 Sep 2008 10:02:36 -0700 Subject: [antlr-dev] How to parse integers, floating numbers, octal, hex, dots, ranges and catch lex errors at the same time Message-ID: <1220979756.3951.72.camel@jimi.temporal-wave.com> This question comes up about 2 or 3 times a month, and people seem to have difficulty locating the prior emails that show how to do it. This is a common thing to have to lex, but the usual solutions don't account for range checking, partially formed input and so on. More than 50% of writing a grammar is concerned with catching errors, but most examples assume a perfect input and that the user will work out the error processing. The same requirement arises as part of the JavaFX project at Sun. The compiler part of JavaFX is open source, and the front end uses ANTLR 3.1; so I have published this part of the lexer on the WIki in the examples section at: http://www.antlr.org/wiki/display/ANTLR3/Lexer+grammar+for+floating +point%2C+dot%2C+range%2C+time+specs Hopefully, being in the Wiki and in innumerable past posts to the group will mean that the question won't keep cropping up on the group. I will alst Cheers, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080909/ef7c19c3/attachment.html From parrt at cs.usfca.edu Tue Sep 9 11:49:05 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Tue, 9 Sep 2008 11:49:05 -0700 Subject: [antlr-dev] How to parse integers, floating numbers, octal, hex, dots, ranges and catch lex errors at the same time In-Reply-To: <1220979756.3951.72.camel@jimi.temporal-wave.com> References: <1220979756.3951.72.camel@jimi.temporal-wave.com> Message-ID: <9989F8DB-70C2-4BF5-90C8-655F73760046@cs.usfca.edu> Thanks very much Jim! I just expanded taps to four instead of 8 to make it more narrow. Ter From parrt at cs.usfca.edu Tue Sep 9 20:19:12 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Tue, 9 Sep 2008 20:19:12 -0700 Subject: [antlr-dev] 3.1.1 Message-ID: <5B150F7E-C9BF-4D40-B0DB-E6EF0E036A88@cs.usfca.edu> Hi Gang, Sun needs 3.1.1 to come out before they can publish their ANTLR Java grammar...if i quit futzing with it, how soon can we go 3.1.1? 3.1.2 can follow quickly ;) Ter From jimi at temporal-wave.com Tue Sep 9 20:44:32 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Tue, 09 Sep 2008 20:44:32 -0700 Subject: [antlr-dev] 3.1.1 In-Reply-To: <5B150F7E-C9BF-4D40-B0DB-E6EF0E036A88@cs.usfca.edu> References: <5B150F7E-C9BF-4D40-B0DB-E6EF0E036A88@cs.usfca.edu> Message-ID: <1221018272.3951.198.camel@jimi.temporal-wave.com> On Tue, 2008-09-09 at 20:19 -0700, Terence Parr wrote: > Hi Gang, > > Sun needs 3.1.1 to come out before they can publish their ANTLR Java > grammar...if i quit futzing with it, how soon can we go 3.1.1? 3.1.2 > can follow quickly ;) Not before the weekend I think - I have a few critical fixes that need to be in there and people are waiting on them. However, Sun are waiting on me to finish the JavaFX compiler too ;-) JIm > > Ter > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080909/16f66c0b/attachment.html From parrt at cs.usfca.edu Wed Sep 10 09:17:28 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 10 Sep 2008 09:17:28 -0700 Subject: [antlr-dev] 3.1.1 In-Reply-To: <1221018272.3951.198.camel@jimi.temporal-wave.com> References: <5B150F7E-C9BF-4D40-B0DB-E6EF0E036A88@cs.usfca.edu> <1221018272.3951.198.camel@jimi.temporal-wave.com> Message-ID: On Sep 9, 2008, at 8:44 PM, Jim Idle wrote: > On Tue, 2008-09-09 at 20:19 -0700, Terence Parr wrote: >> >> Hi Gang, >> >> Sun needs 3.1.1 to come out before they can publish their ANTLR Java >> grammar...if i quit futzing with it, how soon can we go 3.1.1? 3.1.2 >> can follow quickly ;) > > Not before the weekend I think - I have a few critical fixes that > need to be in there and people are waiting on them. However, Sun are > waiting on me to finish the JavaFX compiler too ;-) Ok, cool. I think maybe we should shoot for another week or two then. Ter From parrt at cs.usfca.edu Thu Sep 11 10:58:17 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Thu, 11 Sep 2008 10:58:17 -0700 Subject: [antlr-dev] rm'd build from jar name Message-ID: edit //depot/code/antlr/support/bin/antlrdaily#9 edit //depot/code/antlr/support/bin/antlrrelease#17 Change 5258 submitted. now builds antlr-$BUILD/lib/antlr.jar not antlr-$BUILD.jar easier to upgrade. Ter From parrt at cs.usfca.edu Tue Sep 16 13:13:23 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Tue, 16 Sep 2008 13:13:23 -0700 Subject: [antlr-dev] Fixed FOLLOW cache issue Message-ID: http://www.antlr.org:8888/browse/ANTLR-320 sync baby sync Ter From sharwell at pixelminegames.com Wed Sep 17 15:50:17 2008 From: sharwell at pixelminegames.com (Sam Harwell) Date: Wed, 17 Sep 2008 17:50:17 -0500 Subject: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches Message-ID: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> In the past, I noted that one of the ANTLR compile errors was checking a visual ambiguity and not a syntactic ambiguity. In order to work around the error, I have placed a label ("right=") on one of the references in the following rule. However, I still get: error 132: reference $assign_expression is ambiguous; rule assign_expression is enclosing rule and referenced in the production (assuming enclosing rule) assign_expression : ( ternary_expression -> ternary_expression ) ( assignment_operator right=assign_expression -> ^(assignment_operator $assign_expression $right) )? ; I've tried to make suggestions for ways to prevent the visual ambiguity that error 132 seeks to protect the developers from (such as $this or $self as the implicit label for the enclosing rule), but we never reached a consensus. Am I going to have to keep a modified version of the antlr3 source indefinitely? With error 132 disabled, all my grammars behave exactly as expected, even when written without the explicit label, as in the following case: assign_expression : ( ternary_expression -> ternary_expression ) ( assignment_operator assign_expression -> ^(assignment_operator $assign_expression assign_expression) )? ; Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080917/1dc9e498/attachment.html From parrt at cs.usfca.edu Wed Sep 17 16:59:24 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 17 Sep 2008 16:59:24 -0700 Subject: [antlr-dev] Jim Idle found a bug in pushFollow. doh! Message-ID: <1BDFC3D5-488F-4378-BAAF-DA65DCB2311D@cs.usfca.edu> edit //depot/code/antlr/main/runtime/Java/src/org/antlr/runtime/ BaseRecognizer.java#18 Change 5269 submitted. Ter From parrt at cs.usfca.edu Wed Sep 17 17:02:51 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 17 Sep 2008 17:02:51 -0700 Subject: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches In-Reply-To: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> References: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> Message-ID: On Sep 17, 2008, at 3:50 PM, Sam Harwell wrote: > In the past, I noted that one of the ANTLR compile errors was > checking a visual ambiguity and not a syntactic ambiguity. In order > to work around the error, I have placed a label (?right=?) on one of > the references in the following rule. However, I still get: > > error 132: reference $assign_expression is ambiguous; rule > assign_expression is enclosing rule and referenced in the production > (assuming enclosing rule) > > assign_expression > : ( ternary_expression > -> ternary_expression > ) > ( assignment_operator > right=assign_expression > -> ^(assignment_operator $assign_expression > $right) > )? > ; Because it is ambiguous, I elected to give an error message. Yep, we do need a way to reference the entire outer rule's tree. should it be $ $? Ter From jimi at temporal-wave.com Wed Sep 17 17:05:31 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Wed, 17 Sep 2008 17:05:31 -0700 Subject: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches In-Reply-To: References: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> Message-ID: <1221696331.8923.138.camel@jimi.temporal-wave.com> On Wed, 2008-09-17 at 17:02 -0700, Terence Parr wrote: > On Sep 17, 2008, at 3:50 PM, Sam Harwell wrote: > > > In the past, I noted that one of the ANTLR compile errors was > > checking a visual ambiguity and not a syntactic ambiguity. In order > > to work around the error, I have placed a label (?right=?) on one of > > the references in the following rule. However, I still get: > > > > error 132: reference $assign_expression is ambiguous; rule > > assign_expression is enclosing rule and referenced in the production > > (assuming enclosing rule) > > > > assign_expression > > : ( ternary_expression > > -> ternary_expression > > ) > > ( assignment_operator > > right=assign_expression > > -> ^(assignment_operator $assign_expression > > $right) > > )? > > ; > > Because it is ambiguous, I elected to give an error message. Yep, we > do need a way to reference the entire outer rule's tree. should it be $ > $? As in: $$assignment_operator, or just $$ ? Jim > > Ter > > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080917/9f81bd81/attachment.html From parrt at cs.usfca.edu Wed Sep 17 17:06:31 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Wed, 17 Sep 2008 17:06:31 -0700 Subject: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches In-Reply-To: <1221696331.8923.138.camel@jimi.temporal-wave.com> References: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> <1221696331.8923.138.camel@jimi.temporal-wave.com> Message-ID: <59AEB9E2-B587-4E75-BF41-7E8F016BABA5@cs.usfca.edu> On Sep 17, 2008, at 5:05 PM, Jim Idle wrote: > On Wed, 2008-09-17 at 17:02 -0700, Terence Parr wrote: >> >> On Sep 17, 2008, at 3:50 PM, Sam Harwell wrote: >> >> > In the past, I noted that one of the ANTLR compile errors was >> > checking a visual ambiguity and not a syntactic ambiguity. In order >> > to work around the error, I have placed a label (?right=?) on one >> of >> > the references in the following rule. However, I still get: >> > >> > error 132: reference $assign_expression is ambiguous; rule >> > assign_expression is enclosing rule and referenced in the >> production >> > (assuming enclosing rule) >> > >> > assign_expression >> > : ( ternary_expression >> > -> ternary_expression >> > ) >> > ( assignment_operator >> > right=assign_expression >> > -> ^(assignment_operator $assign_expression >> > $right) >> > )? >> > ; >> >> Because it is ambiguous, I elected to give an error message. Yep, we >> do need a way to reference the entire outer rule's tree. should it >> be $ >> $? > > As in: $$assignment_operator, or just $$ ? Just $$. I guess I was thinking about ## shorthand from version 2 antlr. $this and $self make me nervous because they are normally associate with objects and might refer to the current grammar/parser not the rule. T From jimi at temporal-wave.com Wed Sep 17 17:11:04 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Wed, 17 Sep 2008 17:11:04 -0700 Subject: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches In-Reply-To: <59AEB9E2-B587-4E75-BF41-7E8F016BABA5@cs.usfca.edu> References: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> <1221696331.8923.138.camel@jimi.temporal-wave.com> <59AEB9E2-B587-4E75-BF41-7E8F016BABA5@cs.usfca.edu> Message-ID: <1221696664.8923.145.camel@jimi.temporal-wave.com> On Wed, 2008-09-17 at 17:06 -0700, Terence Parr wrote: > On Sep 17, 2008, at 5:05 PM, Jim Idle wrote: > > > On Wed, 2008-09-17 at 17:02 -0700, Terence Parr wrote: > >> > >> On Sep 17, 2008, at 3:50 PM, Sam Harwell wrote: > >> > >> > In the past, I noted that one of the ANTLR compile errors was > >> > checking a visual ambiguity and not a syntactic ambiguity. In order > >> > to work around the error, I have placed a label (?right=?) on one > >> of > >> > the references in the following rule. However, I still get: > >> > > >> > error 132: reference $assign_expression is ambiguous; rule > >> > assign_expression is enclosing rule and referenced in the > >> production > >> > (assuming enclosing rule) > >> > > >> > assign_expression > >> > : ( ternary_expression > >> > -> ternary_expression > >> > ) > >> > ( assignment_operator > >> > right=assign_expression > >> > -> ^(assignment_operator $assign_expression > >> > $right) > >> > )? > >> > ; > >> > >> Because it is ambiguous, I elected to give an error message. Yep, we > >> do need a way to reference the entire outer rule's tree. should it > >> be $ > >> $? > > > > As in: $$assignment_operator, or just $$ ? > > Just $$. I guess I was thinking about ## shorthand from version 2 > antlr. $this and $self make me nervous because they are normally > associate with objects and might refer to the current grammar/parser > not the rule. Works for me! > > T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080917/fcf33e1f/attachment-0001.html From sharwell at pixelminegames.com Wed Sep 17 17:11:19 2008 From: sharwell at pixelminegames.com (Sam Harwell) Date: Wed, 17 Sep 2008 19:11:19 -0500 Subject: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches In-Reply-To: <59AEB9E2-B587-4E75-BF41-7E8F016BABA5@cs.usfca.edu> References: <86403CA0939415448BCCB83855EFE09A64E38C@Bloodymary.ironwillgames.com> <1221696331.8923.138.camel@jimi.temporal-wave.com> <59AEB9E2-B587-4E75-BF41-7E8F016BABA5@cs.usfca.edu> Message-ID: <86403CA0939415448BCCB83855EFE09A64E38D@Bloodymary.ironwillgames.com> $$ would work. That's what Bison uses in a [kinda-]similar case. I was certainly more concerned with consistency than which token to use. Sam -----Original Message----- From: Terence Parr [mailto:parrt at cs.usfca.edu] Sent: Wednesday, September 17, 2008 7:07 PM To: Jim Idle Cc: Sam Harwell; antlr-dev at antlr.org Subject: Re: [antlr-dev] "Ambiguous references" in rewrite rules still causing headaches Just $$. I guess I was thinking about ## shorthand from version 2 antlr. $this and $self make me nervous because they are normally associate with objects and might refer to the current grammar/parser not the rule. T From parrt at cs.usfca.edu Mon Sep 29 11:01:04 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Mon, 29 Sep 2008 11:01:04 -0700 Subject: [antlr-dev] bug fix 3.1.1 release going out today Message-ID: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> Any issues? Ter From sharwell at pixelminegames.com Mon Sep 29 11:17:04 2008 From: sharwell at pixelminegames.com (Sam Harwell) Date: Mon, 29 Sep 2008 13:17:04 -0500 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> Message-ID: <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> At least the C# target runtime has not been updated for CL 5269 (the pushFollow bug Jim found). I don't know what impact that has; is there a regression test you've created to detect that bug? Sam -----Original Message----- From: antlr-dev-bounces at antlr.org [mailto:antlr-dev-bounces at antlr.org] On Behalf Of Terence Parr Sent: Monday, September 29, 2008 1:01 PM To: ANTLR-dev Dev Subject: [antlr-dev] bug fix 3.1.1 release going out today Any issues? Ter _______________________________________________ antlr-dev mailing list antlr-dev at antlr.org http://www.antlr.org:8080/mailman/listinfo/antlr-dev From jaluber at gmx.de Mon Sep 29 12:10:29 2008 From: jaluber at gmx.de (Johannes Luber) Date: Mon, 29 Sep 2008 21:10:29 +0200 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> Message-ID: <48E12825.3020006@gmx.de> Sam Harwell schrieb: > At least the C# target runtime has not been updated for CL 5269 (the > pushFollow bug Jim found). I don't know what impact that has; is there a > regression test you've created to detect that bug? > > Sam Could I not have some more warning time? Usually you announce something like that at least one day in advance. If syncing is the only thing left I wait until such an announcement because it's easier do that in one go. And yes, I will do that now. Johannes > > -----Original Message----- > From: antlr-dev-bounces at antlr.org [mailto:antlr-dev-bounces at antlr.org] > On Behalf Of Terence Parr > Sent: Monday, September 29, 2008 1:01 PM > To: ANTLR-dev Dev > Subject: [antlr-dev] bug fix 3.1.1 release going out today > > Any issues? > > Ter > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev > From parrt at cs.usfca.edu Mon Sep 29 12:26:55 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Mon, 29 Sep 2008 12:26:55 -0700 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <48E12825.3020006@gmx.de> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> <48E12825.3020006@gmx.de> Message-ID: <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> Oh, sorry. I thought I gave warning two weeks ago that we wanted to go out soon... maybe that was just with Jim. Ok, let's go for a release this week. Sun is waiting on 3.1.1 to release the ANTLR-based Java grammar for the open JDK project. Ter On Sep 29, 2008, at 12:10 PM, Johannes Luber wrote: > Sam Harwell schrieb: >> At least the C# target runtime has not been updated for CL 5269 (the >> pushFollow bug Jim found). I don't know what impact that has; is >> there a >> regression test you've created to detect that bug? >> >> Sam > > Could I not have some more warning time? Usually you announce > something > like that at least one day in advance. If syncing is the only thing > left > I wait until such an announcement because it's easier do that in one > go. > And yes, I will do that now. > > Johannes >> >> -----Original Message----- >> From: antlr-dev-bounces at antlr.org [mailto:antlr-dev- >> bounces at antlr.org] >> On Behalf Of Terence Parr >> Sent: Monday, September 29, 2008 1:01 PM >> To: ANTLR-dev Dev >> Subject: [antlr-dev] bug fix 3.1.1 release going out today >> >> Any issues? >> >> Ter >> _______________________________________________ >> antlr-dev mailing list >> antlr-dev at antlr.org >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev >> _______________________________________________ >> antlr-dev mailing list >> antlr-dev at antlr.org >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev >> > From jaluber at gmx.de Mon Sep 29 12:40:56 2008 From: jaluber at gmx.de (Johannes Luber) Date: Mon, 29 Sep 2008 21:40:56 +0200 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> <48E12825.3020006@gmx.de> <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> Message-ID: <48E12F48.3000000@gmx.de> Terence Parr schrieb: > Oh, sorry. I thought I gave warning two weeks ago that we wanted to go > out soon... maybe that was just with Jim. You did. That was the last time I synced, but then Jim said: "No, I need some more time!" and I wasn't told when he was ready, so I wasn't sure if you, Ter, wanted to add some other fix yet. But I did check in the latest change so we can go live now (was only one file). I have to bundle the runtime files yet, but I'm working on that. I need to put this file into the runtime/CSharp/dist directory, right? For consistency reasons, can you add "-3.1.0" to the old runtime file name? I forgot the versioning there. Johannes > > Ok, let's go for a release this week. Sun is waiting on 3.1.1 to > release the ANTLR-based Java grammar for the open JDK project. > > Ter > On Sep 29, 2008, at 12:10 PM, Johannes Luber wrote: > >> Sam Harwell schrieb: >>> At least the C# target runtime has not been updated for CL 5269 (the >>> pushFollow bug Jim found). I don't know what impact that has; is there a >>> regression test you've created to detect that bug? >>> >>> Sam >> >> Could I not have some more warning time? Usually you announce something >> like that at least one day in advance. If syncing is the only thing left >> I wait until such an announcement because it's easier do that in one go. >> And yes, I will do that now. >> >> Johannes >>> >>> -----Original Message----- >>> From: antlr-dev-bounces at antlr.org [mailto:antlr-dev-bounces at antlr.org] >>> On Behalf Of Terence Parr >>> Sent: Monday, September 29, 2008 1:01 PM >>> To: ANTLR-dev Dev >>> Subject: [antlr-dev] bug fix 3.1.1 release going out today >>> >>> Any issues? >>> >>> Ter >>> _______________________________________________ >>> antlr-dev mailing list >>> antlr-dev at antlr.org >>> http://www.antlr.org:8080/mailman/listinfo/antlr-dev >>> _______________________________________________ >>> antlr-dev mailing list >>> antlr-dev at antlr.org >>> http://www.antlr.org:8080/mailman/listinfo/antlr-dev >>> >> > From jimi at temporal-wave.com Mon Sep 29 13:14:51 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Mon, 29 Sep 2008 13:14:51 -0700 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> <48E12825.3020006@gmx.de> <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> Message-ID: <1222719291.4525.12.camel@jimi.temporal-wave.com> On Mon, 2008-09-29 at 12:26 -0700, Terence Parr wrote: > Oh, sorry. I thought I gave warning two weeks ago that we wanted to go > out soon... maybe that was just with Jim. > > Ok, let's go for a release this week. Sun is waiting on 3.1.1 to > release the ANTLR-based Java grammar for the open JDK project. Well, JavaFX freezes on Friday - I would really like to have a day or two of regression tests and not switch builds on Friday if at all possible ;-) Jim > > Ter > On Sep 29, 2008, at 12:10 PM, Johannes Luber wrote: > > > Sam Harwell schrieb: > >> At least the C# target runtime has not been updated for CL 5269 (the > >> pushFollow bug Jim found). I don't know what impact that has; is > >> there a > >> regression test you've created to detect that bug? > >> > >> Sam > > > > Could I not have some more warning time? Usually you announce > > something > > like that at least one day in advance. If syncing is the only thing > > left > > I wait until such an announcement because it's easier do that in one > > go. > > And yes, I will do that now. > > > > Johannes > >> > >> -----Original Message----- > >> From: antlr-dev-bounces at antlr.org [mailto:antlr-dev- > >> bounces at antlr.org] > >> On Behalf Of Terence Parr > >> Sent: Monday, September 29, 2008 1:01 PM > >> To: ANTLR-dev Dev > >> Subject: [antlr-dev] bug fix 3.1.1 release going out today > >> > >> Any issues? > >> > >> Ter > >> _______________________________________________ > >> antlr-dev mailing list > >> antlr-dev at antlr.org > >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev > >> _______________________________________________ > >> antlr-dev mailing list > >> antlr-dev at antlr.org > >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev > >> > > > > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080929/3d8536bb/attachment.html From jimi at temporal-wave.com Mon Sep 29 13:17:35 2008 From: jimi at temporal-wave.com (Jim Idle) Date: Mon, 29 Sep 2008 13:17:35 -0700 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> <48E12825.3020006@gmx.de> <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> Message-ID: <1222719455.4525.15.camel@jimi.temporal-wave.com> BTW - all examples are updated and all tests pass, so I am ready for 3.1.1 whenever you are. Note that we need to build a 3.1.1 examples tar as none of the current examples will work with 3.1.1 headers (this is just the examples projects that I have configured to be self-contained, which means they are not intercompatiblized even though the users grammars are.) Jim On Mon, 2008-09-29 at 12:26 -0700, Terence Parr wrote: > Oh, sorry. I thought I gave warning two weeks ago that we wanted to go > out soon... maybe that was just with Jim. > > Ok, let's go for a release this week. Sun is waiting on 3.1.1 to > release the ANTLR-based Java grammar for the open JDK project. > > Ter > On Sep 29, 2008, at 12:10 PM, Johannes Luber wrote: > > > Sam Harwell schrieb: > >> At least the C# target runtime has not been updated for CL 5269 (the > >> pushFollow bug Jim found). I don't know what impact that has; is > >> there a > >> regression test you've created to detect that bug? > >> > >> Sam > > > > Could I not have some more warning time? Usually you announce > > something > > like that at least one day in advance. If syncing is the only thing > > left > > I wait until such an announcement because it's easier do that in one > > go. > > And yes, I will do that now. > > > > Johannes > >> > >> -----Original Message----- > >> From: antlr-dev-bounces at antlr.org [mailto:antlr-dev- > >> bounces at antlr.org] > >> On Behalf Of Terence Parr > >> Sent: Monday, September 29, 2008 1:01 PM > >> To: ANTLR-dev Dev > >> Subject: [antlr-dev] bug fix 3.1.1 release going out today > >> > >> Any issues? > >> > >> Ter > >> _______________________________________________ > >> antlr-dev mailing list > >> antlr-dev at antlr.org > >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev > >> _______________________________________________ > >> antlr-dev mailing list > >> antlr-dev at antlr.org > >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev > >> > > > > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.antlr.org:8080/pipermail/antlr-dev/attachments/20080929/effee73d/attachment.html From parrt at cs.usfca.edu Mon Sep 29 16:04:55 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Mon, 29 Sep 2008 16:04:55 -0700 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <48E12F48.3000000@gmx.de> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> <48E12825.3020006@gmx.de> <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> <48E12F48.3000000@gmx.de> Message-ID: On Sep 29, 2008, at 12:40 PM, Johannes Luber wrote: > Terence Parr schrieb: >> Oh, sorry. I thought I gave warning two weeks ago that we wanted to >> go >> out soon... maybe that was just with Jim. > > You did. That was the last time I synced, but then Jim said: "No, I > need some more time!" and I wasn't told when he was ready, so I wasn't > sure if you, Ter, wanted to add some other fix yet. > > But I did check in the latest change so we can go live now (was only > one > file). I have to bundle the runtime files yet, but I'm working on > that. > I need to put this file into the runtime/CSharp/dist directory, right? i guess and then I can push it on to server. > For consistency reasons, can you add "-3.1.0" to the old runtime file > name? I forgot the versioning there. Oh, i will when i scp. Ter From parrt at cs.usfca.edu Mon Sep 29 16:05:35 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Mon, 29 Sep 2008 16:05:35 -0700 Subject: [antlr-dev] bug fix 3.1.1 release going out today In-Reply-To: <1222719455.4525.15.camel@jimi.temporal-wave.com> References: <295EE52A-E1D5-43AC-85C2-01673A75E8BC@cs.usfca.edu> <86403CA0939415448BCCB83855EFE09A64E480@Bloodymary.ironwillgames.com> <48E12825.3020006@gmx.de> <653E5764-F14D-41EF-9368-0F3EA58699AB@cs.usfca.edu> <1222719455.4525.15.camel@jimi.temporal-wave.com> Message-ID: <88CDAE4D-63D6-4815-829F-1BC4FBF423B5@cs.usfca.edu> Ok, let's try tomorrow then if no objections...sounds like Johannes is ready. T On Sep 29, 2008, at 1:17 PM, Jim Idle wrote: > > BTW - all examples are updated and all tests pass, so I am ready for > 3.1.1 whenever you are. Note that we need to build a 3.1.1 examples > tar as none of the current examples will work with 3.1.1 headers > (this is just the examples projects that I have configured to be > self-contained, which means they are not intercompatiblized even > though the users grammars are.) > > Jim > > On Mon, 2008-09-29 at 12:26 -0700, Terence Parr wrote: >> >> Oh, sorry. I thought I gave warning two weeks ago that we wanted to >> go >> out soon... maybe that was just with Jim. >> >> Ok, let's go for a release this week. Sun is waiting on 3.1.1 to >> release the ANTLR-based Java grammar for the open JDK project. >> >> Ter >> On Sep 29, 2008, at 12:10 PM, Johannes Luber wrote: >> >> > Sam Harwell schrieb: >> >> At least the C# target runtime has not been updated for CL 5269 >> (the >> >> pushFollow bug Jim found). I don't know what impact that has; is >> >> there a >> >> regression test you've created to detect that bug? >> >> >> >> Sam >> > >> > Could I not have some more warning time? Usually you announce >> > something >> > like that at least one day in advance. If syncing is the only thing >> > left >> > I wait until such an announcement because it's easier do that in >> one >> > go. >> > And yes, I will do that now. >> > >> > Johannes >> >> >> >> -----Original Message----- >> >> From: antlr-dev-bounces at antlr.org [mailto:antlr-dev- >> >> bounces at antlr.org] >> >> On Behalf Of Terence Parr >> >> Sent: Monday, September 29, 2008 1:01 PM >> >> To: ANTLR-dev Dev >> >> Subject: [antlr-dev] bug fix 3.1.1 release going out today >> >> >> >> Any issues? >> >> >> >> Ter >> >> _______________________________________________ >> >> antlr-dev mailing list >> >> antlr-dev at antlr.org >> >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev >> >> _______________________________________________ >> >> antlr-dev mailing list >> >> antlr-dev at antlr.org >> >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev >> >> >> > >> >> _______________________________________________ >> antlr-dev mailing list >> antlr-dev at antlr.org >> http://www.antlr.org:8080/mailman/listinfo/antlr-dev From parrt at cs.usfca.edu Tue Sep 30 11:50:12 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Tue, 30 Sep 2008 11:50:12 -0700 Subject: [antlr-dev] 3.1.1 probably tomorrow Message-ID: <7D8C48E9-F5AE-40DE-A1DE-5A83CA8A8C51@cs.usfca.edu> got too much to do today. T From pink at odahoda.de Tue Sep 30 13:03:49 2008 From: pink at odahoda.de (Benjamin Niemann) Date: Tue, 30 Sep 2008 22:03:49 +0200 Subject: [antlr-dev] 3.1.1 probably tomorrow In-Reply-To: <7D8C48E9-F5AE-40DE-A1DE-5A83CA8A8C51@cs.usfca.edu> References: <7D8C48E9-F5AE-40DE-A1DE-5A83CA8A8C51@cs.usfca.edu> Message-ID: <543531490809301303t79b97914qee1a9c57ff9bbb32@mail.gmail.com> I just checked that the testsuite is still working and bumped up the version number. There's only one CL (5256) that might be affecting the Python target, and I'm not even sure about that. But I have to update the version number nevertheless, because I introduced a check in 3.1 that requires matching version numbers between codegen and runtime. So Python is green for 3.1.1 A small note: you could make my life a little bit easier, if you stuck to version scheme 3.1.1b1 (as done before) instead of 3.1.1-beta, because it breaks the version matching mentioned above. -Ben On Tue, Sep 30, 2008 at 8:50 PM, Terence Parr wrote: > got too much to do today. > T > _______________________________________________ > antlr-dev mailing list > antlr-dev at antlr.org > http://www.antlr.org:8080/mailman/listinfo/antlr-dev > From parrt at cs.usfca.edu Tue Sep 30 13:24:37 2008 From: parrt at cs.usfca.edu (Terence Parr) Date: Tue, 30 Sep 2008 13:24:37 -0700 Subject: [antlr-dev] 3.1.1 probably tomorrow In-Reply-To: <543531490809301303t79b97914qee1a9c57ff9bbb32@mail.gmail.com> References: <7D8C48E9-F5AE-40DE-A1DE-5A83CA8A8C51@cs.usfca.edu> <543531490809301303t79b97914qee1a9c57ff9bbb32@mail.gmail.com> Message-ID: <4AC95A2E-80A6-477E-B234-590650BA5673@cs.usfca.edu> On Sep 30, 2008, at 1:03 PM, Benjamin Niemann wrote: > I just checked that the testsuite is still working and bumped up the > version number. > There's only one CL (5256) that might be affecting the Python target, > and I'm not even sure about that. But I have to update the version > number nevertheless, because I introduced a check in 3.1 that requires > matching version numbers between codegen and runtime. > So Python is green for 3.1.1 nice. > A small note: you could make my life a little bit easier, if you stuck > to version scheme 3.1.1b1 (as done before) instead of 3.1.1-beta, > because it breaks the version matching mentioned above. Oh, yeah. sorry. It will be 3.1.1 final when we go out and i'll do 3.1.2b1 next ;) Ter