On 08.12.25 11:54, Dave Kemper wrote: > On Mon, Dec 8, 2025 at 5:04 AM dvalin--- via GNU roff typesetting
> system discussion < [email protected] > wrote: > > It'd be quite a while before I could find round tuits to > > figure out git to grab the source > > Getting the source code onto your machine from git is a one-step > process (assuming you have git itself installed already). > > git clone git:// git.savannah.gnu.org/groff.git ( > http://git.savannah.gnu.org/groff.git ) > > You can also view the source in your web browser, if you want to look > at files but not put anything on your system. > > http://cgit.git.savannah.gnu.org/cgit/groff.git/tree/ For a quick look, that was handy. Thanks. At first glance, the problem line looks fairly safe, as ORDINAL and LAST are both tokens, and object_type is a choice of tokens, so it falls to relative_path to cause the conflicts. (I've had a simple subrule do exactly that, but will omit the example for brevity.) Adding "-v" to the bison invocation should elicit some details of the conflicts. Here is an example I ran into in one of my parsers: State 135 conflicts: 1 shift/reduce # Then at state 135: state 135 83 spindle_mode: MODE '=' CSS $@5 . css_options <-- The grammar rule. REVS shift, and go to state 137 SPEED shift, and go to state 138 <-\ The SPEED [reduce using rule 88 (mrevs)] <-/ conflicts. css_options go to state 139 mrevs go to state 140 sspeed go to state 141 « So SPEED is the culprit there - it wants to shift *and* reduce. In short, use "-v" to locate the problem rule's problem state, with the conflict hopefully apparent. The tricky bit is cleaning that up. One technique which has worked for me is flattening the grammar. Even simple subrules can be trouble at times. Maybe time can be found to install and dig deeper, but the excavator arrived, and I have ATmega328P code to write & debug, as well as the tractor shed to build. It'll be slow going. If anyone manages to spit out a "-v" conflict printout, then I could take a look. Erik
