Added to description.

Added to the tests.

Oops, fixed that, and also added the double threat test to the default test fixture.

Also needed to update the comments on the code that was given to the user, which were at odds with the description and tests.

I've updated the kata for multiple threats, you should now return an array (even for threats of one). The order of pieces returned in multiple threat scenarios should not be a problem.

Also added a situation where the only way to avoid a mate is to perform an en passant.

Also had to backtick the coffeescript solution once again, since I don't have time right now to handle it properly.
Edit: now available in pure CS again.

Oh, right, I tried to think of a situation where there would be more than one threat but couldn't think of one, I'll add it now.

As for en passant, I thought about it but didn't implement it. I think I'll add it as additional properties for the piece that moved previously, which would make it possible to check for it as well.

I didn't have a single timeout with my code during the edit phase. Of course it might be possible that they allocate more processing time when you run it in the kata editor, but I doubt it, as it would be possible to make katas that timed out with the correct solution.

I'm not familiar with Ruby, and at this moment do not have time to familiarize myself with it, so without external help (for which you of course would be credited) this Kata will not be available in Ruby.

My first kata submission, hopefully I didn't make too many mistakes with it.

In case you notice that I forgot a test case for something important, please do notify me, I don't play chess much and might have overlooked something fundamental.

Edit: reformatted the back-ticked JS solution to authentic coffeescript (with few changes to the actual code, though).

I guess I read the description too fast, because I assumed automatically that the j-i should be such that every data[i..j] <= data[j], which would also give 2 for [1,2,3]. Adding a less ambiguous example, such as given by GuardianGI, would make it a lot clearer.

I suggest adding

Test.assertSimilar(transpose([[1,2,3],[4,5,6]]), [[1,4],[2,5],[3,6]]);

to the user's default test fixture. transpose([[1]]), while important, doesn't really make a good overall test for the user.

Also, adding a random input test case might be useful.

I agree that it should be documented what the "param" value will contain, especially since there's no default test fixture where you could check the parameters out.

That said, this kata is rather ungainly. Rather than a "key=value" given as param, a more useful implementation would give a hash with multiple key-value pairs. I don't think it would even affect the kata's difficulty by much.

I think random tests would work well with this kata, though the current tests seem to cover everything.

The CoffeeScript version of the initial code body is bugged, currently

solution(str) ->

but should be

solution = (str) ->


I'd like a way to open my profile page to the public. It'd make an interesting addition to my online CV, and I really can't see anyone creating an user here just to view my profile based on a CV.

Also, a possibility to be able to create a small banner or such that would show the users rank in codewars could be fun.

In addition, when you try to view a profile without being logged in, you get a 500 error page, which is slightly mystifying. In case it's not a bug, please consider making it into something more informative.

Right, sorry, this was my bad, I didn't realize the tests were divided into different categories, and it was some test on the second category that caused an infinite loop (probably nested quotes).