BUFFER_LENGTH cannot convert to an integer in 205?

[the bigg]

All the r/r conflicts come from that double COPY_RANDOM btw. (Parser doesn't know which rule to use when doing the empty list production.)

Yeah, I know that by removing the IWD2-ease style COPY_RANDOM this'd be fixed, but I'd rather have unharmful r/r conflicts than break IWD2-Ease.

Of course, it'd be even better if that component was simply DEPRECATED and have its code flushed (since apparently it causes all sorts of CTD by placing nonsensical item combinations all around).

For example: the a @ b operator (List.append a b) you use below is not tail recursive (stack space proportional to length of a) - if you want a faster and not crashing implementation, you need to use List.rev_append (List.rev a) b.

Yep, that's what I actually meant with "Don't know if it's slower".

I was just pointing out why stuff in OCaml can break at times - the OCaml devs don't care about making stuff that works 100% of the times, they care about writing 'clean' code.

[Taimon]

I was just pointing out why stuff in OCaml can break at times - the OCaml devs don't care about making stuff that works 100% of the times, they care about writing 'clean' code.

That's actually a problem with many academical people.

[the bigg]

After converting grammar to right associative, 8 s/r and 67 r/r (all r/r caused by COPY_RANDOM sucking pigeon cock).

EDIT: 8 s/r, 0 r/r, without breaking IWD2 COPY_RANDOM (in theory of course). Go me 

EDIT: 7 s/r after a tweak in REPLACE_TEXTUALLY blah blah (match length).

EDIT: 5 s/r after forcing parens in PRETTY_PRINT*. Will be reverted if it proves to break mods.

EDIT: 4 s/r after forbidding COMPILE without any file.

EDIT: 3 s/r after tighening the supply_tog in ADD_STORE_ITEM (which only Dev uses anyway).

*: before, you could say plain PRETTY_PRINT or PRETTY_PRINT something. Now, you have to say either plain PRETTY_PRINT or PRETTY_PRINT (something).

[Taimon]

You seem to have fun optimizing the grammar for the parser.
What about putting a comment before the rules, whose main purpose is optimization.

EDIT: 5 s/r after forcing parens in PRETTY_PRINT*. Will be reverted if it proves to break mods.

Maybe we should keep a repository with all the released tp2's to grep through them.

Weird, the forum software says 0 downloads for trealparserin.zip but I actually downloaded it a minute ago.

[the bigg]

Maybe we should keep a repository with all the released tp2's to grep through them.

That'd be useful - I have some mods ready for a blanket install for catching many things, but there are many times when I wish I could just grep for difficult constructs 
EDIT: however, after parsing, I need to install them all and compare them, to see if behaviour changed (for instance, when moving ocamlyacc -> elkhound I accidentally reversed all associativity, with a parse check wouldn't have caught).

Weird, the forum software says 0 downloads for trealparserin.zip but I actually downloaded it a minute ago.

I've updated it about 30 times since your download (and I'm uploading it to the beta directory). By the way, would you be interested in having access to the beta forum? It means some slave work every six months or so, and your requests will be prioritized 

[Taimon]

By the way, would you be interested in having access to the beta forum? It means some slave work every six months or so, and your requests will be prioritized 

If you think I can be useful there, sure why not.

About Nythruns v204 vs. current tp2 parsing: v204 did not have the old parser wrapper, so could be related to the ocamlyacc parser.

[the bigg]

PM sent to JCompton. The forum will be available here once you're added to the list.