1: I don't necessarily think exit should end in \n, depends a bit on other choices though. this issue is about that \n is missing between all messages, it never gets sent ever.

2,3: does such a guarantee actually exist? to my (flawed) understanding the kernel will split it into packets however it pleases. a send call is not a frame, not even with short bytestrings.

4: start server exactly once, attempt to connect on both ports and see which sticks and continue to use that one without closing it

6: if it's not about framing then it probably shouldn't act on frames. so no \n at all. or if it is to act on frames, then they need to actually be used. one or the other. if the \n have meaning then there has to be a buffer. if there's no buffer, then \n have no purpose and mentioning them in the description becomes weird.

7: solver shouldn't debug test code or even have to question it. if the tests need more logic to behave well then so be it.

I'm also not at all convinced by that exit check being correct. I'd be looking for some kind of polling with a timeout here, continuing to call recv until it gives an empty response for example. I'm not happy with things that merely "seem to work"

waiting on solution threads to exit also needs timeouts. the user isn't told this is happening, so it needs to be well behaved. alternatively, don't wait, and change them to daemon threads, that way there isn't a hidden unspecified test that times out on fail.

hi hi, I got a bit of time to take a look.
ill go one by one if you don't mind, here is my current fork: https://www.codewars.com/kumite/684460b1f26fb0ebd9a46199?sel=684460b1f26fb0ebd9a46199

1: I looked back and you were right, the exit does not come with a \n which makes it hard to use. I have added the \n to the exit.

2: the issue here stems back to the exit. I was trying to be fancy and use TCP protocol guerentees to allow new socket programers (which was the target audiance of the kata) to use the much simpler "if a.recv(1024) == 'exit'" rather than having to use some buffer. I have added the guerentee that the exit massage will come with a \n which will fix that issue (although it will sadly invalidate a lot of solutions which is why I didn't do it before.)

3: again you are right, I added the framing support to the test, although the only case I will ever use it is if you add sleeps in the middle of your massage as everything I send (and therefor should be sent back) is short enough to fit into a single TCP packate :P

4: yea, the shim is ugly. but sadly I don't know of a nicer way to implement it... the original kata descryption required port 80 rather than 1111 which was problematic... ifg you have a suggestion im open to it. I canalso see just removing it altogether as im changing the requirements in this iteration by adding the \n to the exit massage.

5: in this case, not likely to matter. but I added in a sleep there as well for good messure.

6: you are right in theory, but the main point of the kata is not actually the framing. I much prefer this kata as a first time playing with sockets and letting the user have a nice moment where it works, the framing is a neccessery evil. in reality the tests are made specificaly so that any messeage I or the user send can fit within a single TCP packet.

7: sadly the timeouts happen as a result of the nature of socket katas. if the user runs a recv when there is no data to be recived there is not much difference than running a while True: pass
I tried a few things when I first wrote this kata but ended up deciding against adding the timing failiers as they end up very dirty.

overall I wouldn't write this kata like this had I been writing it today. but I think this new fork is at least servicable :D
please take a look, I will prob republish around monday if no more suggestions arise.

My idea of valid issue is whether I can reproduce it from the description. I should probably say THAT instead. There are obviously things to fix.

If it's your most recently submitted code that you refer to as your code then my understanding is that you have two servers on the same port, with connections being distributed between them. So if the first one ends up getting the connection then the second one never ends up receiving exit and the tests join on that thread so that'll be what times out (aside when the tests fail to send anything at all due to 0 length words which also causes timeout) (and aside from join it would also timeout because they're non-daemon threads - preventing the process from exiting even if the tests have run to end)

I've been thinking about whether this kata is fixable, what trips me up is what to do about the incorrect framing usage because that's a significant thing that needs to change about the kata design - either remove it to keep it simple or fix the inputdata and add tests for framing. Either one would break nearly all current solutions. I need an adult.

mine times out when the test code "sends" an empty bytestring. which isn't to spec, and I'm guessing might be a no-op so it actually didn't send anything then expects a response

this is due to word length being random.randint(0,100) (1 in 101 chance to be empty)

I guess that's also the reason for \n. except it doesn't do that.

BTW: your issue isn't exactly valid since it doesn't say what it is failing to pass or why it fails. it doesn't describe a problem with the kata. except for the part about calling the solution function twice. but that probably isnt't the issue you're having due to one harmlessly crashing and the other continuing to exist.

I'd time out sometimes.

and there's a (poor) compatibility shim which starts another server. but I'd like to think that the second server to start would harmlessly crash, I don't see how that would cause a timeout.

it seems to me like it's test.assert_equals that doesn't finish. which is.. uhm. why..

aside from that, it also doesn't terminate messages with \n as it promises. not sure why it promises that but. would be nice if that matched up.

and tests aren't inside its

to clarify: this only happens with the Cuban Peso (CUP) which has denominations [1, 3, 5, 10, 20, 50, 100]. all other currencies seem to be
canonical

alright, thanks!

either you know, don't know, or know but not well enough

hm, not sure. I literally got an idea for this kata from just discovering dir()! and I suppose I would go that route if I were the one to solve

umm, sorry, I'm not too sure what you are saying. Do you want me to add some reading link in the description as a hint? I don't know which one and is it really worth..

Approved

I made my solution faulty to pass tests and checked the reference solution. It's broken: it only counts vowel substrings that are followed by a non-vowel char.

Fix:
https://www.codewars.com/kumite/650af328f2cc7a0064475fa3?sel=650af328f2cc7a0064475fa3

Seeing the same thing here (Python):

Testing for 'ofimdautsiatboeueo'
Vowel substrings: ['o', 'i', 'au', 'ia', 'oeueo']
5 should equal 2

Testing for 'cree'
Vowel substrings: ['ee']
2 should equal 0

Why? What's different?

Kata notes updated. Thanks.