Welcome to the ZDoom Forums!

by **randi** » Tue Jan 24, 2012 8:59 pm

It sounds like you had a bad experience, then. I had a class one semester that focused heavily on grammars, and I found it rather fascinating. I think there might have been other things covered in the class, but grammars are what I remember most from it. I'm not sure if we messed around with parser generators for the class or not, but I do know that I played with bison on my own time as a direct result of that class.

Graf Zahl wrote:the guy who wrote this apparently doesn't do enough promotion.

It seems like it's probably a case of he wrote it specifically for SQLite's parser, and as long as it gets that job done, that's all he's really interested in. After all, if you want to get it, you have to dig it out of SQLite's source tree. At least he was nice enough to make it all self-contained without any dependencies on other parts of SQLite.

by **Zippy** » Tue Jan 24, 2012 4:30 am

Graf Zahl wrote:The only problem I encountered with this stuff is that the apparent default of flex/bison is a piece of utter crap and the generated code basically impossible to use out of the box, mostly because it's all set up the wrong way which creates a total mess of dependencies, global variables and other not so nice things like memory leaks. I can fully understand why people would throw up their hands in despair and conveniently forget about the whole thing.

In all honesty this is pretty much exactly what happened. I think we were given two weeks to learn and master the technology on our own after a little lecturing and then create some kind of mini-programming language supporting such and such operations, etc., because it was part of a course that covered multiple languages in rapid succession over a ten week time period. In retrospect, I'm pretty sure that setup was a horrible idea. It's the kind of topic that could use a bit more than cursory coverage.

I've pretty much never looked back after putting that behind me.

by **Graf Zahl** » Tue Jan 24, 2012 3:48 am

Weird. I had no problems with this stuff when I first got into it (which was for merging XLATCC into ZDoom itself. I find it's a very elegant way to simplify some otherwise complex work.

The only problem I encountered with this stuff is that the apparent default of flex/bison is a piece of utter crap and the generated code basically impossible to use out of the box, mostly because it's all set up the wrong way which creates a total mess of dependencies, global variables and other not so nice things like memory leaks. I can fully understand why people would throw up their hands in despair and conveniently forget about the whole thing.

Lemon is completely different from that and outputs a nicely encapsulated module that is easy to use and maintain - and it got a much better definition syntax. Strange that people still use the crap default to such a large degree when there's something so much better. But well, old habits die hard and the guy who wrote this apparently doesn't do enough promotion.

by **Zippy** » Tue Jan 24, 2012 12:28 am

Gez wrote:
randy wrote:
Gez wrote:Unfortunately, xlat uses lemon and it's crazy complicated to make lemonade out of it.
What makes you say that? This is exactly the sort of thing that a good parser generator makes very, very easy to do. (And now it's done.)
Mostly, I don't understand how it works at all.

This has always been my problem. Maybe the professor who originally explained it to me was a little off the mark, or maybe the assignments just weren't the right ones. But whatever the case, it broke my spirit forever. Every look at parser generation is a reminder of sleepless times. Of nights spend strained and drained, exhausted and beaten by an unseen foe. His invisible hand strikes me from beyond the veil. And to try and glimpse him... is like staring into infinite agonies, a waking nightmare of unending pain. Tokens! Tokens screaming in the night! Can't you hear them?! Drowning in a sea of collapsing regular expressions! They're calling for me... they want to drag me under, to choke me out until I am joined with them forever in the darkness!

Oh, Light! Oh, Salvation! Keep this evil at bay!

by **randi** » Mon Jan 23, 2012 6:23 pm

The total time spent on it was less than two hours, and it was fun, so it's really no big deal.

by **Graf Zahl** » Mon Jan 23, 2012 6:16 pm

Oh my!

This got to be one of the most useless features in ZDoom ever...

Was it really worth this amount of work to add? How many people actually use Doom format maps with such extremely specialized line types.

by **Gez** » Mon Jan 23, 2012 3:32 am

randy wrote:
Gez wrote:Unfortunately, xlat uses lemon and it's crazy complicated to make lemonade out of it.
What makes you say that? This is exactly the sort of thing that a good parser generator makes very, very easy to do. (And now it's done.)

Mostly, I don't understand how it works at all.

I once wanted to be able to translate thing types, so that for example thing #47 would become thing #89. This could be used to deal with some compatibility problems with conflicting doomednums.

by **Xaser** » Mon Jan 23, 2012 12:49 am

Quick bumpdate -- I've given it a test and it indeed works just as planned. This is gonna prevent a lot of silly duplication.

by **Xaser** » Sun Jan 22, 2012 10:38 pm

Looking at the changelog, it appears so. I'll give it a try presently.

Mighty fine thanks, sir. The Hacx team salutes you.

by **randi** » Sun Jan 22, 2012 10:34 pm

I think what's present now should exactly fit your needs, yes?

by **Xaser** » Sun Jan 22, 2012 6:53 pm

Hmm, after discussing it in IRC with Blzut3 and DavidPH, I don't think it'll work yet. I'm actually trying to solve a different problem from the aforementioned mirror issue now, and it involves extracting individual digits from the tag field, e.g. (tag/10)%10, which would unfortunately require both modulus and multiple operations. That would involve diving into the rewrite, I'm afraid, since this is the only way I know of to avoid having to define Polyobject_StartLine twice in the map (one for ZDoom and one for EE), which would make my planned ExtraData helper DB2 plugin seem rather useless on its own.

I almost feel as if I should try and code this myself considering how special-use it is at the moment, but my only real experience with parser writing was a bit of frustrating keyboard-bashing with lex and yacc that yielded an unusable program. Think I would've preferred it if life had handed me lemon that day.

by **randi** » Sun Jan 22, 2012 6:27 pm

Okay, that's reasonable enough. You can now use any of xlat's existing operators with tags (with the caveat that the left-hand side must be tag and the right-hand side must be a constant.)

[Also, you are a ninja poster.

]

Is bit-wise AND good enough, or do you need modulus? The lexer being used doesn't recognize %, so it would be more work to add that. (That's not code I wrote, so I'm not sure how involved it would actually be.) Is it good enough that you can only use tag on the left of the operator? Changing that could be done, but it would be more involved, since xlat is currently set up such that all expressions can be evaluated at parse time, so the parser can do it itself and hide the details from the line translator part.

by **Xaser** » Sun Jan 22, 2012 6:26 pm

Actually, a division/modulo method might be a bit more in line with what I'm doing if I could get a certain something working on Eternity's side. Might actually make it easier in a way.

What I'm actually trying to do here, for the record, is use ExtraData on Eternity's side to set up a bunch of polyobject door specials by treating the tag field as a flag-list of sorts to pass parameters. The lowest two digits are the tag and the upper three represent different special options like direction, door length, angle, etc. Interestingly, since ExtraData is a definition language rather than a scripting one, this ends up translating to having a megahuge number of lines (~10,000 or so) so I needed to write a perl script to generate the file. Talk about some serious stretching.

Anyhow, thanks so much for adding this, Randy. Just noticed you sneak in some more operators in the changelog as well. Guess the improved version is still on.

by **Blzut3** » Sun Jan 22, 2012 5:44 pm

Just a thought, wouldn't division and modulo be more useful operations? Consider Polyobj_StartLine(tag%256, tag/256, 0, 0) would allow 255 poly objects to be defined with any combination of mirroring. I think this would solve Xaser's missing mirror problem too. (Alternatively tag&255 and tag>>8 of course.)

by **randi** » Sun Jan 22, 2012 4:57 pm

Gez wrote:Unfortunately, xlat uses lemon and it's crazy complicated to make lemonade out of it.

What makes you say that? This is exactly the sort of thing that a good parser generator makes very, very easy to do. (And now it's done.)

BTW, the original xlat parser was written for bison and was later ported to lemon to make it easier to build on non-Unix boxes. (That lemon is a better generator was a minor consideration.)

Welcome to the ZDoom Forums!

XLAT -- Dynamic (?) Tags

Post a reply

Expand view Topic review: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags

Re: XLAT -- Dynamic (?) Tags