@Melpomene said:
@Chime If you ever get around to doing that, gimme. π
@Thenomain tells me I need to give him a hardcode @whence command first. (tells you where the command you specify is defined, which is rather unexpectedly useful for taking a quick look at whatever bug people are complaining about today...)
Have you got that vtables function documented anywhere? I would've used it if I'd known you didn't have to specify column widths, but the code I found didn't include documentation and taking apart someone else's code is always a PITA. I just want to know what format it expects things in.
I had it beautifully expanded and documented on WORA. sigh.
Really, what you see is what you get.
vtable( LIST ) is expected to work for simple cases; the 0-default column count will decide on its own what a sensible column count for the data and screen is.
I found myself (mostly out of sheer "I CAN code so I WILL code!") making the equivalent of vtables in a different way: it expects a string formatted with two delimiters like so: a|b|c|d~e|f|g~h|i|j|k|l~m|n|o~p|q|r|s|t~u|v|w~x|y|z - and the two delimiters, and it outputs the whole set as a list of columns, fitting them to whatever width is available.
One of the MUSH codebases had a hardcode format function (of some name) that looked much like that. Probably Penn or RHOST.
Gimme if you've got it, reinventing the wheel is fun but I'm not sure I'm doing the world any good. π
If you can use it from what I've explained already, you're welcome to it. If not, well, it's broken and you get to keep both pieces.
@Arkandel said:
Sometimes you have a problem. You figure you'll use a regex to fix it. Now you have two problems.
(says someone who uses regexes every day. π )
They are quick and effective, but for anything of significant complexity, I prefer language that allow easy expression of more complex parsing algorithms. Yes, C/C++ has flex/bison (or lex/yacc if you are truly desperate and your time machine is stuck in the 70s or something). Java has ANTLR, or whatever. Those are effective if you're trying to write a compiler, but tend to be a bit clunky and I've found there is a very large functionality gap between "I'm writing a compiler with multi-file contextual grammar." and "heyyy a few regexes will do fine."
The sweet-spot seems to be language that can readily express simpler recursive-descent or similar parsers without having to break into a whole new language (like bison does). Haskell's Parsec and AttoParsec modules do a fantastic job of fitting exactly into that niche-- especially when combined with the applicative functors module. Being able to add recursive grammar for handling string escapes and other important details make for a huge functionality improvement over more primitive systems like regexs.