Kata

Hi, thanks. Looks good to me. Submit it here (so that you get the credit) and I'll accept it

No problem.

in JS in random tests first line sometimes lacks one last space so it is wrongly padded. Is it intended ? Looks like a bug for me

I do think it's a bug

       ww      mmqpsw      
pszwbw|--|swzd|------|qpbwb
LLLLLL|LL|LLLL|RRRRRR|RRRRL
'LLLLLL|LL|LLLL|RRRRRR|RRRRL' should equal 'LLLLLL|LL|LLLL|RRRRRR|RRRLL'

Added this to fixed tests

Which mechanics would you like to be covered in a walkthrough?

• Joining forces when entering the trench?
• Joining forces again after a successful attack?
• Equal power between defender and attackers?
• The first letter in the trench attacking with "no more points than usual"?

Other cases seem to be already covered.

Yes those are good examples, keep them very small, so users could see the effect of these cases. After adding these cases, this kata can be approved.

As I think more about it, I think I'd prefer to edit the sample tests instead of bloating the description. Minimal examples don't really need a step-by-step walkthrough, as they only consist of 1-2 steps. What if I just minify the sample tests and give them descriptive names that directly reference the tested mechanic? For example, I'd turn

    @test.it("They never leave the trench")
    def they_never_leave_the_trench():
        check_solution("     s\n"
                       "mmmm|-",
                       "RRRR|L")

into

    @test.it("Should not attack from the trench")
    def should_not_attack_from_the_trench():
        check_solution("  s\n"
                       "m|-",
                       "R|L")

Would that be enough?

I believe so yes

You mean "If it survives, then that's enough of advantage"? Added that to the C version. Later I'll do renaming/minimization as discussed

There were enough cases to get approved. You may always add more cases if you wish to.

I've edited the description. Let me know if the issue is resolved or suggest how I should improve it further.

if letters join attack force on the ground, will they be split up again once they start going into trenches?

No. Old wording: "attackers [...] continue to attack or join forces with allies. This includes going from the ground deep into the trench". This was hidden under "If defending letter has less power than the attacking letters", so I've extracted the last sentence and merged it into the general rule about never leaving trenches: "While joining forces or attacking, letters can stay on the same level or go down into a trench, but they never leave trenches. They stop at the right end of the trench, and the next letter on the ground starts a new chain of attacks".

if a defender defeats an attacking letter in the trenches, will any other attacking letter to the left of the defeated letter start attacking the defender, or will we proceed from the defending letter to the right?

All letters to the left will attack. In my mental model, this is a single attack by a group that has joined their forces beforehand. Added rule that enforces the "beforehand" part: "Letters act in order, from left to right".

attacking group enters trenches, and there are some of their own in there .. can they ally?

Yes. See my first answer for references.

should those troopers in the trenches attack first, one by one, before the entering troops attack the remaining enemy forces in the trenches?

No. Letters to the left of the trench should act first, i.e. enter the trench. Added rule that enforces this: "Letters act in order, from left to right".

that's good, but since there is whitespace in your input strings it makes it hard to spot in the messages. you could enclose the string within quotes and insert a newline before and after it , i.e. :

..."\n\"%s\"\n", input, ...)

A question though (I have not solved the kata and I cannot see C translation, so I cannot check by myself): the returned value is going to be a pointer to a what, exactly? Are you sure it should be const char*, and not char*?

Note that a dynamically allocated, freeable buffer probably should not be returned as const, because it won't be possible to pass it to free without casting the constness away.

It's supposed to be freeable. I'll remove the const

Generally, the setup of C version is... far from ideal.

If I get the rules correctly, the length of the output is perfectly known upfront. If so, why dynamic allocation in the solution would be even needed? Passing in a preallocated output buffer would be much better, and would make tests much simpler.

If, for some reason, the solution would still be expected to return a dynamically allocated buffer, it should be somehow explained (for example in a comment in the solution setup). The statically allocated example answer is additionally misleading. On top of that, tests leak and pretend it's fine only because they created the problem in the first place :)

My suggestion would be to provide an output buffer preallocated by tests. If author does not like this suggestion and dynamic allocation is going to stay, this requirement should be documented, misleading example should be removed, and leaking tests should be fixed.

I prefer to keep the function interface without an output buffer parameter. Dynamic allocation could be indeed avoided, but I don't think that it's an issue.

I agree with you about misleading static example, though. It will be fixed soon, as well as leaking tests. I'll also add a note about dynamic allocation to the description.

I prefer to keep the function interface without an output buffer parameter. Dynamic allocation could be indeed avoided, but I don't think that it's an issue.

It always makes me wonder why C authors prefer such approach. In cases like this kata (i.e. when size of a result is known upfront) I cannot see a single advantage of it, and I can see many disadvantages. I cannot help but wonder what makes dynamic allocation in a solution so attractive to authors, as all it does is creating obstacles.

I am not going to override your decision in any way, but I would like to honestly ask you to honestly reconsider and see if you can come with any honest argument supporting currently preferred approach.

what are the disavantages ? the user can still write out-of-bounds,forget to nul-terminate, allocate arbitrary memory in his solution and not free it, and so on

I know that not all of below apply to Codewars kata, but it's good to keep general picture also in mind, is it? Requirement to allocate in a solution sucks, because:

1. It makes design of tests more difficult. You need to free after every test case, instead just allocate on stack (or heap for really large cases) once at the beginning and forget. At least try it, and you will hopefully see how much simpler it is to write tests.
2. It causes bugs and sloppy coding. Just see initial version of the translation, which leaked because "well, meh"
3. It's unnecessary, additional requirement which is limiting the scope of possibilities. It incurs a penalty on callers which can be avoided without any additional cost. You force both callee and caller to do something what they would not otherwise have to do.
4. I think that requirement of allocation is more difficult to document than just "fill this buffer"
5. It's not idiomatic in C. Just count amount of standard C functions which accept preallocated buffer vs functions which allocate dynamically.
6. It makes design of a solution difficult. How do you report allocation failure, or any other kind of failure?
7. Dynamic allocation in a solution is not universal and it makes callee to do something what caller might not want to. Caller cannot use stack allocation, nor memory pool, nor anything what they could decide how to handle. Systems where dynamic allocation is forbidden are a thing. For many, a function which allocates by itself, without a control from its caller, is a no.
8. There are setups when such function could not be exposed from a library. Sometimes, malloc from a callee cannot be matched with free by a caller. malloc and free are not always symmetrical.
9. Dynamic allocation has performance disadvantages, and dynamic allocation of many small buffers has more performance disadvantages. Why enforce them, when they can be avoided.
10. Dynamic allocation in a solution of a kata is usually a misguided attempt at making the solution similar to ones from high-level languages. malloc in a solution is a Java or Python cliche.
11. ... probably something more I cannot remember from the top of my head...

I know that dynamic allocation in a callee has its place, but I just think not in this case. I am aware that some of above points apply to Codewars kata, and some not, but why should we lose a view of a general picture? And still, I cannot think of even a single one advantage.

Thank you for the attention. I've updated the description of input terrain, groups and attacking. About your examples in short:

1. Whitespace in between letters can't happen, the only possible delimeters are single'|'s
2. This is valid, grouping depends on the exact latters and could be anything from rr|rr|r to scattered lr|rl|r. The last letter won't be able to get any power boost from allies in the trench, though.
3. Same as 1, can't happen
4. Input is always "well-formed" and can contain any amount of alterating trench and ground sections (starting with whichever). From a plain surface to this most aggressive form. Your example is "well-formed".

   "  w   w  "  "\n"
   "w|-|w|-|w"
   

   Is the issue resolved?

I had no simple idea for deciding the attack direction and the kata seemed complicated enough as it is. If you have a good idea, we can make a part 2!

that actually doesn't change much: compute everything in every direction, resolve everything at the same time, look at what's left. Curently, you're computing step by step, the result of one step affecting what might happen in later steps. No?

Yes, currently it's step by step. But I don't understand what do you mean by

compute everything in every direction, resolve everything at the same time, look at what's left.

in relation to this kata. Sounds like a very dirrerent approach that wouldn't support chained attacks, etc.

Yeah, it's probably me but having examples of a first line defender winning (with and without bonus) would have helped. ^^