What language are you using? What bug have you experienced?

There's an bug in the initial solution.

For some reason, the random tests in the C# translation almost never fail, and you can return pretty much anything. I was able to submit a solution that has hard-coded return values for the three visible test cases, and just returns 0 for all other tests:

https://www.codewars.com/kata/reviews/5e5904021cff490001cdb237/groups/64ca1a6ca9a9ec0001fc2fb8

I'm still confused about arrays in C and assembly, I had some trouble with this.
In C it behaved like a standard 2D array, but in NASM I had to dereference rdi to get a pointer to the array. (I expected rdi to point to the first element in the array).
Is this what usually happens?

You're removing those numbers from the input, so, when the control function calculates its sum, it's using the other numbers: 136 + 128 + 83 = 347 Anyways, I've changed the tests so the expected value is computed first and your code messing with the input isn't a problem anymore, but be aware of that.

Thanks for the reply but I don't understand. The description says, "your task is to find the sum of the minimum values in each row."

As I understand it, the minimum values of each row in the above test are 49, 82 and 17, of which the sum is 148, not 347. What am I missing?

Don't mutate the input.

All of the random tests failed for me. One of the tests tested for [[49, 136],[128,82],[17,83]]. It failed telling me 'Expected 148 to equal 347'. So 49 + 82 + 17 = 347? Or have I grossly misunderstood something?

approved

Approved

.. a mess

I fully agree. :/

That's definitively a mess. I'm not favorable to hold off new translations, fixing merge conflicts when they happen is fine (it's easily done, anyone can dot it, and we are, unfortunately, used to it).

There will be a merge conflict.

The merge is based on the description on the moment of forking. If that changes between fork ( cq. creation of translation ) and approval, you're OOL, even if you have the same description as the current one.

If a translation that changes the description is waiting, hold off on starting new translations.

( As I understand it. )

COBOL translation. I took the unified description from Haskell translation (see below), so as far as I understand the merge process, there should be no merge conflict.

Haskell translation

This translation unifies the description. Languages that do not comform to these specs should have their testing updated, not the specs.