Fail fast

[dberry]

Etienne,

In trying to implement a subset of the SQL2011 grammar I came across a situation where sablecc is trying to resolve some shift reduce conflicts on its own. It took around 90 minutes and I had to bump the heap up to 2GB just to get it to tell me I had 3 shift/reduce errors. The grammar as defined is not LALR and I started with 34 s/r and r/r errors. I got it down to 9. Both the 34 errors and 9 errors came back relatively quickly. I modified the grammar again and this is when sablecc started taking 90minutes and lots of memory just to tell me I still had 3 s/r errors to correct. Is it possible to put in a fail fast flag where sablecc won't try so hard to solve the problem on its own?

The subset of the grammar has around 1000 tokens and productions. 

Thanks,

Dave

[Etienne Gagnon]

Hi Dave,

I have good news for you. SableCC 3.x does have two command-line options to control inlining:

• --no-inline: completely disables inlining
• --inline-max-alts number: do not inline a production if it has more than [number] alternatives (default: 20)
  

When SableCC inlines a production, it causes the number of alternatives of remaining productions to grow exponentially. The second option limits this growth.

I think that the --no-inline option match your proposed fail fast option, but I suggest that you first play with the other option. Inlining does get rid of many little annoying conflicts. Personally, I consider that it's a better use of my time to fight the big conflicts that usually hint to ambiguities in my grammars.

Have fun!

Etienne

Etienne Gagnon, Ph.D.
http://sablecc.org

On 2012-07-28 15:04, dberry wrote:

[dberry]

Good news and bad news.

Good News: --no-inline pointed me directly to a production that was missing a non-terminal. 

Bad News: with the corrected production I get a RuntimeException

java.lang.RuntimeException: 

at org.sablecc.sablecc.GenParser.caseStart(Unknown Source)

at org.sablecc.sablecc.node.Start.apply(Unknown Source)

at org.sablecc.sablecc.SableCC.processGrammar(Unknown Source)

at org.sablecc.sablecc.SableCC.processGrammar(Unknown Source)

at org.sablecc.sablecc.SableCC.main(Unknown Source)

[dberry]

Looks like the runtime exception was there before as well. 

[Etienne Gagnon]

Hi Dave,

Are you using SableCC 3.4? I thought that I enabled debug information in the 3.4 jar (for a more meaningful stack trace on errors).

I'd like to debug this. It would really help me if you sent me a grammar that exhibits the bug.

Also, it would be useful if you could report what happens if you try compiling your grammar with SableCC 2.18.2 (without CST->AST transformations). In theory, SableCC 3.x --no-inline should be equivalent to SableCC 2.x.

Etienne

Etienne Gagnon, Ph.D.
http://sablecc.org

Le 12-07-30 16:02, dberry a écrit :

--
-- You received this message because you are subscribed to the SableCC group. To post to this group, send email to sab...@googlegroups.com. To unsubscribe from this group, send email to sablecc+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/sablecc?hl=en
 
 

[dberry]

I was still using 3.3. Here is the 3.4 output:

java.lang.RuntimeException: 

at org.sablecc.sablecc.GenParser.caseStart(GenParser.java:251)

at org.sablecc.sablecc.node.Start.apply(Start.java:37)

at org.sablecc.sablecc.SableCC.processGrammar(SableCC.java:279)

at org.sablecc.sablecc.SableCC.processGrammar(SableCC.java:170)

at org.sablecc.sablecc.SableCC.main(SableCC.java:136)

In sablecc-2.18.2 I get a run-time exception as well but no stack trace. I am also getting the same two reduce/reduce errors as well.

2.18.2 output:

reduce/reduce conflict in state [stack: TTSelect PBooleanPredicand *] on TTIs in {

[ PBooleanPrimary = PBooleanPredicand * ] followed by TTIs (reduce),

[ PRowValueConstructorPredicand = PBooleanPredicand * ] followed by TTIs (reduce)

}

java.lang.RuntimeException: 

reduce/reduce conflict in state [stack: TTSelect PBooleanPredicand *] on TTIs in {

[ PBooleanPrimary = PBooleanPredicand * ] followed by TTIs (reduce),

[ PRowValueConstructorPredicand = PBooleanPredicand * ] followed by TTIs (reduce)

}

[Etienne Gagnon]

Hi Dave,

SableCC always throws a runtime exception when it finds a conflict. What surprises me is that SableCC 3.x it doesn't tell you about the conflict. The SableCC 2.x behavior is as expected.

I would really like to get a grammar that can reproduce this SableCC 3.x bug!

You have an annoying little reduce/reduce conflict in your grammar; the kind of conflict that inlining eliminates easily. To get rid of it, you'll have to inline (by hand) the boolean_primary and row_value_constructor_predicand productions.

Have fun!

Etienne

Etienne Gagnon, Ph.D.
http://sablecc.org

On 2012-07-31 07:54, dberry wrote:

I was still using 3.3. Here is the 3.4 output:

[...]

[Etienne Gagnon]

Hi Dave,

I've discovered a subtle inlining bug in SableCC 3.x that I fixed in SableCC 3.6. As you have not provided me with an example to reproduce your problem, I can't determine if it also fixes your problem. Could you try the new SableCC version and tell me what happens?

Thanks,

Etienne

[David Berry]

Etienne,

Sorry for not getting back to you. I was getting the list of conflicts with the exceptions in all cases. I had not originally included the conflicts in the message I sent you. So From your explanation sablecc is performing as expected. That being said, I will work with your new version to see how it goes. 

Thanks,

Dave