[antlr-interest] java.g does not compile

[Jim Idle]

I wouldn't change the default time out as then your project depends on a custom version of NATLR for no good reason. That was just my 6:40AM typo of course :-)

I have a QX9450 and some i7s. I think that the Xeon server versions of 9450 etc might be slower on a single thread. I think a lot of the i7s are faster than Xeon? However I haven't bothered with Xeon myself. But, it depends what you are measuring. Most of the published benchmark programs are worthless.

Jim

> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Thursday, January 21, 2010 6:51 AM
> To: Jim Idle
> Cc: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] java.g does not compile
> 
> On 01/21/2010 02:40 PM, Jim Idle wrote:
> 
> > You are probably right on the limit of the default 10000, or perhaps
> > you are not compiling the exact original?
> 
> I haven't touched it.  Honestly!
> 
> Besides, the default seems to be 1000, not 10000.
> 
>  $ java -jar Downloads/antlr-3.2.jar -X
>   -Xconversiontimeout t   set NFA conversion timeout (ms) for each
> decision          [1000]
> 
> I changed it to 10000, and all is fine:
> 
> --- antlr-3.2/tool/src/main/java/org/antlr/analysis/DFA.java~   2009-
> 09-23 19:36:06.000000000 +0100
> +++ antlr-3.2/tool/src/main/java/org/antlr/analysis/DFA.java    2010-
> 01-21 13:08:32.625782840 +0000
> @@ -53,7 +53,7 @@
>          */
> 
>         /** Set to 0 to not terminate early (time in ms) */
> -       public static int MAX_TIME_PER_DFA_CREATION = 1*1000;
> +       public static int MAX_TIME_PER_DFA_CREATION = 10*1000;
> 
>         /** How many edges can each DFA state have before a "special"
> state
>          *  is created that uses IF expressions instead of a table?
> 
> > Try the on in the examples zip and see if there are any
> > differences. However, Xeon's are not as fast as you think on a
> > single thread which is what the analysis phase runs on by default.
> 
> Err, how on Earth do you know how fast I think Xeons are?  :-)
> But anyway, most users aren't likely to have anything hugely faster.
> 
> Andrew.