Learned something new!

The kata's description is horrendously lazy. And it leaves a lot of specs out of the table, even in the context of the linked Wikipedia article:

• Which version of the LZW do we need to implement? There are two versions listed in the linked Wikipedia article (fixed 8-bit to 12-bit, or the variable width version), but the kata does not mention which version it desires.
• What unit are we compressing? Characters, or bytes? Note that most LZW implementations process bytes and not characters. Meanwhile, there are no restrictions on the input string, so it can contain non-(extended) ASCII characters, which cannot be expressed in 1 byte, and has to be explicitly encoded; depending on the encoding they give different bytes. The tests doesn't contain anything other than [A-Z# ], but this is really because the tests are too lazy.
• Speaking of which, the return result should really be an array of integers, not a joined string. This prevents the kata from being translated to other languages.

There are no tests that validate stop is handled correctly. Every test can be passed by processing every character except the last (and ignoring stop altogether).

I like the flow of this task.

It is just lovely!

Going to solve more tasks of the author.

Thank you.

Nice kata! There is a typo in the sample tests, at the group by section: query().select().from(persons).groupBy(profession, name).execute() [i.e., SELECT * FROM persons WHERE profession = "teacher" GROUPBY profession, name]. There should be no 'WHERE' I asume.

Well I have another pending translation that seems to be lost in the nether because I couldn't convince any Rust people to review it, so I thought I'd have a better chance doing something in Python. xd

I did see the other fork, I'll double check but I'm pretty sure I also fixed that typo (and others) in my translation. I'll spend some more time double checking my random test generator when I get a moment and see if I can find convince someone on the Discord to review this.

You certainly picked an ambitious target for your first translation. I'd suggest getting a thorough review from someone proficient in writing kata in Python, i.e. not me.

Probably needs forking; the description was changed for below solved issue.

Fork approved. ( You may want to ask Hobs for the mender role. )

Python translation

Implemented random tests to match o2001's implementation as much as possible.

I made a typo in the description; the error thrown should be of the form "duplicate [query]" not "duplicated [query]". Otherwise, everything is good to go. While at it, I've added clause order tests to the fixed tests so the users don't have to wait till random tests to discover problems with their implementation. Fork here

Approved

Fork of the original JS version:

1. Adds random tests, with near-complete coverage of requirements, within reason.
2. Clearly shows a stringified version of each query on fail to help with debugging.
3. Formalizes requirements. Right now, the requirements are unfortunately too vague - dramatically different solutions pass alike. For example, my original solution assumes having only accepts a single function, and it passes, while the author's intention was having accepting arbitrarily many functions. Based on the author's solution, I have put an addendum in the description to standardize the requirements.
4. Exception message comparison is case insensitive now.

I have kept the author's solution as the submission solution and have put my revised solution (which I have tested against the author's on dozens of thousands of runs and they match every single time) as the reference solution in the random tests since it's more compact and to cross-verify. Please review this fork and tell me if anything needs to be tuned. Adding random tests to this kata was a huge undertaking and took a long time to get right, but I believe it's bug-free by now based on the hundreds of thousands of tests I've run.

Great Kata! Finally solved it, and my solution isn't that bad.

Just tried the go version, I'm pretty sure your solution is just inefficient.

There are more than 417 tests in the Go version. If your solution takes around 2500ms (not including the compile time) for only one time test of n=550, I'm pretty sure it's not good enough. The reference solution itself took only around 0.15ms - 0.19ms for that input.

Try another approach.